Let’s create a simple area 0 point-to-point adjacency between the two routers and make R1’s MTU slightly larger. Then ignore OSPF MTU otherwise the adjacency will not come up:
R1 interface GigabitEthernet1/0 mtu 2000 ip address 10.0.0.1 255.255.255.0 ip ospf network point-to-point ip ospf mtu-ignore ip ospf 1 area 0
The adjacency is fine as far as we can see:
R1#sh ip ospf neighbor | beg Nei Neighbor ID Pri State Dead Time Address Interface 22.214.171.124 0 FULL/ - 00:00:30 10.0.0.1 GigabitEthernet1/0
Now I’ve added 256 loopback interfaces onto R1 and put them all into OSPF by using network 0.0.0.0 0.0.0.0 area 0. This means all those loopback interfaces will be part of the type1 LSA originated by R1. What happens though?
interface Loopback1 ip address 126.96.36.199 255.255.255.255 ! interface Loopback2 ip address 188.8.131.52 255.255.255.255 ! interface Loopback3 ! [etc etc etc] ! router ospf 1 network 0.0.0.0 0.0.0.0 area 0
At first, nothing seems wrong. But take a look at the database from R1 and R2’s perspective. Remember the database should be identical.
R1#sh ip ospf database OSPF Router with ID (184.108.40.206) (Process ID 1) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 220.127.116.11 18.104.22.168 33 0x80000005 0x00767B 257 10.0.0.2 10.0.0.2 100 0x80000011 0x00C816 2
R2#sh ip ospf database OSPF Router with ID (10.0.0.2) (Process ID 1) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 22.214.171.124 126.96.36.199 130 0x80000004 0x00856D 2 10.0.0.2 10.0.0.2 128 0x80000011 0x00C816 2
R1 sees a link count of 257 for R1s router LSA, while R2 only sees 2. This can be confimred by seeing that R2 doesn’t have any OSPF routers to R1’s loopback:
R2#sh ip route ospf | beg Gate Gateway of last resort is not set
If you wait a while you’ll see LOADING on the adjacency too. And eventually the adjacency resets and tries again:
R2#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 188.8.131.52 0 LOADING/ - 00:00:32 10.0.0.1 GigabitEthernet1/0 R2# *Feb 6 19:11:26.958: %OSPF-5-ADJCHG: Process 1, Nbr 184.108.40.206 on GigabitEthernet1/0 from LOADING to DOWN, Neighbor Down: Too many retransmissions
So what exactly is happening? If you check Wireshark you’ll see the issue straight away
OSPF does not do any sort of path MTU discovery. R1 is attempting to send a type1 LSA and it’s using an MTU size of 2000. R2 cannot receive that large a frame and so those fragments get dropped. R2 never acknowledges the LSA as it’s not receiving anything, and eventually that causes the adjacency to reset. This then continues over and over.
This could be hidden though. Let’s stop R1 advertising all those addresses via it’s type1 LSA and instead redistribute the links into OSPF:
R1(config)#router ospf 1 R1(config-router)#no network 0.0.0.0 0.0.0.0 area 0 R1(config-router)#redistribute connected subnet R1(config-router)#end R2#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 220.127.116.11 0 FULL/ - 00:00:38 10.0.0.1 GigabitEthernet1/0 R2#sh ip route ospf | beg Gate Gateway of last resort is not set 18.104.22.168/32 is subnetted, 255 subnets O E2 22.214.171.124 [110/20] via 10.0.0.1, 00:01:14, GigabitEthernet1/0 O E2 126.96.36.199 [110/20] via 10.0.0.1, 00:01:14, GigabitEthernet1/0 O E2 188.8.131.52 [110/20] via 10.0.0.1, 00:01:14, GigabitEthernet1/0 O E2 184.108.40.206 [110/20] via 10.0.0.1, 00:01:14, GigabitEthernet1/0 O E2 220.127.116.11 [110/20] via 10.0.0.1, 00:01:14, GigabitEthernet1/0 O E2 18.104.22.168 [110/20] via 10.0.0.1, 00:01:14, GigabitEthernet1/0 O E2 22.214.171.124 [110/20] via 10.0.0.1, 00:01:14, GigabitEthernet1/0 O E2 126.96.36.199 [110/20] via 10.0.0.1, 00:01:14, GigabitEthernet1/0 O E2 188.8.131.52 [110/20] via 10.0.0.1, 00:01:14, GigabitEthernet1/0 [etc]
This time it works, even with a mismatched MTU. Why? A type 5 LSA only has space for a single address. This means that R1 originates 255 type 5 LSAs and each of those LSA are much much smaller than 2000 bytes. This means that the LSA updates are not bigger than 1500 bytes and so we never have R2 dropping any of those packets.
A router only originates a single router LSA, and that single LSA has to contain all the interface addresses for that router that is enabled for OSPF in the area. If a router has 1000 interfaces, well that’s a large type1.
You can see the individual type5s in the database itself:
R2#sh ip ospf database | beg External Type-5 AS External Link States Link ID ADV Router Age Seq# Checksum Tag 184.108.40.206 220.127.116.11 390 0x80000001 0x00692A 0 18.104.22.168 22.214.171.124 390 0x80000001 0x005F33 0 126.96.36.199 188.8.131.52 390 0x80000001 0x00553C 0 184.108.40.206 220.127.116.11 390 0x80000001 0x004B45 0 18.104.22.168 22.214.171.124 390 0x80000001 0x00414E 0 126.96.36.199 188.8.131.52 390 0x80000001 0x003757 0 184.108.40.206 220.127.116.11 390 0x80000001 0x002D60 0 18.104.22.168 22.214.171.124 390 0x80000001 0x002369 0 126.96.36.199 188.8.131.52 390 0x80000001 0x001972 0 184.108.40.206 220.127.116.11 390 0x80000001 0x000F7B 0 [etc etc]
Out of interest, type3, type4, type5, and type7 LSAs all follow the ‘single address per LSA’ model and as such should never be that big. A type2 LSA will expand to reflect the amount of routers on the layer 2 segment, but I find it hard to believe that there would be over 100 routers on a single segment (though not impossible)
By the way, I wrote a separate post explaining a few more in-depth spf considerations when it comes to type1s and type5s over here: OSPF – Type 1 LSA vs Type 5 LSA (passive vs redistribute)
So there you have it. Ignore the MTU at your own peril. Rather fix the MTU issue than just ignoring it. It’s something that might not be an issue ‘now’ but as your router LSA grows in size you suddenly run into a problem.