Some days back, I was bringing OSPF adjacencyies between two routers, which shown in the below diagram.
The interface configuration for both routers are shown below
The adjacency was not coming up and using “debug ip ospf adj” on R2, I noticed the following message “Nbr 126.96.36.199 has larger interface MTU”. Immediatly I realized that there is an issue with the MTU settings, as all of us recall that MTU should match for the OSPF adjacencies to being established.
Cisco has a great well-known fix for this issue which “ip ospf mtu-ignore“ command. I configure it and the adjacency came up. That is great, right?
Till now, there is nothing new and a question come to your mind why you are writing this article!
The interesting thing was when I jumped to the second router (R1) to configure it with ip ospf mtu-ignore command; I found that the OSPF adjacency already came UP. Strange!! What happened?
To go further, I took the command out from the R2, and clear the OSPF process and start digging deep into the issue to figure out what is going on.
First, I configured the ip ospf mtu-ignore command on the R1, but the adjacency didn’t go UP!
Second, I noticed that R2 is stucking on the EXSTART state but R1 take one further step and stepping on the EXCHANGE state.
Here is the debug output from each of them
So, we can notice that although R1 is receiving the DBD packets from R2 with mismatching MTU, it is sending back a DBD packet with flag 0x2 (declaring that he is slave as MS=0) and with adopted sequence number (seq 0x847) acknowledging the R2 DBD. With this he transits to the EXCHANGE state
At the same time, R2 is ignoring R1 MTUs and keeps retransmitting his BDB packets which are stuck in EXTART state.
This loop continues indefinitely, which prevents either router from transitioning out of the exstart/exchange state.
Now, we can link both observations together, configuringip ospf mtu-ignore on R1 is not solving the issue as he is already accepting R2 DBD packets while configuring the same command ONLY in R2 solve the problem as we are telling him to ignore the MTU from the other side, so he can accept the DBD packets from R1 and transit from EXSTART state.
The question now is why R1 is accepting the DBD packets with mismatching MTUs!!! The OSPF RFC2328 answer this question:
“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.”
So here is the key!
The OSPF adjacency will not come up in mismatching MTU scenario because that the router will reject the DBD packet with larger MTU that what he can accept on his interface, because of this R2 was rejecting the DBD packets from R1 and saying that “Nbr 188.8.131.52 has larger interface MTU”
And because of this ip ospf mtu-ignore is only needed on the router has the lower MTU.
An Alternative to “IP OSPF MTU-IGNORE”
Actually, if we consider a scenario where R1 is a Cisco switch, we can use an alternative solution to ip ospf mtu-ignore, which is “system mtu routing 1490”. That will enable switch to still use a SYSTEM-MTU as needed, but for routed traffic (ie the ospf) the switch will use a MTU of 1490.
But just consider the following notes about this command:
– It is not interface specific like ‘ip ospf mtu-ignore’, it is applied globally on the switch.
– The routing MTU cannot exceed the SYSTEM-MTU. �
– Once the SYSTEM-MTU is active, changing the routing mtu does not require a reload.