10

If one tries to configure the neighbor adjacencys without matching MTU, The routers fail to become neighbors. I assume this is to protect the routing protocol from it self but I don't understand what it is saving itself from? What would(Could) the consequence be without matching MTU?

Mike Pennington
  • 29,876
  • 11
  • 78
  • 152
Pete
  • 203
  • 2
  • 6
  • Could you please clarify what exact situation you're concerned about that would give you a reason to have mismatched OSPF or EIGRP MTUs? – Mike Pennington Mar 16 '15 at 22:36
  • I can't think of a situation where you would need this. I just wanted to know what the logic was that makes this an explicit check in these routing protocols. – Pete Mar 16 '15 at 22:58

2 Answers2

12

Pete said:

I can't think of a situation where you would need this. I just wanted to know what the logic was that makes this an explicit check in these routing protocols.

Short answer

Routing protocols are some of the most fundamental building blocks on the internet; we need them to be very reliable in every possible case. It does no good to bring up an OSPF or EIGRP adjacency on a mismatched MTU.

Routing protocols must remove any potential mismatched MTUs from the router's forwarding path.

Long answer

I can think of three possible situations where you'd find mismatched IGP MTUs...

  1. Unintentional MTU mismatch at Layer2 (for instance, if someone accidentally mismatched MTUs on a serial line, or different vendors had different default MTUs on the same media)
  2. Matching Layer2 MTUs, but a the router implementation has bug which miscalculates the required interface IP MTU
  3. Intentional MTU mismatch

IP MTUs are directly correlated to Layer2 MTUs (at least for Case 1, above). No matter what we do, we are always at the mercy of mitigating the problems from unintentional Layer2 MTU mismatches, since there is no Layer2 MTU discovery mechanism (unlike IP, which has ICMP error messages).

This means that we have to do everything possible to avoid Layer2 MTU mismatches, even if Cases 2 and 3 above are casualties of mitigating problems with Case number 1. Case 1 has colossal implications unless we solve it; i.e. black-holing all traffic just because we permitted mismatched MTUs.

We're always limited to the least common denominator on the link. Frames larger than the receive MTU of an interface are silently discarded, and the router has no way of knowing whether the MTU was intentionally mismatched, or whether it happened accidentally.

Consequently, EIGRP and OSPF require valid Layer2 adjacencies Note 1 (including MTUs).

What would(Could) the consequence be without matching MTU?

Quoting John Moy (OSPF's author) in RFC 2329 Page 4:

  • Problems with all IP forwarding
  • OSPF Problems

Also quoting him from the OSPF mailing list:

John Moy - OSPF MTU mismatches

Note 1 some people misunderstand the meaning of adjacency as strictly an IP routing protocol concept. This assertion misses the reality that everything (including IP) requires matching layer2 MTUs, for Layer2 domains to work properly.

One of the most important functions of a routing protocol is building a valid FIB / CEF / forwarding table. That table maps the information learned via routing protocols to layer2 rewrite info. Those Layer2 relationships on the same physical link are what Cisco also calls adjacencies.

Community
  • 1
Mike Pennington
  • 29,876
  • 11
  • 78
  • 152
  • Thanks, Mike! I think the part I was missing was that a packet over MTU is fragmented on the sending router but discarded on the receiving router. – Pete Mar 17 '15 at 15:01
  • Not quite, mismatched L2 MTUs are a misconfigurarion that cannot be worked around reliably with existing implementations. All OSPF knows is that the existing IP MTU isn't symmetric, but it has no information about how to fix it. Fragmentation isn't supported in OSPF because that still leaves a broken L2 data plane in Case 1 and OSPF doesn't really even know why there is a mismatch – Mike Pennington Mar 17 '15 at 15:08
5

According to the OSPF RFC 2328 (10.6):

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.

The simple answer is that the standard was designed to just drop datagrams which are too large instead of fragmenting them. Fragmented traffic increases the CPU burden of a device and decreases performance because of the need for the fragmentation needed extra traffic. Considering the goal of a dynamic routing protocol is it be a stable and fast converging protocol, anything contrary to those goals should be eliminated. Setting the requirement for the MTUs to match helps enforce this performance requirement.

More from the OSPF RFC:

4.3.  Routing protocol packets

    The OSPF protocol runs directly over IP, using IP protocol 89.
    OSPF does not provide any explicit fragmentation/reassembly
    support.  When fragmentation is necessary, IP
    fragmentation/reassembly is used.  OSPF protocol packets have
    been designed so that large protocol packets can generally be
    split into several smaller protocol packets.  This practice is
    recommended; IP fragmentation should be avoided whenever
    possible.
Robert
  • 538
  • 2
  • 10
  • 5
    EIGRP and OSPF form layer2 adjacencies and there's no IP / datagram fragmentation on any layer2. So, it's impossible to use mismatched MTUs, even if the standard allowed it. – Mike Pennington Mar 16 '15 at 18:31
  • Negative. They form layer 3 adjacencies, protocol communications occur using IP multicast (layer 3). If they formed layer 2 adjacencies technically you wouldn't need IP addresses on the interface. – Robert Mar 16 '15 at 18:34
  • From the RFC itself: **The OSPF protocol runs directly over IP, using IP protocol 89.** – Robert Mar 16 '15 at 18:37
  • 2
    Robert, you're missing the definition of adjacency that Cisco uses. Please look at "sh adjacency internal" on any Cisco router. CEF treats all Layer2 information as part of the adjacency table; the 2nd and 3rd line on each entry is the hex layer2 header info. IP requires a coherent layer2 even when it's directly connected. – Mike Pennington Mar 16 '15 at 18:39
  • The database descriptions exchanged between two routers are IP datagrams sent to the OSPF multicast address based on the network type. How is that not layer 3? I'm not saying that there wouldn't also be a layer 2 connection, layer 3 depends on layer 2. – Robert Mar 16 '15 at 18:43
  • 2
    So how do you support mismatched OSPF MTUs without L2 fragmentation? All RFC thumping aside, the answer is simple... Mismatched MTUs are broken at layer2 – Mike Pennington Mar 16 '15 at 18:45
  • The RFC clearely states that the OSPF protocol runs OVER IP. I don't care what output a cisco show command presents to you. If the information is encapsulated in a layer 3 datagram, there is the possibility of an MTU mismatch. If there was no issue of IP MTU mismatch, why would that even be a requirement for adjancencies? Your counter-argument is completely invalid. – Robert Mar 16 '15 at 18:47
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/22005/discussion-between-robert-and-mike-pennington). – Robert Mar 17 '15 at 03:39
  • Interesting discussion but seems to miss situations when the adjacency forms over a virtual L2 connections (DMVPN is one example) Then it all comes down to that virtual media MTU settings – MiniMe Jul 14 '16 at 12:42