For an OSPF adjacency to form some parameters must match:
Belong to same IP network
If area is stub/NSSA
So why is it a requirement for the MTU to match? Imagine that Router A has a MTU of 1500 bytes, Router B has a MTU of 9000 bytes. Depending on the number of links in the network it is possible that Router B would send router LSA or LSU that will exceed 1500 bytes.
From RFC 2328:
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.
If the MTU does not match the adjacency will not form. This OSPF provides a check for both data plane and control plane. By ensuring MTU is same the path will be able to be used by end hosts with a consistent MTU. Normally Path MTU Discovery (PMTUD) should be used for hosts to provide this check and avoid fragmentation but sometimes ICMP may be filtered.
From control plane perspective it keeps OSPF from breaking in such situations where a router would send larger LSA/LSU than the neighbor can accept. So if Router B sends LSA/LSU that is for example 3000 bytes. Then Router A can not accept this packet which means that synchronization can't occur. If you configure ip ospf mtu-ignore what happens is that OSPF ignores MTU as part of the state matchine checking if to form adjacency. The adjacency will then form but there may be other issues later. Many people believe that this is the solution but it may still be an issue when synchronizing the database.
The proper fix is to ensure that MTU is consistent between adjacent routers.
In my case mtu does match, ospf neighborship - stuck in loading state, but ip ospf mtu-ignore helps resolve this issue and neighborship become full. I can't understand why this command help me in my case?
Daniel is absolutely correct - if the ip ospf mtu-ignore interface command helps then you do have an MTU problem.
I suggest verifying the IP MTU of the interfaces using the show ip interface command. Also, debug ip ospf adj is helpful. Watch for messages such as:
*Mar 1 00:02:29.151: OSPF: Rcv DBD from 10.255.255.2 on FastEthernet0/0 seq 0x1B4B opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART
*Mar 1 00:02:29.155: OSPF: Nbr 10.255.255.2 has larger interface MTU
*Mar 1 00:02:10.263: OSPF: Rcv DBD from 10.255.255.1 on FastEthernet0/1 seq 0xA6C opt 0x52 flag 0x7 len 32 mtu 1400 state EXSTART
*Mar 1 00:02:10.263: OSPF: Nbr 10.255.255.1 has smaller interface MTU
Notice the MTU indicated in the debug message: one router advertises an MTU of 1500 bytes, the other advertises MTU of 1400 bytes. OSPF will refuse to create a full adjacency to this router until either MTU mismatch is resolved, or the ip ospf mtu-ignore is used.
It could be a bug; probably the MTU is configured the same between the routers but what is actually received in the packets could be different, try doing some debugs and taking packet captures to see if everything is alright.
If ospf is stuck in loading state it is highly likely because of some corrupted LSA.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...