Using Checksum in determining the newer LSA


RFC 2328 Section 13.1 explains what a router must do when it encounters two similar instances of an LSA (i.e. the two LSAs are of the same LS type, have the same Link State ID, Advertising Router and the LS Sequence Number) and it needs to determine which of the two LSAs is more recent.

Since the two LSAs have the same sequence number RFC 2328 suggests examining the checksums. The instance having the larger LS checksum is considered more recent.

Now, the question is that how can we be sure that the more recent LSA will necessarily have a higher checksum? The answer is that we cant! Its just done this way to ensure that all routers in the network arrive at the same decision. OSPF would have converged even if the algorithm was to pick the LSA with a lower checksum!

So, how does it work?

The LS checksum is computed over the entire contents of the LSA, excepting the LS age field. This is left out so that the LSA’s age can be incremented without updating the LS checksum. Its used primarily to detect data corruption of an LSA. Its also used as explained above in determining which LSA is more recent.

Its obvious that checksums can only differ if the contents of the LSAs differ. This is possible if a router reboots and floods an LSA that has the same sequence number as the previous LSA it had issued before restarting that still exists in the network.

The purpose of the checksum selection really beyond correct routing and is critical to the detection and elimination of this case. If the LSA issued by the rebooted box has the higher checksum, that information is newer (as per the tie breaking algo specified in the RFC) and will eventually eliminate the earlier version of this LSA. However, if the LSA issued by the rebooted box has a lower checksum, the old version of the LSA is “newer”, and will eventually make it back to the issuing router, which will trump it by reissuing the LSA with a higher sequence number.

If it weren’t for the tie-breaking rule, both LSAs would live in the network until the next refresh (close to 30 mins for OSPF and even longer for ISIS), and long-lived routing loops could result.

Advertisements

About Manav Bhatia

Manav Bhatia is a SDN/NFV dataplane architect at Ionos Networks and has co-authored several IETF standards on routing protocols, BFD, IPv6, security, etc. He is also a member of IETF Routing Area Directorate where he helps the Area Directors review the IETF standards for their impact on the Routing Area. View all posts by Manav Bhatia

4 responses to “Using Checksum in determining the newer LSA

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: