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.

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

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?

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

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?

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#