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.

OSPF Adjacency Building Process

Ever curious regarding how two routers configured for OSPF become fully adjacent?  The following diagram of the process was modeled directly from RFC 2328, and the steps described gleaned from the Routing TCP/IP Vol I book.  Since we can see mention of a DR, this example must be based on a multi-access network.

1. RT1 becomes active and sends a Hello.  At this point, RT1 hasn’t seen any neighbors, so it reports such and sets its DR and BDR fields to 0.0.0.0.
2. Upon receipt by RT2, RT2 will build a data structure for RT1 and set RT1’s state to Init.  RT2 will then send a Hello packet reporting that it has seen RT1, and will report itself as the DR.
3. RT1 now sees its own RID in the received Hello packet from RT2, so RT1 will now create a data structure for RT2 and set its state to ExStart.  RT1 then begins Master/Slave negotiation with a DD packet with a sequence number of “x”, the Init bit set  to indicate that it is the start of an exchange, the More bit set to indicate that it is not the last DD packet to be sent, and lastly with the MS-bit set to indicate that RT1 wants to be the Master.  No LSA summaries are provided just yet – this is purely for Master/Slave negotiation.
4. Upon receipt of RT1’s DD packet, RT2 sets RT1’s state to ExStart.  RT2 then sends a DD with a sequence number of “y”, and the MS-bit set since RT2 has a higher RID in this example.
5. RT1 agrees that RT2 is the Master and sets its state to Exchange. RT1 informs RT2 of its agreement by sending a DD packet with a sequence number “y” that matches what was sent from RT2 in step 4.  The MS-bit will now be set to 0, and here is where we’ll start to see LSA summaries provided by RT1.
6. RT2 now sets RT1’s state to Exchange as well and sends a DD packet containing LSA headers from its Link State Summary list and increments the DD sequence number to “y+1”.
7. RT1 acknowledges this by sending an acknowledgement with the same sequence number that it received in the DD packet from RT2.  It also begins taking the LSA summaries it received and building a Link State Request list.  This process repeats until RT2 sends the last of its LSA summaries and sets the More bit to 0.
8. Once RT1 receives the last of RT2s LSA summaries and acknowledges it knowing that it has sent the last of its own LSA summaries, the Exchange state process is complete.  Now RT1 will begin processing the LSA summaries it has added to its Link State Request list and transition to the Loading state.
9. Once RT2 receives RT1’s last DD packet, RT2 then sets RT1s’s state to Full because RT2 has no entries in its own Link State Request list.
10. RT1 will send Link State Requests for all entries in its Link State Request list and RT2 will send Link Sate Update packets until RT1’s list is empty.  At that point, it sets RT2 to Full, and the adjacency is complete.

OSPF Link State Advertisements (LSAs) and Areas – Part II

For a table describing the different LSA types, check out the first post of this series.

In the first part of the series, we looked at LSA Types 1, 2, and 3 – Router, Network, and Network Summary, respectively.  To move on to the next two LSA types, we need to bring in another Autonomous System (AS).  In the diagram below, we’ve added R5 which has an interface in EIGRP AS 1, and is redistributing that into OSPF Area 4.  The fact that R5 has an interface inside of the OSPF AS, as well as the EIGRP AS, makes R5 an Autonomous System Boundary Router (ASBR). 

The EIGRP-oriented subnet that is being redistributed is considered an external route to the OSPF domain, so a Type 5 LSA, or ASBR External, is flooded into OSPF Area 4 containing a LSID and netmask of the subnet, plus the External Type. This important because it tells other routers whether or not to add the internal link costs within the OSPF domain to the metric to reach that subnet.  A type 2 external route specifies that only the external cost is taken into consideration.

When R2 catches wind of this, it will generate a Type 4 LSA, or ASBR Summary, and flood it into Area 0 as well as the Type 5 LSA.  The contents of the Type 4 LSA are mostly just the LSID of the ASBR’s RID and the metric reach it.

For  other routers to reach this External Type 2 route, they just take metric provided in the Type 5 LSA (20) – no questions asked.

However if it were an External Type 1 route, each router must determine its cost to reach it taking into account the link costs along the way.

So in this example, if R1 needed to reach 172.16.5.0/24 as an External Type 1 route, it would first add the cost to reach R2 (The ABR) [Similar to what it would do to determine cost to an intra-area (IA) route utilizing a Type 3 LSA] to the cost to reach the ASBR as listed in the Type 4 LSA.  Finally, it would then add the cost listed in the Type 5 LSA for that subnet.

Cost to reach ABR (1) + Cost to reach ASBR (2) + Cost in Type 5 LSA (20) = 23

