BPDUGuard Scenario

[prakashrj]

I am not able to understand the following about BPDUGuard from Chapter 11 in "CCNP Self-Study: CCNP BCMSN Exam Certification Guide, Third Edition"

-----

Naturally, BPDU guard does not prevent a bridging loop from forming if an Ethernet hub is connected to the PortFast port. This is because a hub doesn't transmit BPDUs itself; it merely repeats Ethernet frames from its other ports. A loop could form if the hub became connected to two locations in the network, providing a path for frames to be looped without any STP activity.

-----

What scenario is he describing where a loop is formed without STP activity?

Can STP detect those loops? How can I protect the network from those issues if STP cannot solve them?

Thanks in Advance.

Prakash.

[ananddiwakar]

Hie Prakash,

The scenario described here is that if you use a hub where one port connect to upstream switch and all other ports are supposed to be used only for connecting end devcies. Now accidently if another port of the hub is connected back to any upstream switch, it will form a STP loop.

The reason for this is a hub does not transmit any BPDUs. Its a passive device which just copies frames received on any port to all other ports.

To prevent these issues there is a simple solution: Do not use hubs ;)

And if you have to use hubs, then take every care that they are not accidently looping anywhere. You can also put all the hub ports (and hence effectively all the end devices connected to those hubs) in a separate VLAN to localize the impact in case of such accidents

[prakashrj]

Hi Anand,

Thank you for a detailed explanation of the scenario. I have assumed that HUB will receive BPDU Hello packets every 2 secs.

Then when a new port is connected back to another upstream link, I assumed the new upstream link to hear BPDU hellos(of first uplink) from the hub. Then I thought the BPDUGuard will block the new upstream port.

I am still confused. Will the first uplink port to the hub participate in STP? what happens to Hello BPDU's on that port?

Are you telling me that the HUB will never receive a BPDU packet?

Even if it receives, are BPDU packets different from ethernet frames. Hence the reason they are not transmitted to other ports on the HUB.

Please pardon me for asking you too many questions. Just wanted tell you how I was getting confused.

Thanks,

Prakash.

[mahmoodmkl]

Hi

You can think of this scenario like this that u r connectig two portfast enabled ports of the same switch with the crossover cable.becoz hub is not a intelligent device its just acts as a repeater.

Thanks

Mahmood

[prakashrj]

Hi Mahmood,

I have tested your scenario with a cross-over cable and BPDUGuard could detect the loop and error-disabled one of the port.

So, the other example which I first mentioned is different where BPDUGuard will not detect the loop.

I also envision HUB as a repeater and expect it to repeat BPDU Hello packets on all ports.

When the second upstream link (with BPDUGuard enabled) listens to those BPDUs that HUB just repeats.

Since BPDUGuard disables a port when it listens to any BPDU traffic, I expected the second upstream link to get into err-disable mode.

[Francois Tallet · Accepted solution]

Hi Prakash,

How about this answer: the author of this book is not very clear as to how stp works;-)

Seriously, I don't understand this scenario. As you say, a hub will relay bpdus so STP is able to block a loop through a hub. What STP cannot do is block a loop involving links that are not controlled by STP. For instance, if you connect redundantly two hubs together, they form a loop between them, and STP will be helpless preventing it. That a good reason why I never call a bridging loop an STP loop. If STP is working, there is no loop. It's only because of a failure or lack of STP that you get into this situation.

I would like also to clarify few stuff mentioned in this thread.

Portfast does not disable STP. Portfast only transition a port coming up immediately to forwarding (skipping the intermediate stages of listening learning or the proposal/agreement for rstp). But if a bpdu is received on a portfast enabled port, it may still revert to discarding. So playing around with portfast should (in theory) only open temporary bridging loop.

You don't need bpduguard to block a loop. That's what STP does naturally. Bpduguard is just a way of enforcing a security policy that states that a given port should never receive a bpdu. This could be helpful in the case where a hub is connected to an access port. The hub does not generate bpdus, so it is legitimate to configure bpduguard on the access port. If some users create a loop on the hub, it will send back to the access port its own bpdus. The access port will then go errdisable, at least isolating the loop if it cannot prevent it.

