SMTP test fails

[Jackson387]

Hi,

I'm attempting to setup Email Settings on my SG350x-48 through FindIT. When I test connectivity (which I know works), I get the following. This a single site so Probe and Manager are the same.

Any ideas on how to fix this?

[David Harper]

Hi there,

This is very strange.  Basically the temporary directory that the probe uses to store the email while it is being built seems to be missing.  However, there really isn't a good reason why it would be removed.  Can you restart the probe application by either disabling and re-enabling it through the GUI, or simply by rebooting the switch?  The probe should recreate that directory on startup.

As for why the problem occurred in the first place, it is very hard to say.  We've tried to reproduce it here without any luck so far.  It is going to be tricky to figure it out unless it is happening repeatedly.

Anyway, try restarting the probe application as I described above and let me know what happens.

Thanks,

Dave.

[Jackson387]

Hi Dave,

Progress, I think! Restarting the probe seems to have solved the temporary folder issue but now I'm left with the following. Connects to O365 but never sends. Thanks.

[David Harper]

Can you scroll down when you get that message?  The error bar only increases in size to a set maximum, and that error trace sometimes includes a lot more information with the important bit inevitably being at the bottom and not immediately visible.

Cheers,

Dave.

[Jackson387]

Hi Dave. Thanks for your response. Decided to update the SG350x-48 to 2.5.0.83 after hours last night and try your solution. However, now when I click FindIT from the web interface, it tries to redirect to https://<switch_ip>:4443 but just times out. I disabled the probe on one switch and tried it on another with the same result... simply times out on port 4443. Why are the switches no longer responding on 4443?

[David Harper]

Port 4443 should definitely be listening if the probe is enabled, but since the error you are getting is a timeout rather than a connection refused, it seems like the port is open.  Can I ask how big your network is?  Depending on the number of devices being managed, the probe can get pretty busy.  The other thing to look at is the CPU utilisation graph on the main switch GUI.  You can find it under Status and Statistics > CPU Utilization.  That wouldn't explain why there is a difference between the two versions though.  But it would be good to eliminate CPU usage as a cause.

Cheers,

Dave.

[Jackson387]

Hi Dave. I had pruned VLAN1 from all the trunks for security reasons. Once I re-enabled the default VLAN1, Network Probe began working properly. From what I can tell, It wants to connect to port 4443 on only the VLAN1 interfaces (192.168.1.x) on the switches. It times out when trying to connect to a different IP assigned to the SVI. Is there a way to force it to listen on a particular IP?

[David Harper]

It should answer on any VLAN that has an IP interface configured.  Was the PC you were connecting from in a different VLAN or subnet to the management interface?  That shouldn't matter, but I've seen something odd when I was trying to reproduce your problem that could be the issue here.  But in this case, the management interface and the PC were in different VLANs.  If they are in the same VLAN, it works no matter what that VLAN is.

Anyway, I need to do some checking with the engineering team, but in the meantime, let me know if you are in different VLANs or subnets which will help determine if we are looking at the same problem.

Cheers,

Dave.

[Jackson387]

Hi Dave,

Yes, I am in a different subnet than the switch, on the other side of the router, administering the switches remotely. I have 4 SG350x switches. All the SVIs have more than one active IP (192.168.1.x for VLAN1 and 10.235.100.x for VLAN100 - mgmt VLAN). The network is fully routed. I can manage the switches via either VLAN1 or VLAN100 IPs, however, when I click on FindIT from the web interface, it only works from VLAN1 IP. When Network Probe does work, it sometimes shows the switches with the VLAN1 IP and sometimes the VLAN100 IP. Ideally, I'd like to prune VLAN1 from the trunks again but I also want to use the Network Probe.

Is there a way to "reset" the probe and have it rediscover the network? I originally enabled it with VLAN1 up and the probe discovery worked. Then I pruned VLAN1 and tried the same thing from VLAN100. Timed out every time, even with a disable and reenable of Network Probe and reboot of the switch. It's like it was still trying to connect to the IP on VLAN1. As soon as I reenabled VLAN1 again, Network Probe began working again through 192.168.1.x:4443 address. Still times out when I try the probe from VLAN100 address.

The network is very small. Not a collection or CPU issue.

[David Harper]

Hey there,

Just wanted to let you know we haven't forgotten you.  We've reproduced this behaviour in the lab and engineering are looking in to what is going on.  Might take a little while to get to the bottom of the problem though.  I will let you know as soon as we know more.

In the meantime, everything should work if you add an IP interface on the switch for the VLAN you are trying to access the Probe from.  But that might not be feasible depending on the purpose of the different VLANs.

Cheers,
Dave.

[Jackson387]

Hi Dave,

Thanks for the update. Just to be clear... the switch I'm connecting to has multiple IPs (see image). I can manage the switch from any of them. However, the network probe only works from VLAN1 IP. Times out when I try it from the others. Don't think it's a routing issue if I can manage the switch successfully from any IP and other traffic is routing correctly.

[David Harper]

But is your PC in the same subnet as any of those VLAN interfaces?  If it is not, it will have the same issue.

Agree it is not a routing issue.  The problem is internal to the switch and since I can reproduce it fairly readily as well, it is most likely a software bug.

Cheers,

Dave.

[Jackson387]

Thanks Dave. The PC used to administer the switch is NOT in any of the subnets.

[David Harper · Accepted solution]

Just a quick progress update on this.  Engineering have identified the root cause and are working on a fix that should go into the next maintenance release of the switch firmware.  I'll let you know once we have a version number and release date, but it should not be too far away at this point.

Cheers,

Dave.

[David Harper]

Hi there,

Just wanted to follow up on this.  It took a little longer than I expected, but switch firmware version 2.5.0.90 has been posted that resolves this issue for almost all the cases we have seen.  There is one case that we know of where you will still see these symptoms, but it requires the local router to send invalid ICMP redirects, so you are unlikely to hit that case.  Anyway, can you upgrade the switch to 2.5.0.90 and see if you still have the problem.

Thanks,

Dave.