Subject: [pim] MTU mismatches and routing hangups

From: Tom Taylor <[email-masked]>
Date: Tue, 04 Sep 2012 13:26:01 -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-00.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-00.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

---

From: Anton Smirnov <[email-masked]>
Date: Thu, 06 Sep 2012 16:33:30 +0200

Hi Tom,
    first thing to acknowledge at the beginning of any MTU-related 
discussion is that there is no single MTU, there exists one MTU per 
protocol (on every level of OSI model). To give you an example - IPv4 
MTU is not necessarily the same as IPv6 MTU and they are definitely 
different than MTU for bridged PDUs. So strictly speaking your questions 
are incorrectly formulated. I presume you are talking about IPv4 MTU. 
This distinction is very important when single routing protocol somehow 
handles more than one net protocol. Say, ISIS runs on top of CLNS (and 
thus checks CLNS MTU) but is widely used to route IPv4 (and IPv6).
    The second thing, there exists MTU mismatch by configuration and 
actual MTU mismatch when configuration on both ends is identical but 
datagrams of that size cannot be exchanged (say, due to intermediate 
lower-level equipment on the link or due to software defect etc). So, 
against which one of them do you want to protect?

    In brief - ISIS in its original concept sends MTU-sized Hellos and 
thus can discover actual CLNS MTU mismatches. OSPF communicates 
configured MTU in some packets during exchange with neighbor and thus 
can discover MTU misconfiguration (OSPFv2 - IPv4, OSPFv3 - IPv6). BGP 
doesn't have its own MTU mechanism and relies on TCP's path MTU discovery.
    All routing protocols are bad in handling MTU mismatches for network 
protocol other than their native one.

    And finally my personal take - PIM shouldn't try to discover MTU 
mismatch.

Anton

On 09/04/2012 07:55 PM, Tom Taylor wrote:
> draft-lts-pim-hello-mtu-01.txt was inspired by customer reports of
> MTU size. The proposal in draft-lts-pim-hello-mtu-01.txt was for
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>