Stubby.. Totally Stubby… Not-So-Stubby… Totally Not-So-Stubby….

While there are several iterations of a stubby area, with varying mechanics behind them, they all serve mostly a single purpose – to reduce overhead.

  

Once R6 is added and area 6 is configured as a stubby area, two major things happen:

• R3 (An ABR for area 6) will still receive, but stop flooding Type 5 LSAs into area 6.  Notice that R6’s routing table does not include R5’s EIGRP-oriented subnet (172.16.5.0/24)
• R3 injects a default route into area 6

So we can see here that the logic is, hey, there’s only going to be one way to get out of this area, so let’s reduce the size of the LSDB and make things easier by just injecting a default route into the area and calling it a day.  Imagine if R5 had 100 subnets hanging off of it in the EIGRP AS – if R6 wasn’t in a stubby area, those 100 routes would be added to its LSDB and in the routing table.  Why do that if we can just inject a default route and not advertise these external routes into the area – effectively accomplishing the same thing?  If R6 needs to hit any of these external routes, it just uses the default route to the ABR who knows how to get there, and greatly reduce the size of R6’s LSDB and routing table all at the same time!

A “totally” stubby area takes this concept even further by also not flooding Type 3 LSAs.  What’s kind of interesting about that statement though is that the default route R3 injects into the stubby area is a Type 3 LSA.

A Not-So-Stubby Area (NSSA) simply allows you to redistribute external routes if needed.  A special type of LSA is used in this situation – a Type 7, or NSSA External.

This will be generated by the now ASBR, R6, who is redistributing its connected 192.168.6.0/24 subnet.  As depicted above, once it reaches the ABR, R3, it will convert this LSA into a Type 5 before flooding it into area 0, so you will only see Type 7 LSAs in a NSSA.

 

 

Exploring OSPF Messages in a Multi-access Network

 

The following network is configured with OSPF with all interfaces in area 0.  Since this is a multi-access network, a Designated Router (DR) is elected which improves OSPF performance by reducing the amount of LSA flooding. R3 is the current DR, with R2 as the BDR.  R4’s interface to SW1 has been configured as a passive interface to prevent an adjacency from forming and simulate R4 being a “new” router on the network.  Wireshark is monitoring the link between R4 and SW1.

I won’t go into all the details regarding Wireshark output and the OSPF process.  If you want a more detailed analysis, take a look at my previous blog article here.  In this article, we’ll only be taking a closer look at what happens specifically in a multi-access environment.

Upon re-enabling R4’s interface for OSPF, we see R4 sends a Hello packet to the All OSPF Routers multicast address (224.0.0.5) and that no DR or BDR is listed.  R4 is “new” to the network as far as OSPF is concerned, so it has no idea about the current topology.

R1, R2, and R3 all send Hello packets with the routers they have seen, which now includes the newly added R4. It also provides information regarding the established DR and BDR.  Since there is already an established DR/BDR, R4 will not attempt to participate in an election or usurp the current DR/BDR.  Also note that this Hello packet, and the communication that follows afterward between R4 and routers R1, R2, and R3 is unicast – not multicast.

What follows next are the usual Database Descriptor (DD) packets utilized to establish Master/Slave relationships, followed by the exchange of summarized LSAs.  Notice that this communication is only occurring between R4 and routers R2 and R3 – the BDR and DR, respectively.  Communication between R4 and R1 stops after they have reached the 2-way state, since R1’s role in this environment is DROther (Not the DR or BDR).  

Of interest in this scenario is the Network LSA provided by R2 and R3 in addition to the usual Router LSAs.  This is a type 2 LSA that represents a subnet where a DR has been elected.  Notice that the advertising router is the DR, and the  Link State ID is the DR’s IP address on that subnet.  An interesting note is that the SPF process treats this as an individual node in its “mathematical model”, so this type of LSA is sometimes referred to as a pseudonode.

Since R4 will attempt to establish full adjacency with R2 and R3, R4 follows the usual process of requesting full LSAs from R2 and R3 for any LSAs it does not already have or that it may have but are not up to date.  In addition, R2 and R3 will request at least R4’s Router LSA since they will obviously not have it. Once this process completes, R3 as a DR will send LSA Updates to the All OSPF Routers multicast address. In the picture below, R3 advertises R4’s Router LSA.  This will in turn update R1 – the DR acts as a relay of sorts for updates in the OSPF environment.

R4 will acknowledge the update utilizing the unicast IP address of the DR, mirroring the LS Sequence number.  R4 has an updated LSA however, so it reports this to the DR utilizing the All OSPF DR Routers multicast address, 224.0.0.6. Notice the updated LS Sequence number.