Regards

Francois

[prakashrj]

I frequently use the words "spanning tree loops". The realization that only bridging loops occur is a stroke of enlightenment for me :-) Thank you for response. I now feel comfortable about BPDUGuard and also about the implementation that I am planning to do.

Based on the knowledge I have gained.. I have decided to implement the following SPT optional features to protect our network. Can you please comment on the configuration.

on Primary Root Bridge

# conf t

(config)# udld aggressive

(config)# udld message time 7

(config)# spanning-tree mode pvst

(config)# spanning-tree logging

(config)# spanning-tree loopguard default

(config)# spanning-tree backbonefast

(config)# spanning-tree vlan 1-1024 root primary

(config)# end

#

on Secondary Root Bridge

# conf t

(config)# udld aggressive

(config)# udld message time 7

(config)# spanning-tree mode pvst

(config)# spanning-tree logging

(config)# spanning-tree loopguard default

(config)# spanning-tree backbonefast

(config)# spanning-tree vlan 1-1024 root secondary

(config)# end

#

on Access Layer Switches ( 3550-12G | 3550-12T | 3550-24 | 3550-48 | 355024PWR | 356024PS | 356048PS | 37xxStack | 4006 | 4506 | 4507 | ciscoProducts.615 | ciscoProducts.616 | ciscoProducts.617 | WS-C3550-12G | WS-C3550-24-SMI | WS-C3550-24PWR-SMI | WS-C3550-48-SMI | WS-C3560-24PS-S | WS-C3750G-12S-S | wsc4003 | wsc4006 | wsc6006 | wsc6509 )

! disable portfast on all uplink, trunk and VoIP ports.

# conf t

(config)# int range -

(config-if-range)# no spanning-tree portfast

(config-if-range)# end

#

! enable portfast on all user-access ports.

# conf t

(config)# int range -

(config-if-range)# spanning-tree portfast enable

(config-if-range)# end

#

# conf t

(config)# udld aggressive

(config)# udld message time 7

(config)# spanning-tree mode pvst

(config)# spanning-tree logging

(config)# spanning-tree loopguard default

(config)# spanning-tree backbonefast

! Enable bdpu guard by default on all portfast ports

(config)# errdisable recovery cause bpduguard

(config)# errdisable recovery interval 300

(config)# spanning-tree portfast bpduguard default

(config)# end

on 3508XL, 3524XL, 3548XL switches

! disable portfast on all uplink, trunk and VoIP ports.

# conf t

(config)# int range -

(config-if-range)# no spanning-tree portfast

(config-if-range)# end

#

! enable portfast on all user-access ports.

# conf t

(config)# int range -

(config-if-range)# spanning-tree portfast enable

(config-if-range)# end

#

# conf t

(config)# udld aggressive

(config)# udld message time 7

! Enable bdpu guard by default on all portfast ports

(config)# spanning-tree portfast bpduguard default

(config)# end

[Francois Tallet · Accepted solution]

Hi Prakash,

Well, bridging loop, forwarding loop, whatever you like to call it;-) It's just that I've been working on STP for a while and I think it is unfair to always associate the protocol with issues that occur at layer 2. I've seen people disabling STP and calling later an STP loop the result of their wrong cabling. When you don't configure OSPF on your network, you generally don't blame it if RIP is black holing your traffic;-)

Anyway, you configuration looks ok, I have nothing much to say at this high level.

If you really have 1024 active vlans, I would consider MST. With the latest standard MST implementation, not only you would save CPU cylces, but you would also be protected in a much more efficient way against unidirectional link failures than with loopguard (that you would not need in that case).

Backbonefast is a 20th century feature that only reduce your convergence time to 30 seconds from 50 seconds. Rapid-PVST and MST will behave must faster if you can easily configure them all over your network.

As a configuring help, we also introduced a portfast default command that put all the ports in porfast mode unless explicitly configured on the interface. That could save you entering: spanning-tree portfast enable on each access port.

You would instead do:

spanning-tree portfast default //globablly

Then:

(config)# int range -

(config-if-range)#spanning-tree portfast disable

