Spanning Tree Exercise and Revisiting Root Guard

This was actually spurned from a comment I received on another one of my blog posts that you can find here.  Seeing that comment, I white boarded it and realized that I may have been completely wrong in regards to how Root Guard could “break a network”. 

Let’s say we have the following topology:

• Core 1 is the root for VLAN 10 with a configured priority of 4096, and is the secondary root for VLAN 20 with a configured priority of 8192.  We alternate this with Core 2 in order to load balance VLAN traffic.
• Access 3 and 4 are left in default configuration regarding spanning tree.
• Two workstations are present – one in VLAN 10, and another in VLAN 20.  Their default gateways are SVIs that are on the Core switches.
• For simplicity, switch MAC addresses are the number contained in their names.  Example: Access 4’s MAC address is “4”.
• All link costs are the same.
• All links between switches are trunks transporting all VLANs.

Let’s work through the spanning tree topologies.

Core 1 – Root bridge for VLAN 10.  All ports designated.

Core 2 – Port 1 will be a root port due to lowest cost to root. Since the cost to reach root for Core 2, Access 3, and Access 4 are equal, and a root port exists, ports 2 and 3 will be designated due to Core 2 having the lowest bridge ID (STP tie-breaker).  We know this by calculating the bridge IDs:

• Core 2  - MAC Address (2) + VLAN ID (10) + Priority (8192) = 8204
• Access 3 – MAC Address (3) + VLAN ID (10) + Priority (32768) = 32781
• Access 4 – You get the idea.

Access 3 and 4 – Port 1 will be the root port leaving port 2 as blocking since there are already designated ports on those links belonging to Core 2.

VLAN 10	Port 1	Port 2	Port 3
Core 1	Designated	Designated	Designated
Core 2	Root	Designated	Designated
Access 3	Root	Blocking	N/A
Access 4	Root	Blocking	N/A

And for VLAN 20:

VLAN 20	Port 1	Port 2	Port 3
Core 1	Root	Designated	Designated
Core 2	Designated	Designated	Designated
Access 3	Blocking	Root	N/A
Access 4	Blocking	Root	N/A

Now we can see how traffic will flow from each workstation to each other.

VLAN 10 Workstation to VLAN 20 Workstation:

1. Traffic leaves VLAN 10 Workstation and hits VLAN 10 SVI on Core 1
2. Multilayer switched to VLAN 20 within Core 1.
3. Hit Core 2 since the link directly to Access 4 is blocked on VLAN 20.
4. Traverse Access 4 to reach VLAN 20 Workstation.

And now we move to the million dollar question from my previous blog article.  Let’s say we have Root Guard configured on ports 2 and 3 on both Core 1 and Core 2.  What happens when we lose the link between the Core switches? First it may warrant to discuss what happens without Root Guard in place:

Core 1 – Root bridge for VLAN 10 – all remaining ports remain designated.

Core 2 – Since the cost to root is the same going through either Access 3 or Access 4, port 2 will transition to a root port due to, again, Access 3 having the lowest bridge ID. Port 3 will transition to a blocking state since Access 4 now has the lowest cost to reach root for that link.

Access 3 – Port 1 remains a root port.  Port 2 transitions to a designated port since Access 3 has the lowest cost to reach root on that link.

Access 4 – Port 1 remains a root port.  Port 2 transitions to a designated port since Access 4 has the lowest cost to reach root on that link.

VLAN 10	Port 1	Port 2	Port 3
Core 1	Down	Designated	Designated
Core 2	Down	Root	Blocking
Access 3	Root	Designated	N/A
Access 4	Root	Designated	N/A

And for VLAN 20:

VLAN 20	Port 1	Port 2	Port 3
Core 1	Down	Root	Blocking
Core 2	Down	Designated	Designated
Access 3	Designated	Root	N/A
Access 4	Designated	Root	N/A

This has some pretty drastic results:

The path for the blue Workstation to the red Workstation is pretty straight-forward.  But check out the path from the red Workstation to the blue one:

1. Traffic from the VLAN 10 Workstation hits the VLAN 10 SVI on Core 1 as usual.
2. Multilayer switched to VLAN 20 within Core 1, again, as usual.
3. Here’s where it gets interesting.  The link between Core 1 and Core 2 is physically down, and STP is blocking on port 3 for VLAN 20, so this traffic must go back down to Access 3.
4. Traffic traverses Core 2 and Access 4 before finally reaching its destination.

Now let’s see what happens when we enable Root Guard on Core 1 and Core 2’s ports 2 and 3:

• Core 1 begins receiving superior BPDUs on VLAN 20 on ports 2 and 3, so it places those ports in root-inconsistent.
• Core 2 begins receiving superior BPDUs on VLAN 10 on ports 2 and 3, so it places those ports in root-inconsistent.

VLAN 10	Port 1	Port 2	Port 3
Core 1	Down	Designated	Designated
Core 2	Down	Root-Inconsistent	Root-Inconsistent
Access 3	Root	Designated	N/A
Access 4	Root	Designated	N/A

 

VLAN 20	Port 1	Port 2	Port 3
Core 1	Down	Root-Inconsistent	Root-Inconsistent
Core 2	Down	Designated	Designated
Access 3	Designated	Root	N/A
Access 4	Designated	Root	N/A

Now lets take a look at traffic flow from the red Workstation to the blue:

1. Traffic leaves the VLAN 10 Workstation and hits the VLAN 10 SVI on Core 1
2. Multilayer switched to VLAN 20 within Core 1
3. Uh oh – port 1 is physically down and ports 2 and 3 are down for VLAN 20 thanks to Root Guard.  The traffic has no where to go!

Welp – guess I wasn’t wrong after all.  This appears to be a corner case scenario because if it were only a single instance of spanning tree there would be no issue.  Even in this scenario, intra-VLAN communication would be fine, but this does break inter-VLAN communication.