1

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. 
2

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, RootGuard
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
3

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
4

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.

STP Dispute
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.