Let ' s  cla rify Spanning Tree Protocol, because it can be confusing.       I’m going to make this as painless as possible in the short beginning of this post, but details will follow for the rest that are curious in nature.     There are THREE!     802.1D  - old, D stands for DAMNIT! DAMNIT nobody switched it to Rapid-PVST.  You have one STP topology instance for all  v lans  with this version .  Its old, let's move on.     802.1W : new, W stands for WIN! I don’t need a maintenance window to switch it from 802.1D, WIN  WIN !  You will have a separate STP topology instance for every  vlan .   802.1S : newest, S stands for SUPERIOR, it is superior over the other two.  But,  in reality most  networks that we are used to won’t need this, so S can also be confused with STUPID.   However , if you are a service provider and/or your equipment can’t handle a large amount of SPT instances, etc. MSTP is for you.     What is the difference in these three versions?  802.1DAMNIT will make individuals  that are going  to Facebook wait about 50 seconds.  But 802.1WIN, you can update your status on Twitter in about a few hundred  ms.   The above times depend on where the timers/hellos are at in their transition.  No worries overall though, the two versions are backwards compatible, so go ahead and start migrating your site.       The fancy add-on features for 802.1DAMNIT, like Backbone Fast, Uplink Fast and  Portfast , you can forget about ensuring these are configured correctly because 802.1WIN has it built in and handles it for you very ninja like.     The last thing I’ll cover in the quick review section is port roles.  802.1DAMNIT has five port roles to confuse you on purpose.  Disabled, listening, learning, blocking and forwarding.  802.1WIN decided life shall be simpler, as we  really only  care about when people can  get  to Facebook, they are discarding, learning and forwarding.       802.1S is MSTP,  which stands for  multiple spanning-tree instance s protocol .  This article is already snow balling into the size of something that would smash my kid in the winter, so I'm not going to focus too much on this one.  The main reason for developing 802.1SUPERIOR is because it is unmanageable for a device to handle 409 4  SPT instances.  You can customize a range of  vlans  into SPT instances, saving your resources.  Compared to 802.1WIN, you have no choice, you have a different SPT instance  running  for each  vlan .   A  lot of the  niddy   griddy  details  are  the same and is backwards compatible with 802.1D and 802.1W.  Overall, this is another article.       *** DARE to CONTINUE***   Details for the curious:   802.1D  - The overall 50 seconds comes from the following port  transitions .     20 seconds need to expire first to  change the original port state role.  This is the result of the max age time of 20 seconds, it must time out.     15 seconds, it will sit and listen 15 seconds again, it will start to learn what it  is  listening too   Backbone Fast  is a good add-on feature.  To transition a port from blocking to forwarding will now take only 30 seconds.  This is a Cisco proprietary feature, the reason it reduces it from 50 seconds to 30 seconds, is  because it is   eliminating the  maxage  timer  of 20 seconds.  This is due to the designated port receiving an inferior BPDU than the one it originally has stored, instead of  maxage  of 20 seconds, it skips this  now  and moves directly to the listening state.       Uplink Fast,  please use the keyword “Uplink” as a remembering tool, to only be used on Uplinks to the root.  This feature is also Cisco proprietary.  This can reduce the failover time from a failed uplink of 30 seconds to 1 second.  The 30 seconds is from the listening and learning states.   Without this feature, you do have the option of adjusting the timers for the  listening and learning states to a minimum of 7 seconds, total of 14 seconds at a minimum for recovery.       It is not recommended to configure this on switches without the topology knowledge of an alternative/backup root link.  Therefore, in a lot of scenario's, this would be configured at the access layer that has 2 or more uplinks to the root.  The reason  this  fails over so quickly is due to creating  the feature creating an   uplink group .   I nstead of going through listening and learning, once the root port fails it immediately elects the next port with the lowest cost from the group and makes it the root port.     802.1W  - The major benefit of Rapid PVST is how  it  uses BPDU frames.  When a port comes online or the topology changes, the switches exchange BPDU's using proposal/agreement flags.   This is why  it transitions so fast for ports.  These flags are defined in 802.1D (TC and TCA), but RSTP now uses six bits of  the  flag byte.      These BPDU’s in 802.1W are now sent in EVERY hello, even if it does not receive any from the root.  Comparing to 802.1D,  which  would only relay BPDU’s (when it receives a BPDU from root).  With that, STP says that it has lost connectivity to its direct neighbor if it misses three BPDU’s in a row.  Therefore, with  hello’s  at 2 seconds by default, it will take at a maximum of 6 seconds to recover from a failover.  Remember, this is an event of detecting a failure in the topology, not a physical link failure, which is extremely faster.       These flags are used as part of a negotiation to determine which ports are going to be designated, non-designated or root port roles.  When transitioning ports, the proposal agreements are extremely fast, they don’t use timers, they set the bits accordingly in the BPDU byte to communicate the change and  synchronize .      Comparing to Uplink Fast failures, RSTP has its own built in technology, but better.  802.1D uses a dummy multicast generator to help speed up and clear the CAM table when there is a change in the uplink.  RSTP uses its own features and clears it immediately due to receiving a BPDU with the TC flag bit set.  This process skips a step in 802.1D, like having to wait to notify the root of a change .    N ow TC is propagating the TCN directly from the switch.  This feature is native in RSTP.       The other cool thing about RSTP is  EdgePorts , which is basically  portfast , kind of.   But the cool thing is anytime there is a change on an  edgeport , it doesn’t create a TC (topology changes) now.  Unless it receives a BPDU,  then  it will return to a normal STP port.  Edge ports also don’t receive TC’s as well.       I would continue, but spanning tree is confusing and the longer I go on, the more confusing it gets.  I hope this helps overall.   ... View more

I have a couple of 5545x's running in a HA pair, were running on 9.1.5.  The environment overview, we are running a bunch of point to point vpn's into the firewalls.  The routes come into the routing table as a static with an AD of 1.  As most people know, there is no way to change that AD of the RRI route to any other AD, quite frustrating as you can do this on the routers.  But, we have found a way to work through this.   Following, from there we redistribute the statics (RRI routes) into EIGRP.  So the neighbors will get the routes with an AD of 170.  The nice thing about this is the remote sites that we have typically have a primary MPLS connection.  Those connections come into our primary site via BGP and those are redistributed into EIGRP.   With the MPLS routes and the VPN routes, I set the VPN routes with a worse metric (not AD), therefore, if the MPLS connection is up at the remote site, that will always be preferred.  HOWEVER, i upgraded the pair to 9.6.2.  I started to realize I was getting some asymmetric routing issues on the network.  I found in the EIGRP neighbors, all the routes from the ASA pair were receiving them as internal EIGRP route (AD of 90), instead of what they were doing, receiving them as external.  Well that screwed up our balance of routes for all vpn's, now the network saw those as preferred, instead of the MPLS.   In the ASA, RRI use to put them in as a static.  They are not static's anymore, they are 'V' routes, which stands for VPN.  Example below: ! V        10.8.8.0 255.255.255.0 connected by VPN (advertised), Outside ! Following, they were just putting them into EIGRP, no redistribution was working.  But, i saw the word 'connected' in the route, so I tried redistribute 'connected', still nothing.  I looked for a command under the EIGRP process, like 'redistribute VPN', still nothing.   I currently have a TAC case open but i have not heard back from them yet.  But the only work around i found was to make a ton (felt like a billion) static routes for each vpn network and remove RRI. If anyone has any magical ideas that would be appreciated.   Thanks, ... View more