Classic STP (802.1D) Exception BPDU Generation

NetCraftsmen®

Recently, a friend of mine, currently pursuing the CCIE, was tackling the all important topic of spanning tree; specifically taking a deep dive into the inner workings of classic STP defined by 802.1D and comparing it to 802.1W (RSTP). After reviewing a couple of references, he was confused about how STP and RSTP respond to the reception of inferior BPDUs. This article illustrates the actual behavior in Cisco IOS focusing on the use of the “Exception BPDU”.

The working of STP BPDUs is well documented for a stable topology, essentially when a fully functional Root Bridge/Switch is present in the topology and is generating configuration BPDUs every HELLO_TIME seconds. The confusion usually occurs when one is discussing STP/RSTP during convergence/reconvergence i.e. the Root Bridge has, for whatever reason, experienced a failure and is no longer generating BPDUs; none that reach other switches in the network anyway. In such a case, a commonly used but not-exactly-correct summary states the behavior somewhat like: “STP switches ignore any inferior BPDUs they may receive on their designated ports till the stored BPDU expires whereas RSTP switches respond to inferior BPDUs with a proposal message using previously cached information”.

Sometimes it is a wording issue – for example, in this definitive article on STP and RSTP convergence, http://blog.ine.com/wp-content/uploads/2011/11/understanding-stp-rstp-convergence.pdf, quadruple CCIE Petr Lapukhov writes:

“Now for the case when upstream bridge loses all paths to the root bridge. In this case, the original root bridge information is expired (immediately or in up to Max_Age seconds) and the upstream declares itself as a new root. Immediately after this it starts sending inferior BPDUs, declaring itself the new root. The downstream bridge ignores this new information for the duration of the Max_Age – Message_Age, retaining information about the original root. After this timeout expires, there are two possible outcomes:”

The highlighted wording is seemingly at odds to what Radia Perlman describes in her “Interconnections” book. She writes:

“If the only time the Designated Bridge issued a configuration message were upon receipt of a configuration message from the direction of the root, there would be no reason to include the age field in the configuration message because upon transmission it would always be 0. However, there is another situation in which a Designated Bridge will issue a configuration message even if one has not been received recently from the root port. Suppose that B is the Designated Bridge on a particular port. Suppose, too, that B has not recently received a configuration message from the direction of the root, so that the stored configuration message from the direction of the root now has age X (B has been aging the message while holding it in memory). If another bridge, B2, were to come up, it would issue its own configuration message because it would not have heard B’s configuration message on that LAN. It would be dangerous for B to ignore this situation until B hears a new configuration message from the root because it would cause the new bridge to be very unsynchronized with respect to the rest of the network. If the new bridge does not hear B’s configuration message, the new bridge will assume that it should become designated on that port, causing extra connectivity, a loop. If B retransmitted its configuration message without the age field (or with age field 0), then it would slow down discovery of any failure of the root in that subtree because B’s retransmission of the configuration message would look like assurance that the root (and the path to the root) was still functioning at the time B retransmitted its configuration message”.

She is describing what we can call an “Exception BPDU”. Note: She does not name the behavior as an “Exception BPDU”, but Kennedy Clark does in “Cisco LAN Switching” to simplify the writing and the discussion of the behavior. What an “Exception BPDU” does is that it prevents the downstream switch from sending inferior BPDUs until the BPDU currently stored on the designated port is expired. In the quote from Petr above, he has simplified the description by omitting the behavior of “Exception BPDUs”, which for the purposes of his article is unimportant.

But for a student pursuing a CCIE, such a statement is very tormenting as the person is torn between who to believe in, a quadruple CCIE and CCDE or the mother of STP.

However, “Exception BPDUs” do happen in Cisco IOS. We can illustrate the “Exception BPDU” behavior in a simple lab with the following topology:

The links have been configured as trunk ports with VLAN 1 as the native VLAN.

Sw1 has been made the root for VLAN 1 with a bridge priority of 0.

Also, the Max-Age on Sw1 has been increased to a value of 40, the maximum value IOS allows. The reason for this will become apparent soon but mostly has to do with ease of verification.

