Sometimes things are just too simple to see. It appears a left over MTU statement on a gig sub-int prevented an OSPF neighborship to come up. The software on the 7304 was SBC (One of the new Broadband S builds) which required a hard conffed MTU due to dot-1q [mtu 1504] but as QoS was broken there (no CBWFQ/LLQ) I went back to plain 12.2(25)S. This plain S version doesn’t require MTU to be hard coded and thus I had an MTU of 1504 on the sub-int. OSPF has this info in its hello’s so the neighborship would keep bouncing with the notification that too many retransmits had happened.

Pretty annoying to have OSPF not tell you what’s really going on. Especially as a ping with df bit set at 1500 was fine and I saw no errors at all in the path between the two devices. At least IS-IS prevents a neighborship to come up when there’s an MTU problem in the path. The first packets IS-IS sends are padded to (nearly) full MTU for that interface. Then once the neighborship is up the padding is removed as per (non default) configuration.

I found out IS-IS worked this way after setting MTU to 1600 for MPLS and leaving it set to 1500 on the other side. I could send 1500 byte frames either way, even VPNV4, but the IS-IS neigborship did not recover onze it went down. A debug showed the first frames to be 1573 bytes in size…

Categories: CCIE R&S
Comments Off on OSPF & i/f MTU