R3 then provides the updated LSA to the rest of the world, acknowledgements are sent back, and everything settles into place.

Looking at the capture, there are two points I’m a little confused on. 

In one packet, R4 sends an acknowledgement using 224.0.0.6, and there are two Network LSAs contained within. Why are there two of the same network LSAs with different LS Seq numbers in the same LS Acknowledge?

Another is that I see LS Acknowledgements sourced from R4 to the unicast address of the DR, as well as to the multicast address 224.0.0.6.  What determines when an LS Acknowledgement is sent to the DR unicast address or to the multicast address?

To be continued….

OSPF Link State Advertisements (LSAs) and Areas – Part I

If every router in an enterprise environment was in a single OSPF area, at some point you’re going to encounter scalability issues due to any changes in the environment causing an SPF recalculation in all routers in that single area.

LSAs and their use within areas provide a mechanism for maximizing performance in OSPF by logically segmenting groups of contiguous links so that every router in the entire autonomous system does not have to have exact copies of the Link State Database (LSDB) and to reduce the amount of LSA flooding.  SPF calculations are also isolated to each individual area rather than the entire environment.  Different LSAs are used in different situations, and are treated differently depending on the type of OSPF area involved.

The following table represents the different LSA types, and was taken from the CCIE R&S OCG.

TYPE	NAME	DESCRIPTION
1	Router	One per router containing its RID and all interface IP addresses; also represents stub networks.
2	Network	One per transit network.  Created by the DR and represents the subnet and router interfaces connected in the subnet.
3	Network Summary	Created by Area Border Routers (ABRs) to represent one area’s type 1 and 2 LSAs when being advertised into another area.  This also defines the links (subnets) in the origin area, and cost, but no topology data.
4	ASBR Summary	Similar to a type 3 LSA, but it advertises a host route to reach an Autonomous System Boundary Router (ASBR)
5	AS External	Created by ASBRs for external routes injected into OSPF
6	Group Membership	Used for Multicast Open Shortest Path First (MOSPF).  This is an extension to OSPF that allows multicast routing, allowing routers to share information about group memberships.  This is not supported by Cisco.
7	NSSA External	Created by ASBRs inside of a NSSA area instead of a type 5 LSA.
8	External Attributes	Not implemented in Cisco routers.
9-11	Opaque	Used as generic LSAs to allow for easy future extension of OSPF; as an example, type 10 has been adapted for MPLS traffic engineering.

The diagram below depicts a simple point-to-point network with all interfaces within the same area.

In this situation, there will only be Type 1 LSAs exchanged between routers.  The LSA will contain the RID of the advertising router, connected links (subnets), and the RIDs of any other routers it has seen. Below is Wireshark output taken from a different network than the one diagrammed above. The link types seen here are:

• PTP – Point-to-point connection
• Stub – a subnet on which a router has not formed any neighbor relationships
  • *QUESTION* The CCIE R&S OCG defines a stub network this way, but Wireshark packet capture lists connected subnets that HAVE formed neighbor relationships as stubs… what gives?  The entries that contain the RIDs of the other routers are listed as PTP and the loopback of the advertising router is listed as a Stub
    • *ANSWER* SPF treats these two “stub” entries as  separate data structures from the PTP entries that actually specify the connected neighboring router.  The more important of the two entries is the PTP entry. I don’t know exactly what that means, but I’ll push the “I Believe” button for now.

When we talk about a multi-access environment, a DR is elected and here is where we can expect to see a Type 2 LSA – a Network LSA. 

 

This type of LSA is  generated by the DR and describes the subnet as well as the RIDs of the DR’s connected neighbors.  The Link State ID will be the interface IP address of the DR within that subnet.  It may seem odd that it lists itself as an attached router.  This is because this LSA is treated as a pseudonode – not an actual physical device, but a logical node on the SPF mathematical model.  So think of it as a separate entity from the actual physical router that is the acting DR.

You will find Type 1 and 2 LSAs inside of a single area.  These are the most computation-intensive LSA types and they do not traverse areas.  When you bring in multiple areas, this is where you encounter a Type 3 – a Network Summary LSA.  Since R2 now has interfaces in two areas – area 0 and 4, it is now an Area Border Router (ABR).

This type of LSA is created by ABRs to represent subnets that the ABR can reach.  Notice that it not only contains its directly connected subnets in area 4, but also the route it learned from R4.  The nice thing about this is that a router, for example R3, doesn’t have to run the SPF algorithm for these routes.  All it does is add its cost to reach the ABR, to the metric value gleaned from the LSA from the ABR.  So in this case, the cost for R3 to reach 192.168.4.0 would be 3 (1 for the cost of R3’s fa0/0 interface, plus 2 for the metric advertised in the Type 3 LSA).

