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.