Subject: [OSPF] MTU mismatches and routing hangups

From: Tom Taylor <[email-masked]>
Date: Tue, 04 Sep 2012 13:55:49 -0400

PLEASE NOTE THE CROSS-POSTING when responding. Please direct responses 
to the authors and the PIM WG only, so the broader community doesn't get 
bombarded with responses. This message is also being sent to the 
Routing-Discussion and ISIS WGs.

draft-lts-pim-hello-mtu-01.txt was inspired by customer reports of 
multicast routing hangups caused by MTU mismatches at the two ends of a 
link. The end with the larger MTU sends a message within its MTU size 
that is discarded at the other end because it is larger than that end's 
MTU size. The proposal in draft-lts-pim-hello-mtu-01.txt was for 
adjacent routers to exchange information on their MTUs on each link, 
then restrict message sizes to the smaller of the MTUs.

Working Group discussion in Vancouver raised the obvious question: do 
MTU mismatches cause problems for other routing protocols? And do any of 
these protocols have a solution to the problem?

I raised the issue of the effect of MTU mismatches on the NANOG list.
There were quite a few responses. Amongst other comments:

- OSPF hangs at a particular point in the state machine and fails to 
come up. Debugging can take a while if you don't think of MTU mismatch 
as a possible cause.

- Cisco has published a note on the subject, to be found at

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f0d.shtml
(sorry about the wrapping).

- BGP can hang after a link flap when two specific products [identities 
omitted] are at the two ends of the link and the configured MTUs are 
identical, because one end includes the ethernet overhead and the other 
doesn't.

- a good MTU debugging tool can be found at
    http://www.elifulkerson.com/projects/mturoute.php

This message is written to ask the broader routing community what, if 
anything, routing protocols should do about identifying MTU mismatches, 
and beyond that, accommodating them. As requested above, please direct 
responses to the authors and the PIM WG only.

Tom Taylor