BPDU and root issues within PVRST+

[Kin Loo]

Hi all, please look at a portion of my diagram which I have some questions to ask. Please ignore the access points as they are implemented for other purposes.

As you can see, I am using packet tracer. I could only enable bpdu guard and portfast on the ALS switches on the left.

1. How do I configure bpdu filtering on the ALS switches?

The network is operating in a pretty stable form. For example, DLS1 is holds the root status for vlan 11,12,13 and same goes to the other DLS switches.

2. How do I configure root guard to ensure that, for example, DLS1 for becoming root of vlan 41, or other vlans residing in other switches?

I read cisco documentation that they spanning-tree root guard should be configured on physical interfaces, (which in my case, the etherchannels) and only on the affected vlan etherchannels. Problem here is that, I enables all vlans to span accross all etherchannels. (They are all L2 etherchannels)

I consulted a friend and he told me to configure on the etherchannel which I did try. The result is that all the end hosts that used to have access with its dgw, were able to obtain IP from the dhcp router. However, after configuring root guard, all etherchannels were thrown to a inconsistent root state and none of the hosts were able to access the dgw, thus dhcp. One of the error that prompted in one of the switches is that: %SPANTREE-2-ROOTGUARDBLOCK: Port 23 tried to become non-designated in VLAN 41.

Some miscellaneous stuffs that you may ask,

Why are all vlans enabled on all etherchannels? The network was setup that all access layer switch hones a variety of hosts in different vlans. Thus practicing of logical groups within a physical location.

Why is there a router in the middle? The router is the default gateway of all hosts, it serves as a dhcp router as well. Running eigrp on it, all vlans are able to ping each other.

Why are there 4 links connecting to the router? These gi links are actually r-o-a-s links with subinterfaces configured. For example, the link between DLS1 and Core router has three subinterfaces, each subinterface with an ip of vlans its appointed to. therefore, vlan interfaces of 11,12,13. Reason behind this is that, I force all vlan 11,12,13 hosts must send packets destined to the router via DLS1, then onto the gi interface without using other links. Ensuring that more bandwidth is available for other vlans.

Please ask more questions if necessary. If you can answer my two questions and explain why, I will be grateful. Thanks

[Peter Paluch]

Hello Kin,

Let me answer some of your questions. Before I do that, however, I need to point out that all commands and behaviors I will describe only apply to real switches, not necessarily to Packet Tracer simulations. Packet Tracer does not implement the full range of IOS commands, and the behavior of Packet Tracer simulations might not be identical to the behavior of real devices.

1. How do I configure bpdu filtering on the ALS switches?

BPDU Filtering on Catalyst switches comes in two different variants. The first variant is the BPDU Filter enabled directly on an interface using the spanning-tree bpdufilter enable command. This kind of BPDU Filter completely stops sending and receiving BPDUs on that interface.

The second variant is the BPDU Filter enabled in the global configuration mode using the spanning-tree portfast bpdufilter default command. This variant has many specifics:

• It applies only to PortFast-enabled ports
• It does not stop receiving BPDUs
• It only stops sending BPDUs: After a PortFast-enabled port comes up, it will send 11 BPDUs over 10 hello_time intervals, and then stop. Should the port receive a BPDU, it will stop being a PortFast-enabled port, and so the global BPDU Filter will also stop being active on it, meaning that the port will simply start operating as a normal port and send and receive BPDUs according to normal STP rules.

It should be noted that a BPDU Filter is a very specific feature. Why do you believe you need to use it? There are scenarios where using the BPDU Filter makes sense but unless you have a very solid reason to use it, you are safer without it. Can you perhaps explain in more detail why are you trying to configure it?

The per-port BPDU Filter is commonly used when you need to split your network into two or more independent STP domains, each one of them having its independent STP root bridge and active topology. However, it is then your responsibility to make sure that these domains are interconnected in a loop-free fashion, as you cannot rely on STP loop prevention anymore.

The global BPDU Filter is just an optimization feature to stop sending out BPDUs from ports where they are likely not useful, such as interfaces toward end hosts. However, the real usefulness of the global BPDU Filter is dubious; personally, I do not think it is worth the risk.

2. How do I configure root guard to ensure that, for example, DLS1 for becoming root of vlan 41, or other vlans residing in other switches?

