OSPF Packets and Neighbor Discovery

[lagapidis (Lazarus Agapidis)]

Hello David

@davidilles

But the RID is also included in Hello messages, right? so what makes the routers even hit EXSTART in the first place? wouldn’t they realize upon the reception of the hello that the RID is duplicate?

You’re right that the RID is included in the hello messages. Even so, OSPF does not check that the RIDs are unique during that exchange ( wierd right?). The protocol itself, as described in the RFC has no mandate for OSPF to check RIDs during that exchange. Other things are checked during the hello exchange including area IDs, network mask of interfaces (on broadcast/NBMA networks), timers, authentication, and stub area flags. But not the Router ID!

The duplicate RID actually breaks the adjacency during the master/slave election in the EXSTART state, where the router with the higher RID becomes master. If both routers have the same RID, then both claim to be master, neither accepts the claim of the other router to be master, and we get stuck in EXSTART.

Now you may find that some modern devices will detect a duplicate RID in previous states during the hello exchange, making the process more efficient, but the official RFC does not mandate this.

@davidilles

My question is the same with the MTU. Apparently, routers can be stuck in EXCHANGE if the MTUs are mismatched. But MTUs are included in DBDs that are exchanged during EXSTART, so shouldn’t the routers immediately notice the MTU issue?

Actually, MTU is never included in any hello packets. The Interface MTU field only appears in Database Description (DBD) packets. In RFC 2328, section 10.6 it says:

    If the Interface MTU field in the Database Description packet
    indicates an IP datagram size that is larger than the router can
    accept on the receiving interface without fragmentation, the
    Database Description packet is rejected.

Now because OSPF routers don’t send an “MTU mismatch error” message, the DBD is simply silently dropped. This results in the neighbor appearing to be stuck in EXSTART or may flap between EXSTART and EXCHANGE because the DBD exchange cannot be successfully completed.

It’s interesting that the protocol is designed so that the OSPF routers address these particular “issues” or “errors” only when they are functionally used. (RID for the master/slave election, and MTU for packet size validation during DBD exchange). Make sense?

I hope this has been helpful!

Laz