Looking for someone that has a Dell 5224 switch connected to a Cisco switch. Dell engineers have been no help. Dell link to Cisco switch is currently configured with 2 redundant switchport links. Dell side one link forwarding, one discarding. We are having issues with security scans. Dell switch sends out broadcast storm when scanned. Dell engineer said to have priority level on Dell discarding port set lower than the priority on forwarding and it would fix problem. It does not.
We want to try just one link from Dell to Cisco and configure as a trunking link.
Has anyone done this, any advise on the configuration of the Dell? Looking at the Dell switch, there is not much to configure the trunk, but it looks more like configuring an aggregate link.
If one link is forwarding and one link is blocking on the Dell side, then spanning tree is working correctly. Perhaps your bridge loop is on the Dell switch? Maybe a hub connected to 2 switchports, or a server with dual NICs set for bridging?
What exactly do you see that indicates "Dell switch sends out broadcast storm when scanned. "? Does this crash your network until the link is disconnected?
Yes, the bridge loop is on the Dell switch. We have narrowed that down. Yes, it crashes the network until we unplug the cables from the Dell, turn it off, or I do a shut on the Cisco interfaces. I set bpduguard on the Cisco ports so when the scan goes off, those ports go into err-disable and the rest of the network is now protected. At one point yesterday the one Dell switchport was sending out 22000 packets per second.
The Dell switch also has 4 connections to brocade switches. The Dell switch is only used for management of the SAN.
You said the links were redundant links, meaning only one is needed, but it sounds like maybe they are both needed, and on different VLANs?
If yes, then you should configure a trunk, and run a single link. The Dell runs a single instance of Spanning Tree, and the Cisco runs Per VLAN Spanning Tree (PVST). In that scenario, I would expect the Dell to block one link, killing traffic on that VLAN. That is not what you are seeing, but by turning on BPDU-guard you are preventing Spanning Tree from working correctly so maybe that explains it. Did you originally have connectivity problems on one VLAN?
They are both on the same VLAN. I only just recently turned on bpduguard so if there is a security scan done, our network will not crash. I put it there after the scans were crashing our network and we narrowed it down to the Dell switch causing the broadcast storm. I need to safeguard until we could figure out a solution to this.
We have not had any connectivity problems.
According to Dells doc, if I am understanding it correctly, their trunk configuration is more port aggregation. We did have port aggregation configured on both (Dell and Cisco) ends 4 years ago when the SAN was first installed, that caused many issues so we went to the current configuration which had been fine all this time until a Retina scanner was stood up and used for security scans. If we eliminate the Dell management IP from the scan, there is no storm from the Dell switch and life is good in network land. Unfortunately, being a military network, all devices must be scanned and deemed compliant to be on the network, so eliminating the IP is not an acceptable solution.
A trunk would be no help then.
If you only have one link connected do you have the problem?
When this happens are there any Dell switchports with high input packet counts?
We have not tried scanning with just one link connected. If we test it, should I leave both sides of the link configured exactly the way they are now and just disconnect and shutdown the other link?
This is the Cisco config:
description Dell San port #2 (forwarding)
switchport access vlan 18
switchport mode access
spanning-tree bpduguard enable
(other link configed the same)
Dell port settings are basic: forwarding port set at 128 priority, discarding port set at 32 priority, path cost 10000 (default), link type is auto negotiate.
ETA: Forgot to mention- the scan PC is on the same vlan as the management ip of the dell. If we scan from a different vlan, no broadcast storm occurs. ????
Just unplugging one cable should do the trick.
You should never unable portfast on an interface that connects to another switch that needs to run SPT. Same with BPDU guard, as I noted earlier. With only a single link between switches SPT becomes a non-issue, so no need to change that unless you have both links connected.
I'm assuming my Cisco config can stay to test the one link? What about spanning-tree on the Dell switch? It seems to be enabled globally, as in "Spanning-tree State".
We will be able to test first thing tomorrow morning.
I really appreciate your help on this.
Yes, with a single link you are not depending on Spanning Tree for protection, so you do not need to change your config for the single link test. In the long run, even if you stay with a single link, it is best practice to have it configured correctly in case someone inadvertently connects a redundant link.
Yes, Spanning tree should be enabled on the Dell switch.
Happy to help -- just remember to use the pull down menu to rate helpful posts.
We will try it tomorrow.
I do know that when one of the links was down, I can not ping or get to the management IP of the Dell switch via telnet or the web interface.
We ran the scan this morning with one link. I had to remove the bpduguard or the Cisco side would go into err-disable mode. The scan then worked running it with one link between the two but, as the scan was finishing, my continuous ping to the Dell managment IP started to time out. I had to power cycle the Dell switch to be able to reach the management IP. All links stayed up and were active.
Does it ping reliably with 100% returns now? Do you see any errors on the Cisco port? Do you have a replacement Dell switch to try?
Yes, it pings reliably now after power cycling the Dell switch. 1 input error on the Cisco port. We do not have a replacement Dell switch. Dell replaced this switch for us about a year ago because of issues.