That is not the point of the Root Guard. The Root Guard prevents a specific port from becoming a root port; however, it does not prevent a switch from becoming a root switch.

The Root Guard would be used if you needed to connect your switched network to someone else's switched network while still sharing a single STP domain. If you wanted to make sure that the other part of the network does not attempt to overthrow your STP root, you could configure the Root Guard on all ports on your edge switches facing that other switched network. The Root Guard will prevent these ports from becoming root ports if the other network started advertising a better STP root, but they will still interoperate in STP nicely if their role is different.

It does not make much sense to use the Root Guard inside your own network. The Root Guard is intended to be used on an interface toward an untrusted network. However, inside your own network, the Root Guard would actually be harmful: Imagine that something happened to your primary path toward the root switch, and you needed to converge through an Alternate port, but that port would be configured with Root Guard. That port would then become Root_Inc(onsistent) and remain blocked, and you would lose any advantage from the redundancy in your network.

So, once again, why do you think would you want to your Root Guard in your network?

Best regards,
Peter

[Kin Loo]

Hi Peter,

Thanks for taking the time to reply. I do know there are two options of bpdufilter, I want to thank you for enriching the second option as i was not entirely clear with that. While making this topology, I planned to use the first option and apply it on the physical interfaces. Problem here is that, The 2950 switch in packet tracer do not allow me to configure that. See the photo i attached.

On second note regarding the root switch, I gotta admit I got mistaken with the terminology used of root switch and root port. okay okay, we can come to an agreement that a switch with all interfaces designated represents that it is the root switch of the particular vlan. What you are saying is that root guard prevents the interfaces from turning into root ports. If one of the interface decides to turn into a root port because it does not have root guard applied on, the current switch is no longer root switch of that vlan. The root switch selection will be contested elsewhere in which a better stp root is being advertised. In other words, root guard do defend the current root switch from turning into a non root switch, this is by preventing any root port from turning into root port.

You got me thinking that whether it is applicable to my topology. I could say possibly. As each DLS is a root switch of 3 vlans, I do want to protect its designated interfaces from becoming root. The issue I am facing here is that if I configure root guard on the etherchannels, it defends all the ports from becoming root, that indeed is a problem. Because, it applies to ALL vlans spanning on the etherchannel.

That would indeed be harmful to my network like you said because, for instance, DLS1's horizontal etherchannel is root port to vlan 41, because vlan 41 on DLS4 is the root switch. By applying root guard to that vertical etherchannel, as it is the alternating port, it will throw that root inconsistent error and puts the port into blocking mode.

Best Regards,

Kin

[Peter Paluch]

Hi Kin,

You are very welcome.

About the BPDU Filter: Can you explain why you want to use it? What do you want to achieve, or in other words, what do you want to prevent by using it? I see that you are very focused on configuring it but I am trying to understand what is your goal that you hope to accomplish by having the BPDU Filter configured. What would go wrong if you did not have it configured? Try to explain your motives.

we can come to an agreement that a switch with all interfaces designated represents that it is the root switch of the particular vlan.

This is an interesting way of looking at it :) Yes, if a switch has all its interfaces in the Designated role then obviously it is the root switch. However, this is a consequence of being the root switch, not the prerequisite - we must be careful not to confuse the cause and effect. Note that a root switch can also have blocked ports in the Backup role if there are two ports on the root switch connected together.

root guard do defend the current root switch from turning into a non root switch, this is by preventing any root port from turning into root port.

Technically, you are correct, but I am afraid that you are missing the point of the protection Root Guard is supposed to provide. You can take your root switch and configure all its ports with Root Guard, and if another switch in your network advertises a better (read - lower) root bridge ID, the Root Guard will prevent those ports from becoming root ports, and so your current root switch will continue considering itself as the root. However, what will the rest of the network do? Of course, they will converge to the new root switch because it is truly better, and your current root switch will remain isolated from the network altogether.

Consider the following diagram:

The numbers above the switches are their STP priorities. In this network, the leftmost switch is the root switch, and all is working perfectly well. This root switch also has the Root Guard enabled on its interface toward the rest of the network, and because there is truly no better switch in this network, the Root Guard does nothing.

However, let's take the switch at the right, and modify its priority from 32768 to 4096. What will happen then? Check the following diagram:

