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?

Improve this question
2
  • 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, 2015 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, 2015 at 22:58

2 Answers 2

Reset to default
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.

Improve this answer
2
  • 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, 2015 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, 2015 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.
Improve this answer
9
  • 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, 2015 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, 2015 at 18:34
  • From the RFC itself: The OSPF protocol runs directly over IP, using IP protocol 89.
    – Robert
    Mar 16, 2015 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, 2015 at 18:39
  • 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, 2015 at 18:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.