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