If you haven’t picked up on it already, an interesting note is that this is distance vector behavior because R3 in this example depends on R2 to tell it the metrics to reach routes in area 4 instead of R3 determining the cost on its own.  So OSPF is a link state routing protocol, but when it comes to inter-area operations it uses a distance vector algorithm.  Pretty cool.  Something I found out from the TCP/IP Routing Vol I book is that this is the reason why there is a backbone area and that all areas must be connected to it.  This essentially creates a hub-and-spoke topology and prevents the route-loops that distance vector protocols are so vulnerable to.

Continue to Part II.

Exploring OSPF Messages Between New Neighbors

A basic network is setup and OSPF is configured.  R1 is then prevented from forming an OSPF adjacency with R2 due to R1’s serial interface being configured as a passive interface.

Only Hello packets are seen from R2.

From this Wireshark output we can see:

1. OSPF Version 2 is utilized
2. This is a Hello packet
3. The Hello packet is sourced from a router with OSPF Router ID 2.2.2.2.  Duplicate RIDs will prevent an OSPF adjacency and cause other issues.
4. The interface that sourced this Hello packet resides in OSPF area 0.  This item is used to verify that the two connected router interfaces are within the same OSPF area – this is a requirement in order to form an OSPF adjacency.
5. No authentication is used
6. A /30 network mask is used on R2’s connected interface.  This item is used to verify that the two connected router interfaces are using the same subnet mask, which is a requirement in order to form an OSPF adjacency in addition to the two interfaces being within the same primary subnet.
7. Hello and Dead timers.  These must be the same on both connected routers in order to form an OSPF adjacency.
   1. Hello is set to the default 10 seconds
   2. Dead is set to the default 40 seconds
8. The configured router priority is the default of 1.
9. An active neighbor is listed.  This was due to the fact that an adjacency existed before I set the interface to passive, and the dead timer hadn’t expired yet on R2.  This line will disappear in subsequent Hello packets once the timer on R2 expires and it drops the now broken adjacency.

Also, notice that the OSPF process-id is not included in the Hello packet.  This is because the process-id is only locally-significant.

So now, let’s re-enable R1’s s1/0 interface as an active OSPF interface.

As the neighborship begins to form and the LSDB exchange process starts, the first thing we see is a Hello from R1 while it is in the Init state.  R2 then sends a hello that indicates it has seen R1.  This means R2 is now in a 2-way state.

The next two packets appear to be a negotiation between the two routers to determine who will be the master and slave in the relationship, as they both have the master bit set, and no LSA headers.  I also noticed that the Init bit is set in both of these DD packets.  I believe this would equate to the ExStart state.

 

The next two packets indicate that R2 is the master, which it should be due to the higher RID.  Also notice the Init bit is no longer set, and LSA Headers are provided.  The LSDB Exchange has started.

 

These LSAs are Router LSAs and do not contain any in-depth information such as the actual links contained within them. An important thing to note is the LS Sequence number.  A router uses this to see if a) it already has this LSA and b) if the LS Sequence number is later than the received LSA’s.  If the received LSA’s sequence number is later than the LSA it has in its database, the router assumes the received LSA is more recent, and will in turn send a LS Request to get a full copy of that LSA.

Now that both routers have a list of LSAs that their neighbor has, LS Requests are sent to retrieve the full LSAs for any that they do not have locally, or LSAs that their neighbor has a more recent version of (Again, going off the LS Sequence number). This is the Loading state.

 

LS Updates are sent in return with full information regarding the requested LSA.  Here we see R1 send its Router-LSA (LS ID 1.1.1.1) with sequence number ending in 04. R2 sends its Router-LSA (LS ID 2.2.2.2) with sequence number ending in 03.  Both of these LSAs contain the links and metric that each respective router has at that point in time.  These LSAs will then be locally updated with the new information, and their sequence numbers incremented.  Also, LS Acknowledgements are sent to tell each router that their LS Updates were received successfully by mirroring the previously-received LS Sequence number. 

  

The next LS Updates are sent out containing their previous information in addition to the updated links that were newly added by the previous LS Updates.  Notice the incremented LS Sequence numbers.

 

LS Acknowledgements are sent, LSAs and their LS Sequence numbers now  match – all is good.  These neighbors are now fully adjacent.

Late Night fun with a Meme Generator

I was watching a movie the other night with my wife and decided to hop on memegenerator.net and play around with memes.  Thought I’d share my creations.