The topology stabilizes for VLAN 1 as is shown below:

Sw1#sho span vlan 1
VLAN0001
  Spanning tree enabled protocol ieee
  Root ID    Priority    1
             Address     0012.0183.3b00
             This bridge is the root
             Hello Time   2 sec  Max Age 40 sec  Forward Delay 15 sec
  Bridge ID  Priority    1      (priority 0 sys-id-ext 1)
             Address     0012.0183.3b00
             Hello Time   2 sec  Max Age 40 sec  Forward Delay 15 sec
             Aging Time 300
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/23              Desg FWD 19        128.23   P2p 
-----------------------------------------------------------------------------------------------
Sw2#sho span vlan 1
VLAN0001
  Spanning tree enabled protocol ieee
  Root ID    Priority    1
             Address     0012.0183.3b00
             Cost        19
             Port        25 (FastEthernet0/23)
             Hello Time   2 sec  Max Age 40 sec  Forward Delay 15 sec
  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     0018.b9ff.c780
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 300
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/19              Desg FWD 19        128.21   P2p 
Fa0/23              Root FWD 19        128.25   P2p 
-----------------------------------------------------------------------------------------------
Sw3#sho span vlan 1
VLAN0001
  Spanning tree enabled protocol ieee
  Root ID    Priority    1
             Address     0012.0183.3b00
             Cost        38
             Port        21 (FastEthernet0/19)
             Hello Time   2 sec  Max Age 40 sec  Forward Delay 15 sec
  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     0018.b974.3f80
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 300
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/19              Root FWD 19        128.21   P2p

Now to set up our topology to test the scenario, we need a standalone switch that will produce an inferior BPDU during the time when Sw1 is apparently down but not out (its BPDUs still have not reached MESSAGE_AGE = MAX_AGE).

To facilitate this behavior, the following command is issued on Sw3:

int f0/19
  spann bpdufilter enable

As should be true, with a single uplink the is no longer processing any BPDUs, Sw3 believes itself to be the root:

Sw3#sho span vlan 1
VLAN0001
  Spanning tree enabled protocol ieee
  Root ID    Priority    32769
             Address     0018.b974.3f80
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     0018.b974.3f80
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 300
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/19              Desg FWD 19        128.21   P2p

Note – it is not sending any BPDUs out F0/19 because of the filter.

Now, Sw3 can be forced to send an inferior BPDU to Sw2 on demand (removal of the BPDU filter).

Note that Sw1 right now is, and this is the normal behavior for 802.1D STP, the ticker of the topology. I.e. if it stops sending BPDUs, the switches in the rest of the topology stop relaying them. Specifically, Sw2 stops sending any BPDUs out on F0/19 towards Sw3.

Therefore, once the following command set is issued on Sw1 :

Sw1(config)#int f0/23
Sw1(config-if)#spanning-tree bpdufilter enable

Then Sw2 should stop receiving BPDUs and in turn should stop sending any BPDUs on its designated ports, namely F0/19.

Now, during this period when Sw1 and Sw2 are not producing any BPDUs but within 40 seconds of issuing the BPDU filter on Sw1 (the MAX_AGE was increased just so there is enough time to perform verification without going into “hurry up offense”), if the BPDU filter is removed on Sw3:

Sw3(config)#int f0/19
Sw3(config-if)#no spanning-tree bpdufilter

Then, Sw3, believing itself to be a Root Bridge, will send a BPDU on F0/19. This BPDU, when Sw2 compares it to the stored BPDU on F0/19, will be inferior thereby forcing Sw2 to send an exception BPDU in response.

The above two commands, on Sw1 first and Sw3 second, will be issued about 15 to 20 seconds apart. What does this do? This enables the check of “before and after” on Sw3. The first round of verification is simple, with show commands. The message age will be shown as increasing towards 40 on Sw2 for BPDUs on F0/23 and then same age will be shown to have instantaneously reflected on Sw3 after the removal of the BPDU filter.

On Sw3, this is its idea of the stabilized STP topology :

