Unsolved
This post is more than 5 years old
2 Posts
0
403780
May 28th, 2010 19:00
6224, Spanning Tree, and Topology Change Behavior
We're using Dell PowerConnect 6224 switches. In my opinion, the spanning-tree implementation incorrectly sets some ports to the discarding state during topology reconfiguration.
We have interconnected two 6224s with a pair of cables creating a loop. We expect spanning tree to cause one port to be blocked, which it does.
The problem happens when we disconnect the cable for the currently forwarding port of the loop. The 6224 changes the mode of all edge ports (connected to PCs and servers) to be discarding (and eventually learning) for 30 seconds before restoring them to the forwarding state. This does not happen on other brands of network switches -- if the switch hasn't seen a BPDU on a port then why would it be affected by a topology change?
Additionally, even though I have set the spanning-tree mode to rstp, it takes 30 seconds for the edge port to get back to forwarding.
Setting the portfast option on the edge ports prevents the problem. Is this a requiement for the Dell switches? What if someone connects a switch to a portfast port?
There is the "spanning-tree portfast bpdufilter default" command, but the description makes me wonder if we could end up with loops in the LAN. Does Dell support shutting down that port if a BPDU is received on what we designate an edge port (and does it work)?
Any thoughts on the auto-portfast option?
Below are just a bunch of details:
Test config:
Dell PowerConnect 6224, hostname switch56, software version 2.2.0.3
Dell PowerConnect 6224F, hostname switch57, software version 2.2.0.3
PC, connected to switch56 port 1/g11
PC, connected to switch57 port 1/g23
switch56 port 1/g1 connected to switch57 port 1/g21
switch56 port 1/g2 connected to switch57 port 1/g22
Since we have two paths between the switches, switch56 port 1/g3 is in the discarding state (Sts=DSC, Role=Altn).
According to the "show spanning-tree" command, we are configured to run RSTP on both network switches.
When I unplug the cable between switch57 port 1/g21 and switch56 1/g1, port 1/g3 on switch56 goes to "Sts=Fwd, Role=Root", but port 1/g11 on switch56 transitions to "Sts=DSC, Role=Desg".
30 seconds later we see port 11 transition back to forwarding.
peterhd
22 Posts
0
May 29th, 2010 01:00
This behaviour is correct according to RSTP (802.1w) standard. It's essential to declare all edge ports by configuring "spanning-tree portfast" not only to prevent them from being blocked for 30 seconds, but also to prevent generating topology changes to the whole LAN when some workstation is turned off.
It's also correct, that it takes 30 seconds to bring undeclared edge port to forwarding state. Rapid state transitions are only possible when the other side also speaks RSTP, but in case of edge port, the other side is not sending any BPDUs - hence the protocol must fall back to classic STP as per specification.
Setting portfast is also required and highly recommended on e.g. Cisco switches.
For shutting down an edge port which received an unexpected BPDU, use "spanning-tree bpdu-protection" global command.
pzero
1 Rookie
•
108 Posts
0
May 31st, 2010 06:00
I think the behavior you are seeing is similar to what I described in this thread:
http://en.community.dell.com/support-forums/network-switches/f/866/t/19333986.aspx
BHunsaker
2 Posts
0
June 5th, 2010 00:00
Based upon my reading of the 802.1D-2004 (incorporates 802.1w) standard and experiments with Cisco and HP switches, the Dell handling of edge ports is ... wrong.
The problem appears to be that the Dell 6224 switches only implement the adminEdge logic but not the operEdge boolean as defined in the Bridge Detection state machine in section 17.25.
HP and Cisco handle this appropriately. Please refer me to any Cisco document stating that portfast is required for edge ports. Yes, Cisco recommends edge ports be set to portfast (adminEdge) to avoid the 30 second delay for workstations. But adminEdge is not required to avoid topology changes as the Topology Change state machine in section 17.31 of the standard accounts for operEdge to prevent TCNs.
Besides referencing the standard, here is another good document to review:
http://www.ieee802.org/1/files/public/docs2008/aq-seaman-fragile-bridges-0908.pdf
Any chance of getting Dell switches to behave like Cisco and HP in terms of managing edge ports without requiring portfast?
bh1633
909 Posts
0
June 11th, 2010 08:00
in 3.2 firmware the following command is available that will make the behaviour match the other implementations.
spanning-tree auto-portfast Allow to move to the forwarding state when BPDU timeout occurs
Here is an example:
console(config)#interface range ethernet all
console(config-if)#spanning-tree auto-portfast
jheinrichs79
6 Posts
0
April 14th, 2013 07:00
Do I have to go into the ports that are connected to other switches and do something to them... IE. turn off portfast to prevent switching loops?
Any down sides of running these commands?
Mikeb76
26 Posts
0
September 23rd, 2016 10:00
Daniel,
I changed the instance from 0 to 1 for the 41VLAN on both sides. made sure port channel was correct on both side. But looking at the upstairs switch I still see STATE: Discarding. Where do I make that change ?? I've looked thru pages 354-360 and don't see were I make the changes. On the core switch it says FOWARDING
CMTX-IDFC-6248#show spanning-tree port-channel 41
Port ch41 Enabled
State: Discarding Role: Alternate
Port id: 96.666 Port Cost: 20000
Port Fast: No (Configured: no ) Root Protection: No
Designated bridge Priority: 32768 Address: 00:25:64:2C:42:FE
Designated port id: 96.666 External path cost: 20000
CST Regional Root: 00:00:00:25:64:2C:42:FE CST Port Cost: 0
Root Guard..................................... FALSE
Loop Guard..................................... FALSE
TCN Guard...................................... FALSE
BPDU: sent 1503, received 58390
CMTX-IDFC-6248#