Cisco Spanning tree and network loops question

[miele1234]

Question about spanning tree / loop guard on trunk ports on 3750 backbone stack. Here is an extract from our backbone config. Has been running for four years with no problems. 

switch 1 provision ws-c3750g-24ps

switch 2 provision ws-c3750g-24ps

!

spanning-tree mode rapid-pvst

spanning-tree loopguard default

spanning-tree portfast default

spanning-tree etherchannel guard misconfig

spanning-tree extend system-id

spanning-tree vlan 1-20 priority 24576

!

interface GigabitEthernet1/0/5

switchport access vlan 20

{Above is example of a standard port connected to our server}

!

interface GigabitEthernet1/0/25

switchport trunk encapsulation dot1q

switchport trunk native vlan 2

switchport mode trunk

{Above is example of standard Trunk port CONNECTED TO OTHER CISCO SWITCHS 2950's and 3750's}

interface Vlan1

no ip address

shutdown

!

interface Vlan2

ip address 10.60.2.250 255.255.255.0

!

!interface Vlan10

ip address 10.60.10.250 255.255.255.0

interface Vlan20

ip address 10.60.20.250 255.255.255.0

We have received this recommendation from an outside consultant that looked at our switches:

-----------------------------------------------------------------------------------------------------------------------

Disable  spanning-tree portfast on the ports connected to other switches or network device. PortFast should be used only when connecting a single end station to a switch port. If you enable PortFast on a port connected to another networking device, such as a switch, you can create network loops.

------------------------------------------------------------------------------------------------------------------------------

Is this advice correct or not, we have loopguard configured as above:

spanning-tree mode rapid-pvst

spanning-tree loopguard default

spanning-tree portfast default

spanning-tree etherchannel guard misconfig

spanning-tree extend system-id

spanning-tree vlan 1-20 priority 24576

Thanks.

[dominic.caron]

Hi,

The advice is correct, but the second the port receive a bpdu, it will revert back to a standard port. Depending on the speed of your bpdu, you might create a 1-3 second loop. Bad, but not a network killer. If you start adding bpdu filtering with portfast (edge port), il can get messy.

I would still disable portfast on switch to switch link. If all switch are using rapid-pvst, the ports will come up in a few seconds. 

[wasmer_anne]

Portfast is most required on interfaces directly connected to PC/ Servers to avoid a STP induced delay in the switch interface coming up.

The global command span portfast default enables portfast on all interfaces by default, BUT as soon as a BPDU is received on an interface (switch connected to other switch), portfast is disabled. So it does not harm to have the global config portfast default and avoids to have to configure span portfast on each interface.

I do not agree with the advice given by your consultant; it creates more unnecessary work and enabling portfast globally can not create loops.

Depending whether your switches and servers are in a data-center / secure location or whether you consider that there may be a risk of rogue switches being connected to access ports, I would also add span bpdugaurd en on each interface connected to a server (if a BPDU is received, the interface will be err-disabled) or span tree bpdufilter en (if a superior PDU is received, the interface stops transmitting any traffic but resumes normal operation once those better BPDU are not received any longer).

[Peter Paluch]

Hello Anne,

I have a slightly different view of the situation. Please allow me to elaborate more closely.

So it does not harm to have the global config portfast default and avoids to have to configure span portfast on each interface.
I  do not agree with the advice given by your consultant; it creates more  unnecessary work and enabling portfast globally can not create loops.

Enabling PortFast globally in itself is not generally more or less dangerous than enabling the PortFast directly on an interface. The added risk with global PortFast configuration, however, is in the way you are managing your ports: the PortFast enabled globally applies to all access-mode ports. If you are interconnecting switches with access ports, this will activate the PortFast also on inter-switch links which is never a good idea. This is not a place to search for comfort.

Also, the disabling of PortFast can not be seen as a self-healing mechanism. Imagine that you have two access layer switches connected to a working switched topology, and for whatever reasons, you interconnect two PortFast-enabled ports on these switches with a cable. What will the ports do? They will immediately become Forwarding as the link comes up, and assuming you had a working topology before, now you have added an extra link and created a loop. Sure, the loop will be broken after the devices exchange BPDUs - but only then, not before.

In other words, this leads to a situation where there are transient, temporary switching loops introduced into a topology, and you are relying only on timers to have that loop broken. You do not prevent it - you only remedy it. This causes a very dangerous race condition: the network may be flooded by, say, several HD multicast streams, and if these huge streams get trapped in this loop, the multicast storm may become so strong that the BPDUs won't have a chance of being transmitted or even generated, and you may very well end up with a permanent switching loop. All this just because you forced the switches to be too presumptuous that "nothing can happen, and even if it does, we can manage". As it sometimes shows up, they can not.