Obviously, the rightmost switch will become the root switch because nothing prevents it from doing so! The switch in the middle will happily converge to the new root switch at the right, but when it advertises this root switch to your former root switch at the left, the Root Guard will kick into action and put that port into Broken state due to Root_Inc. So, in essence, this network now has two root bridges: The right one because it deserves to be the root switch, and the left one whom no one respects but who won't accept that a better switch is in the network, due to Root Guard, and who hangs on its root switch role even though it is entirely undeserved at this point.

In other words, what has just happened? The switch at the right has become the new root switch, everybody is happy with it except the original root switch whose only port to the network is blocked by the Root Guard, and effectively, every host connected to the left switch is now cut off from the network!

Surely, you do not want this to happen.

The Root Guard is, in general, not supposed to be applied to the root switch - perhaps this is where the confusion comes from. Consider the following network that shows how the Root Guard is really intended to be used:

The whole network here has two owners: Think of yourself as a service provider, and think of me as a client. You have the left two switches, and you are their administrator. You are not the administrator of the switch at the right - that is my part of the network, and I am the administrator there. Because I connect through two switched links to you, we absolutely must run STP, otherwise a loop would form between your and my switch.

Now, of course, if you are the service provider, you do not want me to overthrow your root switch, but you still need to have your STP communicate with my STP. So what do you do is apply the Root Guard on your edge device to the ports toward an untrusted network - that is, toward me. This way, if I configure my switch to be better than your root switch, your edge switch will block the ports to me thanks to Root Guard, and will not allow me to become the new root switch in your network. My switch will become the root in my part of the network, but at the same time, I will be cut off your network, and rightfully so - this is your punishment for me trying to interfere with your root switch selection. Your network will retain your current root switch - that will not be changed. If I configure the priority of my switch to be higher than 8192, all will be good again.

So the Root Guard is intended to be used at a boundary toward an untrusted part of a network which is no longer under your administrator and which you cannot control. It is not supposed to be used on the current root switch, and it is also not supposed to be used inside your own network between your own switches, because that is a perfectly controlled and controllable environment - it is your network, there is nobody to protect yourself from. If your own network changes topology so that the switches need to choose a different root port but if it is still your network, you do not want to prevent that - otherwise, you will not be able to fall back on an alternate path toward a root, and the redundancy in your network is suddenly useless.

Try to think this over, and try to consider whether either BPDU Filter or Root Guard it is really applicable to your network, if the whole network is fully under your administration and you want to make sure that if a primary path to the root fails, an alternate path can be used.

Please feel welcome to ask further!

Best regards,
Peter

[Kin Loo]

Hi Peter,

Wow, Thank you for your explanation and I really appreciate that you provided me such in depth analysis of how the root guard function operates in STP.

Before I continue to the interesting STP part, the bpdufilter that I intended to use should prevent any bpdu packets from leaving the access layer switches and ended up in host devices' medium. This is absolutely unnecessary to the host machines as they do not need bpdu information, but on the other hand, it creates additional overhead load on the link, hence the decrease in bandwidth. If someone pops a switch into my access ports, the interface will turn into err-disabled mode so thats not a problem.

Pardon my little confusion over there where I said "root guard do defend the current root switch from turning into a non root switch, this is by preventing any root port from turning into root port."  As I meant designated port to root port, well I guess you probably figured what I was trying to say anyway.

I understood the main function of root guard now as it should not be applied in my internal network. I guess I was kind of paranoid as I anticipated an IF situation when the network is managed by a group of administrators, probably some juniors as well and in the interest in isolating the issue shall any of the administrator changes the switch priority, lesser than the root switch's priority, I was hoping some mechanism is able to prevent it. Having said that only the particular vlan is affected.

I am also puzzled when you mentioned "Note that a root switch can also have blocked ports in the Backup role if there are two ports on the root switch connected together."

Are you referring to a stp or pvst? My topology is running pvrst and the rapid protocol implements the discarding role, therefore, there is no blocking of ports. Then again, I understands that pvrst is an improved version of pvst in which backup and alternate roles are used. I think I need to read up more on that.

When you first showed the diagram, instantaneously I figured that root guard should be applied on the east interface of the middle switch, its a brilliant idea for networking between isp and client. However, I think that isp uses frame relay, ppp to connect with their client whereas through a switch, I am not sure if it is possible.

