1

I have three new Cisco SG-300s operating in default settings. These are connected to two WatchGuard M300s in a HA configuration, with the WatchGuards acting as the router. These three switches connect to ten rack servers.

When I connect to the server's ILO NICs via one of the Cisco switches, 99% of packets are lost. I am able to browse each server's ILO GUI for around 30 seconds, after which, all network connectivity drops. This is the same whether I am connected via Remote Desktop into a server within the physical network, or whether I am using my laptop externally via VPN.

I have had extensive calls with WatchGuard, and after enabling debug logs across the cluster, I can see that each packet is allowed to transmit through the firewall to the switch and visa versa.

What confuses me is that if I connect to the WatchGuard cluster and use the inbuilt ping tool, 100% of packets are sent/received to the devices on the Cicso ILO switch.

I believe have ruled out the possibility of two new WatchGuards being at fault, and I cannot see a reason for each server's ILO port to be faulty, nor for all of the new patch cables to be faulty. For debugging, I have enabled DHCP, and each server ILO NIC picks up an IP address from the WatchGuard.

The three IP ranges are:

  • Cisco switch 1 (blue cabling) 10.0.1.X/24, connected to eth1 on the WatchGuard cluster (can ping fine 100% of the time).

  • Cisco switch 2 (red cabling) 10.0.2.X/24, connected to eth2 on the WatchGuard cluster (can ping fine 100% of the time).

  • Cisco switch 3 (green cabling - ILO) 10.1.0.X/24, connected to eth3 on the WatchGuard cluster (drop 99% of packets).

My question therefore is what within the Cisco switch or networking configuration could be causing this?

Ping tool

WatcgGuard configuration

  • Have you checked that the interfaces on the connections between the devices are all set to Auto/Auto? If you have one side fixed, and the other side Auto, then you can certainly have such problems. For example, if the ILO is set to 100/Full, but the switch interface to which it is connected is set to Auto/Auto, then you will have collisions, CRC errors, runts, etc. that will slow communications to a crawl. – Ron Maupin Aug 10 '17 at 13:53
  • Hi Ron, thank you for your response. I believe it was caused by one of the switches accidentally being set to L3. I don't believe my factory reset commands worked as they should as it seemed to had not switched to L2. Now everything works fine and as expected. – Jake Elsley Aug 30 '17 at 15:30
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Feb 21 '18 at 16:38
2

This seemed to be caused by a faulty factory-reset. One of the switches was still configured in L3 mode and had not reset to L2 mode. I believe the switch was then conflicting with the routing being performed by the WatchGuard.

| improve this answer | |
  • You should accept your answer so that the question doesn't keep popping up forever, looking for an answer. – Ron Maupin Oct 30 '17 at 14:03
  • Please accept your own answer. :-) – user36472 Dec 29 '17 at 11:14
0

before u proceeding, please make sure the switch has been updated to the latest firmware available. It would also help to enable logging on the switch as it may give an idea as to the problem. The SG300 does offer 'port' mirroring. In this case the 'port' you could mirror is all of vlan2 and do it from any other port on the switch. For a packet capture go to Administration > Diagnostics > Port and VLAN Mirroring.

With regard to involving both TAC and SBSC, it is often easiest to get a TAC engineer online and then call the SBSC. We here in the SBSC are more on-demand and can be reached anytime.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.