Wednesday, October 23, 2013

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:

image

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

image

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:

image

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:

image

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

No comments:

Post a Comment