Spanning-Tree Performance Enhancers
Welcome to our third and final post dedicated to the Spanning-Tree CCIE objectives. Since many of these features discussed are used to enhance and tune our STP environments, I’m going to bunch them all together and call them STP Performance Enhancing Features. We’ll have to watch in 15 years to see if these features ever make it into the networking hall of fame. I can hardly believe the sheer volume of information that we were able to pack into three posts. I’m sure things won’t slow down much as we get into our Layer 3 topics. It’s exciting to be able to touch on topics with such incredible depth!
For today, here’s our final exam blueprint topics regarding Spanning-Tree Protocol
2.1.f Implement and troubleshoot spanning-tree
2.1.f [iii] port fast, BPDUguard, BPDUfilter
2.1.f [iv] loopguard, rootguard
2.1.i Describe spanning-tree concepts
2.1.i [i] Compatibility between MST and RSTP
2.1.i [ii] STP dispute, STP bridge assurance
PortFast, BPDUGuard, BPDUFilter
We all know that PortFast is that thing that we should activate on access ports because it makes ports come up faster. Another key benefit when used with 802.1d STP networks is the fact that it prevents Topology Change Notifications (TCNs) from being send when the edge port changes states. Further, in RSTP and MST networks, it allows the switch to disregard the normal requirement to put the port into a Sync state when a topology change is detected and the proposal/agreement process is taking place. One key configuration option is the fact that you can either configure interfaces individually with the interface spanning-tree portfast command, or you can simply configure the global spanning-tree portfast default command. With this second option, any port that is not in a trunking operational state will automatically operate as a port with the portfast command configured. In some cases, you might need to configure portfast on a port that is configured as a trunk, but that is NOT connected to a switch. In these cases, you can configure the interface with the spanning-tree portfast trunk command.
BPDUGuard is a rather simple concept: If you get a BPDU on this port, disable it. The idea being that you don’t want users plugging in switches into your network. On a “social” note – be sure to send out notifications to your users before activating this feature if you plan to do so in production. I’ve deployed this feature in multiple networks, only have users screaming that the network is broken. It’s really surprising to discover just how many people do indeed bring in STP-speaking switches and use them at their desks. As with portfast, BPDUGuard can be enabled by default on every port with the global spanning-tree bpduguard default command. It is important to note though, that using BPDUGuard globally does protect you quite as well. The reason for this is that BPDUGuard will only run on ports where PortFast is operationally active. So, if you have DTP running on a port in dynamic mode, a user could plug in a PC, and BPDUGuard will be operational… but then, if they plug in a switch that negotiates a trunk, then portfast will no longer be operational, and then BPDUGuard will shut off. The irony is that this is often the exact scenario that BPDUGuard is intended to prevent. It is less of a worry if the port is not configured in a way in which a user could bring up a trunk link (IE, the port is hard-coded as an access port), but it’s one of the finer details that might be easy to forget, or for another network admin to be completely unaware of, leaving the door open for users to plug in a switch.
BPDUFilter is an interesting command. Depending on how you’re using it, it’s either a command you’ll want to use every day, or never at all. When configured on an interface, it essentially tells the port to stop sending and receiving BPDUs on that port. Obviously, incorrectly configuring this feature can have devastating effects on your network, so it should be avoided if at all possible. It’s likely to be rare that you’ll use the interface-level spanning-tree bpduguard enable command. Conversely, when configured globally with the spanning-tree bpduguard default command, it operates a little bit differently. It tells the switch not to send BPDUs on this port, but to still listen for incoming BPDUs. The basic idea is that it makes little sense to send BPDUs to your host PCs if they don’t know how to speak the spanning-tree language, and it causes additional overhead that is of little benefit. As with BPDUGuard, BPDUFilter, when configured globally, will only take effect on ports that are operationally running in PortFast mode.
LoopGuard runs as an additional safeguard against unidirectional links. Honestly, I’ve seen UDLD save the day far more often than LoopGuard, but since they can both run together, it’s always better to be safe than sorry. LoopGuard operates on the assumption that a port that becomes a root or alternate port should never become a designated port. A port with loopguard configured, after becoming a root port will go into a loop-inconsistent state if it stops receiving the BPDUs that cause it to become root or alternate. If a root port were to stop receiving BPDUs, it could be an indication of issues with the STP process upstream, and it may be preferable to have the link drop rather than go into a designated state. As soon as such a port begins receiving those superior BPDUs again, it will come out of its inconsistent state. Hat tip to Brian McGahan from INE’s CCIE Video Series for pointing out this great link: http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/10596-84.html. One of the great resources on that page is a table toward the bottom that shows exactly what UDLD protects and doesn’t protect, along with the same for Loop Guard.
Rootguard operates on the idea that you know where the root bridge of your spanning-tree should be, and just as importantly, you know where it SHOULDN’T be. If a new switch claims to be the root on your network in normal operating conditions, this could indicate an attack where a user is attempting to execute a man-in-the-middle exploit. If a port should not ever be a root port, you can instruct not to allow it to become so with RootGuard. Obviously, on your Root brige, this is a great idea to configure, as it should never have any root ports. This command can be activated with the interface spanning-tree guard root command.
While we’re already talking about STP, I’m going to skip ahead a few exam objective and consider some of the other topics that are very closely relate to these STP ideas we’ve covered.
2.1.i Describe spanning-tree concepts
2.1.i (i) Compatibility between MST and RSTP
2.1.i (ii) STP dispute, STP bridge assurance
Compatibility between MST and RSTP
Like VLAN 1 in a PVST/legacy STP edge, instance 0 is the only instance which interacts with STP outside the MST region. In such an environment, instance 0 merges with the non-MST regions via a Common Spanning Tree. If that term sounds familiar, it’s because it’s the same term we used to describe the merger of VLAN 1 in an PVST region with a legacy 802.1D STP region. While the interaction between MST and non-MST regions (or even between different MST regions) is not exactly the same as the CST/PVST interactions, the basic underlying concept is still the same: presenting a Spanning Tree topology that is merged between regions inside and outside of the MST region. The CST is the set of links between region boundaries. In each region, the CST and the IST (Instance 0) merge and become the Common and Internal Spanning Tree, or CIST. Individual regions each have a root bridge, and the CIST recognizes a single CIST Root Switch (one to rule them all), and a CIST Regional Root Switch in each individual region. Yes, I said that – “There will be multiple root bridges in the CIST.” Not surprisingly, the election of the CIST Root switch is won by the Regional Root switch with the lowest bridge ID, along with all switches in the STP/RSTP domains.
When RSPT or legacy STP switches interact with an MST switch, they must first operate as if they have a single topology. In other words, there can be no per-VLAN concepts between the MST and non-MST regions. MST handles this interoperation by simply having its instance 0 format BPDUs in a manner consistent with legacy STP.
When MST interacts with a PVST switch, the rules change a bit. One of the reasons we run PVST is to be able to essentially operate with multiple topoligies that can all be different. Conversely, an MST instance is a group of VLANs that all use the same topology. In order to operate correctly, ALL PVST VLANs must make the same choices as to port roles and states when they border with an MST region. The responsibility falls upon the MST region to ensure this consistency occurs. From the PVST region’s perspective, the region simply sees the BPDUs that come from the MST’s IST instance, and the MST region replicates BPDUs as necessary to interact with each PVST instance. This provides the PVST region with the same information for each VLAN. In the other direction, the MST region will only take the VLAN 1 BPDUs from the PVST region and make topology decisions based on that single VLAN. Again though, because each VLAN in the PVST region could (and in fact, very likely will) have a different topology in use, the MST boundary switch must take care to ensure that all VLANs on the PVST side will arrive at the same conclusion about the port roles in use. Therefore, the MST region is responsible for watching the BPDUs coming from all VLANs to ensure that this is the case. When the CIST Root is in the MST region, the MST region simply checks to make sure that all incoming BPDUs are inferior, so that the MST region contains the regional root for all VLANs. When the Root switch is in the PVST region, it’s a little more complicated. First of all, there are two possibilities for a port between the regions when this is the case, either the port will become a root port toward the PVST root, or it will be blocked because there is already a better path from the MST region to the root. In the case where the port becomes a root port, the MST switch ensures that the BPDUs for all other VLANs are superior to the ones being received for VLAN 1. That sounds simple at first glance, but remember what System ID Extension does: it essentially makes each successive VLANs BPDUs slightly WORSE than the previous VLANs. This is because the VLAN # is added to the priority field, and when dealing with STP, lower is better. So VLAN 1 will have a standard priority of 32769, VLAN 2 will be 32770, and so on. That slight increase means that each successive VLAN has a BPDU that is worse than the previous VLAN… and also means that this consistency check will fail if each of these VLANs has the same configured priority as VLAN 1. Therefore, if the CIST Root is in the PVST region, then all non-VLAN 1 VLANs in the PVST+ region will have to be configured with a priority value that is at least 4096 less than the priority of VLAN 1. If this consistency check fails, then the MST switch will put the port into the Root Inconsistent state. Finally, if the port will become blocking, the switch will simply block unconditionally.
Finally, we must note the fact that Cisco’s implementations of PVST+ and RPVST+ are Cisco-proprietary. When MST is neighbored with a RPVST+ region, the MST region will fall back to PVST+ operation. No, I didn’t miss the “R” there. That’s the regular-Per VLAN Spanning-Tree+, as opposed to it’s Rapid Spanning-Tree+ variant.
The STP dispute mechanism doesn’t need to be configured or activated. It is a built in feature of RSTP and MST. These two STP implementations encode the operational role and state of a port in the BPDUs that are being sent. If a switch receives a BPDU that indicates that the neighboring switch is going into a state that it shouldn’t, for instance, if a port receives an inferior BPDU that shows a port becoming designated port (not a root port – an inferior BPDU can indeed be received on a port that should be a root port), then the port will move itself into a discarding state.
STP Bridge Assurance
STP Bridge Assurance only works with RSPT and MST, and essentially tells the bridge to send BPDUs every hello interval, regardless of the state of the port. It MUST be configured on both sides of the link. Not all switches support this feature, so it will often not even be an option. If a port configured for bridge assurance does not receive a BPDU, it will go into a BA-Inconsistent state. The idea is that a link connected to a switch expects to always receive BPDUs, so if you aren’t receiving them, it might be better to shut the port down, rather than continue operating and risk a loop. Activate it globally with the spanning-tree bridge assurance comand, or on a per-interface basis with the interface spanning-tree portfast network command.
As you may suspect, Spanning-Tree covers a good section of our Layer 2 topics, and coming to the end of our STP conversation means that we are nearing the end of our Layer 2 objectives altogether.