The above topology is just demonstrating vlan 11 presented using visio.

Say for example, some junior administrator changed the priority of DLS3 during a shift that I am not around, if root guard is applied on interfaces marked red, that would isolate the issue to only DLS3 and the other vlans with their respective switches should continue to operate per normal. Something to think about, if the vlan is a native vlan, untagged vtp packets will not be able to arrive at the desired switch and the entire network will be in trouble.

Best Regards,

Kin

[Peter Paluch]

Hi Kin,

Once again, you are very much welcome!

the bpdufilter that I intended to use should prevent any bpdu packets from leaving the access layer switches and ended up in host devices' medium. This is absolutely unnecessary to the host machines as they do not need bpdu information, but on the other hand, it creates additional overhead load on the link, hence the decrease in bandwidth.

Well... you are correct that the end hosts don't need BPDUs. But, quite honestly, the BPDU Filter is an overoptimization here. An STP/RSTP BPDU is 36 bytes long. Even with the LLC encapsulation, the resulting Ethernet frame carrying a BPDU still needs to be padded to the minimum length of 64 bytes (10/100 Mbps), or 512 bytes (1Gbps and higher). Even on a 10Mbps link, the bandwidth consumption of an additional 64 bytes every 2 seconds is absolutely negligible.

I have in fact seen the BPDU Filter do more harm than good: A server hosting several virtual machines was connected to multiple physical ports on a switch, and the ports have been configured with global BPDU Filter (the one that stops sending BPDUs after the first 10 hello_time intervals). All was good until, due to some misconfiguration on the server or on the virtual machines, the server started bridging frames between the multiple physical interfaces. Because the server has been running for days, the switch ports had long stopped sending BPDUs, so when suddenly the server started bridging, the switch had no way of detecting that the ports are in fact looped. The resulting switching loop had brought down the network.

So, while it is true that end hosts do not need BPDUs, and the BPDU Filter might look reasonable, STP is still your friend because it prevents you from disasters when those hosts start misbehaving, or someone connects a non-end device to the host port without you knowing.

I cannot overemphasize this: You do not want to disable STP (or a different protocol for loop prevention if there is any) in a switched network, particularly on interfaces toward edge devices where users can do all kinds of weird stuff.

If someone pops a switch into my access ports, the interface will turn into err-disabled mode so thats not a problem.

Why do you think so? For this, you would need to have your access ports configured with BPDU Guard, not BPDU Filter or Root Guard, and we have not been discussing the BPDU Guard until now :)

I guess I was kind of paranoid as I anticipated an IF situation when the network is managed by a group of administrators, probably some juniors as well

I understand what you are looking into, but frankly, Root Guard is not here to make your network fool-proof; it is here to prevent the hijacking of your root switch role by another network you cannot control at all and thus you consider it untrusted. You see, inside your own network, Root Guard would only kill some of the path redundancy you have - it would possibly prevent an alternate path to the root switch from being used if the primary path fails.

I am also puzzled when you mentioned "Note that a root switch can also have blocked ports in the Backup role if there are two ports on the root switch connected together."

Are you referring to a stp or pvst?

That statement refers to every STP version - STP, RSTP, PVST+, and Rapid-PVST+ (and even MST), although by the terminology, the "Backup role" is only recognized in RSTP and derived versions (Rapid-PVST+, MST).

In any case, what I had in mind is simply this: Consider a root switch, with someone connecting its fa0/1 and fa0/2 interfaces together with a single cable. With default settings, the fa0/1 will become Designated Forwarding, the fa0/2 will remain blocking; the RSTP/RPVST+/MST will label fa0/2 as "Backup Discarding".

This is a wonderful document on RSTP and the internals:

http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/24062-146.html

It also explains the port roles and states very nicely.

When you first showed the diagram, instantaneously I figured that root guard should be applied on the east interface of the middle switch, its a brilliant idea for networking between isp and client. However, I think that isp uses frame relay, ppp to connect with their client whereas through a switch, I am not sure if it is possible.

You are correct - there are many types of access technologies to connect to a service provider, and also, there are many types of the services themselves that the service providers can offer.