Sw3#sh span vlan 1 det | in Port|Timers|BPDU
  Timers: hello 1, topology change 0, notification 0, aging 300
 Port 21 (FastEthernet0/19) of VLAN0001 is designated forwarding 
   Port path cost 19, Port priority 128, Port Identifier 128.21.
   Timers: message age 0, forward delay 0, hold 0
   BPDU: sent 394, received 890
Sw3#sh span vlan 1 det | in Port|Timers|BPDU
  Timers: hello 0, topology change 0, notification 0, aging 300
 Port 21 (FastEthernet0/19) of VLAN0001 is designated forwarding 
   Port path cost 19, Port priority 128, Port Identifier 128.21.
   Timers: message age 0, forward delay 0, hold 0
   BPDU: sent 394, received 890
Sw3#sh span vlan 1 det | in Port|Timers|BPDU
  Timers: hello 1, topology change 0, notification 0, aging 300
 Port 21 (FastEthernet0/19) of VLAN0001 is designated forwarding 
   Port path cost 19, Port priority 128, Port Identifier 128.21.
   Timers: message age 0, forward delay 0, hold 0
   BPDU: sent 394, received 890

Notice the BPDUs are stable, courtesy of the BPDU Filter. Keep these numbers in memory.

After issuing the BPDU filter on Sw1, a few snapshots are taken at Sw2 –

Sw2#sh span vlan 1 det | in Port|Timers|BPDU
  Timers: hello 0, topology change 0, notification 0, aging 300
 Port 21 (FastEthernet0/19) of VLAN0001 is designated forwarding 
   Port path cost 19, Port priority 128, Port Identifier 128.21.
   Timers: message age 0, forward delay 0, hold 0
   BPDU: sent 2131, received 394
 Port 25 (FastEthernet0/23) of VLAN0001 is root forwarding 
   Port path cost 19, Port priority 128, Port Identifier 128.25.
   Timers: message age 9, forward delay 0, hold 0
   BPDU: sent 2131, received 394
Sw2#sh span vlan 1 det | in Port|Timers|BPDU
  Timers: hello 0, topology change 0, notification 0, aging 300
 Port 21 (FastEthernet0/19) of VLAN0001 is designated forwarding 
   Port path cost 19, Port priority 128, Port Identifier 128.21.
   Timers: message age 0, forward delay 0, hold 0
   BPDU: sent 2131, received 394
 Port 25 (FastEthernet0/23) of VLAN0001 is root forwarding 
   Port path cost 19, Port priority 128, Port Identifier 128.25.
   Timers: message age 11, forward delay 0, hold 0
   BPDU: sent 2131, received 394
Sw2#sh span vlan 1 det | in Port|Timers|BPDU
  Timers: hello 0, topology change 0, notification 0, aging 300
 Port 21 (FastEthernet0/19) of VLAN0001 is designated forwarding 
   Port path cost 19, Port priority 128, Port Identifier 128.21.
   Timers: message age 0, forward delay 0, hold 0
   BPDU: sent 2131, received 394
 Port 25 (FastEthernet0/23) of VLAN0001 is root forwarding 
   Port path cost 19, Port priority 128, Port Identifier 128.25.
   Timers: message age 13, forward delay 0, hold 0
   BPDU: sent 2131, received 394
Sw2#sh span vlan 1 det | in Port|Timers|BPDU
  Timers: hello 0, topology change 0, notification 0, aging 300
 Port 21 (FastEthernet0/19) of VLAN0001 is designated forwarding 
   Port path cost 19, Port priority 128, Port Identifier 128.21.
   Timers: message age 0, forward delay 0, hold 0
   BPDU: sent 2131, received 394
 Port 25 (FastEthernet0/23) of VLAN0001 is root forwarding 
   Port path cost 19, Port priority 128, Port Identifier 128.25.
   Timers: message age 14, forward delay 0, hold 0
   BPDU: sent 2131, received 394

As can be seen, the message age on the Root port BPDU is incrementing towards 40 and BPDU transmission has ceased in both directions.

Now on Sw3, the filter command will be removed. Pay attention to the Message-age and BPDU numbers before and after. Note that the commands below were issued in quick succession, no smoke and mirrors (Empty lines have been placed to increase visibility after the fact).