(config-if-range)# end

on your uplinks.

Hope this helps!

Francois

[prakashrj]

(config)# spanning-tree vlan 1-1024 root primary

I will have atmost 10-12 Vlans in some buildings. 2 reasons for doing that and using PVST.

1) Since I have noticed BPDU traffic only for active vlans, I have enabled it for all vlans. I thought it will save me some configuration overhead when new vlans are added to that VTP Domain.

2) We have about 300 3500XL switches on campus which only support PVST. We don't have enough budget to replace those switches.

I have implemented backbonefast only because it didn't find it harmful :-)

Global portfast configuration option is convenient, but I am afraid that we will forget to disable it on uplink ports when we add new switches.

Here is an updated version of my configuration.

on Primary Root Bridge

! disable portfast on all uplink and trunk ports.

# conf t

(config)# int range -

(config-if-range)# spanning-tree portfast disable

(config-if-range)# end

#

# debug spanning-tree events

# conf t

(config)# udld aggressive

(config)# udld message time 7

(config)# errdisable recovery cause udld

(config)# errdisable recovery interval 60

(config)# spanning-tree mode pvst

(config)# spanning-tree backbonefast

(config)# spanning-tree vlan 1-1024 root primary

(config)# end

#

on Secondary Root Bridge All ports must be uplink ports.

# conf t

(config)# int range -

(config-if-range)# spanning-tree portfast disable

(config-if-range)# spanning-tree guard loop

(config-if-range)# end

#

# debug spanning-tree events

# conf t

(config)# udld aggressive

(config)# udld message time 7

(config)# errdisable recovery cause udld

(config)# errdisable recovery interval 60

(config)# spanning-tree mode pvst

(config)# spanning-tree backbonefast

(config)# spanning-tree vlan 1-1024 root secondary

(config)# end

#

on Access Layer Switches ( WS-C3550-12T | WS-C3550-12G | WS-C3550-24-SMI | WS-C3550-24PWR-SMI | WS-C3560-24PS-S | WS-C3550-48-SMI | WS-C3560-48PS-S | WS-C3560G-24TS-S | WS-C3560G-48TS-S | WS-C3560G-48PS-S | WS-C3750G-12S-E/S | WS-C4006 | WS-C4506 | WS-C4507R )

# conf t

(config)# int range -

(config-if-range)# spanning-tree portfast disable

(config-if-range)# spanning-tree guard loop

(config-if-range)# end

#

# conf t

(config)# int range -

(config-if-range)# spanning-tree guard none

(config-if-range)# spanning-tree portfast enable

(config-if-range)# end

#

# debug spanning-tree events

# conf t

(config)# udld aggressive

(config)# udld message time 7

(config)# errdisable recovery cause udld

(config)# errdisable recovery interval 60

(config)# spanning-tree mode pvst

(config)# spanning-tree backbonefast

(config)# spanning-tree portfast bpduguard default

(config)# end

on 2900, 3500XL switches ( WS-C2912-LRE-XL | WS-C3508G-XL-EN | WS-C3524-XL-EN | WS-C3548-XL-EN )

! disable portfast on all uplink, trunk and VoIP ports.

# conf t

(config)# int range -

(config-if-range)# no spanning-tree portfast

(config-if-range)# end

#

# conf t

(config)# int range -

(config-if-range)# spanning-tree portfast

(config-if-range)# end

#

# debug spanning-tree events

# conf t

(config)# udld aggressive

(config)# udld message time 7

(config)# errdisable recovery cause udld

(config)# errdisable recovery interval 60

(config)# spanning-tree portfast bpduguard

(config)# end

One final question before I can feel comfortable about the implementation.

I will enable loop guard on all uplink ports except ports on root bridge. What happens when Root port on a switch stops receiving BPDU?s under heavy traffic load? Will port get into loop-inconsistent state when it doesn?t receive the first BPDU packet? Will it wait max_age time before moving the port into loop-inconsistent state?

Basically, I will be very afraid if a port goes into port-inconsistent state as soon as it stops receiving its first Hello packet. I am afraid that STP will start its reconvergence immediately after that.