So my personal view on this is that if the interconnections between switches are duly configured as trunks then indeed, using the global-level spanning-tree portfast default command is safe. However, if I knew that some inter-switch links are in access mode, I would never use that global command, and instead, configure the PortFast on per-port basis.

To put it simply: do not lie about the port types. If they are not edge ports, do not configure them as such.

span tree bpdufilter en (if a superior PDU is received, the interface  stops transmitting any traffic but resumes normal operation once those  better BPDU are not received any longer).

What you are describing is the BPDU Root Guard, not BPDU Filter. BPDU Filter simply causes BPDUs to not be sent and received, and its behavior differs depending on how it is configured - whether in global configuration or on a port.

Best regards,

Peter

[wasmer_anne]

Hi Peter,

thanks for correcting: BPDU filter on an interface would only cause that interface to ignore any BPDU received.

Yes, also agree that it's always better to configure a trunk as a trunk (switch mode trunk) and an access port as an access port (switchport mode access) and to avoid auto or dynamic desirable.

With RSTP/RPVSTP, the transient loop that you describe would only last as long as a BPDU is not received with normal timers 2 seconds in the worst case and a 50% probability that it's less than 1 second. So your example is a little bit extreme because, in normal circunstances, no network guy would start interconnecting switches during working hours and while there are hug multicast transfers, plus it depends on the HW type of switches & load on links...but yes theoretically I agree with you.

anne

[Peter Paluch]

Hello Anne,

Yes, also agree that it's always better to configure a trunk as a trunk  (switch mode trunk) and an access port as an access port (switchport  mode access) and to avoid auto or dynamic desirable.

Thank you. I was not talking about DTP modes, though. But if we embark on talking about dynamic modes, I agree with this recommendation as well.

With RSTP/RPVSTP, the transient loop that you describe would only last  as long as a BPDU is not received with normal timers 2 seconds in the  worst case and a 50% probability that it's less than 1 second

That might be true, but who is to guarantee that the BPDU will arrive at all, or that the switch will still have a power to process it? You see, these all are assumptions that may be violated during the occurence of the transient loop. There is no guarantee that they will hold.

but yes theoretically I agree with you.

It has been my firm belief that situations deemed as "strongly theoretical" caused many problems after they became real - and they did. The scenario as described in my previous post may be somewhat unrealistic to make it simple and visible, but there is an underlying issue I wanted to highlight. With normal STP operation, you first check if there is a loop, and proceed to forwarding state only after you have ascertained you won't generate any trouble, in other words, the STP algorithm guarantees that there will be no switching loops - even at the expense of transient losses of connectivity. With PortFast operation, you put the port into forwarding state - and hope for the best. There's no guarantee, on the contrary, it's a blind shot. Considering the destructive power of a storm in switched network, hoping alone is not enough.

Best regards,

Peter

[wasmer_anne]

Peter,

The transient loop you explained so well would only be caused by a new switch being connected to an existing STP domain, would it not?

That's maybe why we have barbaric corporatism like change control / planned maintenance windows and out-of-hours work...!

kind regards,

anne

[wasmer_anne]

Yuan,

I would also configure each trunk link (switch to switch) as span link-type point-to-point. I'm sure Peter will correct me if I'm wrong , but I believe that in order to enable the nice features of RSTP of no forward delay (avoids the default 30 seconds sending and receiving BPDU first clearing the ARP cache than populating it with newly received MAC and not passing any data traffic) but instead actively negociating its port role so that trunk ports can pass traffic within a few seconds of being enabled. 

regards

anne

[Peter Paluch]

Hello Anne,

You are spot on about the point-to-point link type for RSTP rapid convergence. It won't prevent switches from erasing their MAC address tables (nor should it do that - erasing MAC addresses from switching tables does not cause connectivity outages, only temporary flooding, and removing potentially invalid entries is crucial in TC situations) but it will allow the switches to engage into Proposal/Agreement procedure allowing them to bring a new link up rapidly.

The transient loop you explained so well would only be caused by a  new switch being connected to an existing STP domain, would it not?
That's maybe why we have barbaric corporatism like change control / planned maintenance windows and out-of-hours work...!

Well, you are assuming that everybody is well-behaved What about a not-so-well-behaved user trying to plug his own switch or WiFi AP to the company network in his office, and potentially messing with the cables to the point of having his switch connected to company network via two ports? Or a user with a laptop that is connected to the network both via WiFi and via a cable, and having bridging enabled between his WiFi and wired NICs? I would personally believe that these scenarios can occur quite often.

Best regards,

Peter