The Root Guard could be used if the service provider was offering some kind of Metro Ethernet service to the customer. Obviously, it does not apply on PPP, PPPoE, DSL, Frame Relay, or other non-Ethernet kinds of access technologies.

But it also applies if, for example, two companies are merging including their switched networks, and you want already to impose who's going to be the part with the "righteous" root switch. Or imagine two independent companies in the same building, one company using the other company's network as a transit network, and the other company wanting to make sure that their root switches won't be tampered with.

Say for example, some junior administrator changed the priority of DLS3 during a shift that I am not around, if root guard is applied on interfaces marked red, that would isolate the issue to only DLS3 and the other vlans with their respective switches should continue to operate per normal.

That is true, but also consider another scenario: If the Po12 between DLS1 and DLS2 fails, DLS2 needs to choose Po23 as its new root port to make sure that the network remains fully connected. However, if you run Root Guard on Po23, this port will instead become Root_Inc and blocked, and DLS2 will remain cut off the network. So instead of STP doing its job and switching to an alternate loop-free topology while still maintaining full connectivity, your application of Root Guard on DLS2 Po23 has effectively rendered the redundancy in your network useless.

That's why I keep saying: Root Guard is not intended to be used inside your own network; it is not a mechanism to make your network fool-proof.

Something to think about, if the vlan is a native vlan, untagged vtp packets will not be able to arrive at the desired switch and the entire network will be in trouble.

I am afraid I do not see how VTP could be relevant. VTP synchronizes the contents of VLAN databases across switches in a VTP domain, but until you do not modify the VLAN database, VTP does nothing. In addition, VTP is always sent in VLAN1, not in native VLAN; if the trunk happened to use a different native VLAN, VTP traffic would be tagged with VLAN1 tag.

There is an exception to what I just wrote, and that is VTP Pruning - but let's rather not go into this topic, as we are covering quite a vast range of technologies already :)

Best regards,
Peter

[johnlloyd_13]

hi peter,

good read and nice to see you here again!

i've started reading your CCIE RS v5 book.

just out of topic question, does it cover v5.1?

[Peter Paluch]

Hi John,

Thank you - and thank you :) Yes, it's a good feeling to be here again! It's more difficult nowadays, as my workload in TAC is significantly more demanding than what it was while I was still a uni teacher, but I am doing my best to juggle both.

Regarding that book: Oh, thank you - hope you have a good time reading it. In Volume 1, I have had my hands in chapters 2 (Ethernet, VLANs, etc.), 3 (STP), 6 (IP Forwarding), 7 (RIP), 8 (EIGRP), 9 (OSPF), and 10 (IS-IS). Narbik was handling the other chapters.

Unfortunately, the book does not cover 5.1 topics. The 5.1 revision came more than one year after the book was published. I guess we should definitely be looking into having it updated, but there have been no talks with Cisco Press about this particular issue so far, and also, due to some additional involvements on my part, it might not be possible for me to engage in such an update at this time. I remain positive, though, that we can find a way. I would certainly like to continue being active on that particular title.

Thank you once again!

Best regards,
Peter

[Kin Loo]

Hi Peter,

Thank You for your responses till this far, I really learned alot from you. I really enjoyed that you shared your experience of the server that has multiple ports connected to the switch, as all of the port are configured with bpdu filters, it will pose an issue because ports that are on a switch, destined to a host end-device, excluding server should be configured as access and bpdu parameters and portfast should be configured. Whereas if its a server, it should be in a trunking mode, in a separate promiscuous vlan, therefore bpdu parameters should never be configured in that scenario. For instance, if the server uses VMware vCenter with couple of vSwitches configured, it would means that the server does expect to receive bpdu frames on those interfaces.

My scenario is that all the hosts connected to the access layer switches are desktop end user computers. No IP phones as well.

The scenario examples you made are really spot on and I could say that it could be a recipe for MAN. Probably have a network for research facilities within a city would most benefit from it.

I understood what you mean for root guard and I will not apply it, it certainly will cause issues when failure takes place on another interface or link.

If VTP is always set to vlan1, wont it be unable to traverse if vlan1 is administratively shutdown because another vlan is chosen as the native vlan?

Is it a better practice to use vlan1 as the native vlan as I think it might be vulnerable to hackers if they inject packets into vlan1 (with a vlan tag of vlan1), causing it to flood as part of a dos attack?