Sw3#sh span vlan 1 det | in Port|Timers|BPDU
  Timers: hello 1, topology change 0, notification 0, aging 300
 Port 21 (FastEthernet0/19) of VLAN0001 is designated forwarding 
   Port path cost 19, Port priority 128, Port Identifier 128.21.
   Timers: message age 0, forward delay 0, hold 0
   BPDU: sent 394, received 890
Sw3#conf t
!
Enter configuration commands, one per line.  End with CNTL/Z.
Sw3(config)#int f0/19
Sw3(config-if)#no spanning-tree bpdufilter 
Sw3(config-if)#end
!
Sw3#sh span vlan 1 det | in Port|Timers|BPDU
  Timers: hello 0, topology change 0, notification 0, aging 300
 Port 21 (FastEthernet0/19) of VLAN0001 is root forwarding 
   Port path cost 19, Port priority 128, Port Identifier 128.21.
   Timers: message age 30, forward delay 0, hold 0
   BPDU: sent 395, received 891
Sw3#sh span vlan 1 det | in Port|Timers|BPDU
  Timers: hello 0, topology change 0, notification 0, aging 300
 Port 21 (FastEthernet0/19) of VLAN0001 is root forwarding 
   Port path cost 19, Port priority 128, Port Identifier 128.21.
   Timers: message age 32, forward delay 0, hold 0
   BPDU: sent 395, received 891
Sw3#sh span vlan 1 det | in Port|Timers|BPDU
  Timers: hello 0, topology change 0, notification 0, aging 300
 Port 21 (FastEthernet0/19) of VLAN0001 is root forwarding 
   Port path cost 19, Port priority 128, Port Identifier 128.21.
   Timers: message age 33, forward delay 0, hold 0
   BPDU: sent 395, received 891
Sw3#sh span vlan 1 det | in Port|Timers|BPDU
  Timers: hello 0, topology change 0, notification 0, aging 300
 Port 21 (FastEthernet0/19) of VLAN0001 is root forwarding 
   Port path cost 19, Port priority 128, Port Identifier 128.21.
   Timers: message age 35, forward delay 0, hold 0
   BPDU: sent 395, received 891
Sw3#sh span vlan 1 det | in Port|Timers|BPDU
  Timers: hello 0, topology change 0, notification 0, aging 300
 Port 21 (FastEthernet0/19) of VLAN0001 is root forwarding 
   Port path cost 19, Port priority 128, Port Identifier 128.21.
   Timers: message age 37, forward delay 0, hold 0
   BPDU: sent 395, received 891
Sw3#sh span vlan 1 det | in Port|Timers|BPDU
  Timers: hello 0, topology change 0, notification 0, aging 300
 Port 21 (FastEthernet0/19) of VLAN0001 is root forwarding 
   Port path cost 19, Port priority 128, Port Identifier 128.21.
   Timers: message age 38, forward delay 0, hold 0
   BPDU: sent 395, received 891

Conclusion –

Study the very first show output and compare it to the one directly after removing the BPDUfilter.

Two important things – Message age of the BPDU jumps to 30 and send and received BPUD counts increase by 1.

Analysis – As soon as the filter is removed, Sw3 sends an inferior BPDU to Sw2. Sw2 sees this and relays the stored BPDU from its root port. This explains the increase of 1 in the BPDU counts and the message age on Sw3 jumping from 0 to 30, impossible under normal circumstances.

In a short follow-up post, the same verification will be performed using IOS debugs.

2 responses to “Classic STP (802.1D) Exception BPDU Generation

  1. the usage of deductive reasoning to extrapolate the existence of exception BPDU processing in IOS is pure genius. I came to the complete opposite conclusion while doing my studies accepting the regular BPDU rx and tx debugs as asbofacto while failing to pay attention to the details of the debugs, and not designing a work upon plan of attack to see the solution (like it ws done here with the bpdufilter).

    bar none the smartest most original thing you have done yet (other than the 2 CCIEs!)

    J

  2. Very nice one.
    As a CCIE I was not aware of that one 🙂
    Thank you very much for the explanation 😀

Leave a Reply

 

Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.

 

Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.

 

John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.