Is there anyway to change how the vtp would use another vlan instead?

Thanks,

Kin

[Peter Paluch]

Hello Kin,

Thank you very much once again for your kind words! I really appreciate them.

My scenario is that all the hosts connected to the access layer switches are desktop end user computers. No IP phones as well.

I understand that this scenario makes you feel very safe, because - indeed - if nobody starts playing with the cables to end hosts, there can be no switching loop, and so applying the BPDU Filter on the access ports toward these end hosts might appear as a reasonable optimization.

However, what if, for example, there are two Ethernet sockets in an office, and a user connects them together? It's easier than you think - just leave a single Ethernet cable connected to an Ethernet socket on one end on an office table, and it's almost certain that someone will start thinking that the cable was disconnected by mistake, and will plug the second end into the first Ethernet socket that is free in the office. And voila - you've got a switching loop. And I am not even talking about malicious attempts to cause trouble that can be very inventive.

The bottom line is: The BPDU Filter is not a tool you really want to use. Except in specific scenarios where you want to intentionally split a network into a series of independent STP domains, the BPDU Filter is a dangerous thing, and I cannot recommend using it.

If VTP is always set to vlan1, wont it be unable to traverse if vlan1 is administratively shutdown because another vlan is chosen as the native vlan?

This needs further clarification. First of all, you cannot shutdown VLAN 1. You can shutdown "interface Vlan1", or SVI 1, but that is something different, and shutting down SVI 1 does not affect the operation of VLAN 1 itself.

What you can do with VLAN 1 on trunks is twofold: You can change the native VLAN to a different VLAN, and you can disallow VLAN 1 on that particular trunk.

Perhaps surprisingly, neither of these actions really impacts the operation of VTP.

VTP is hardcoded to operate in VLAN 1. If VLAN 1 is the native VLAN on a trunk, VTP messages will be sent without a 802.1Q VLAN tag. If the trunk uses a different native VLAN, the VTP messages will be sent tagged, with the VLAN ID in the 802.1Q VLAN tag being set to 1.

Disabling VLAN 1 on a trunk by removing from the list of allowed VLANs has no impact on VTP. Protocols such as CDP, LLDP, DTP, VTP, LACP, PAgP, or LOOP continue being sent and received on a trunk even if you disable VLAN 1. This is done intentionally by design.

Is it a better practice to use vlan1 as the native vlan as I think it might be vulnerable to hackers if they inject packets into vlan1 (with a vlan tag of vlan1), causing it to flood as part of a dos attack?

Arguably, the best practice is twofold:

• Keep VLAN 1 enabled on trunks but do not use it for any data traffic. I have seen situations where disabling VLAN 1 had negative impact on certain protocols (MSTP in particular). While that was certainly a bug, the easiest way to prevent those unexpected glitches was not to touch VLAN 1 in the first place.
• Change the native VLAN to a different VLAN than 1, and also keep that VLAN unused.

In short, change the native VLAN to a different unused VLAN, and then keep both these VLANs unused across your whole switched network.

Is there anyway to change how the vtp would use another vlan instead?

No. VTP is tied to VLAN 1; it cannot be made to communicate over any other VLAN.

However, why are you so worried about VTP? Apart from the fact that the best practice is to deactivate VTP (use VTP Transparent or VTP Off mode), the VTP would not cause your network to stop operating just because the VTP messages cannot be passed between switches. Can you perhaps elaborate more why do you believe that VTP is so crucial?

Best regards,
Peter

[Kin Loo]

Hi Peter,

I apologize for the late reply as I am busy these days. 

It does make sense that a switching loop will be formed if someone decided to plug in an ethernet cable with both ends connecting to the switch. Just that I guess employees have a minimal sense of intelligence and they are not that bored. I guess its an unlikely but possible of cause of a problem. So if this is the case, how is the switch going to react to it? Will the port violation shuts down or err-disable the interface?

I also understood the concept behind vlan 1 now that you had explained it this way. Exactly in my set up, vlan 1 is now left intact and the native is vlan 99.

I dont know, im just trying to iron things out as a curious beginner would. I thought that vtp would cause my network to stop operating if an additional switch is added and because the revision is different, it wipes off all existing vlans.

Thanks,

Kin