0

Is it possible to achieve 1500 byte MTU at the end host connections ignoring fragmentation overhead in this simple scenario using GRE. I would like to configure R1 and R2 to do the fragmentation silently and present this network as standard MTU 1500 byte network between this 2 hosts. the vendor is HPE comware and I'm missing the dfbit enable command under tunnel, anyway i'm trying to clarify is this doable because every manual online is focused on performance issue and guide to go with lower mtu that goes un fragmented between this sites. In my case i would like to abstract a 1500 bytes spanned network over a lower mtu overlay network.

interface Tunnel2 mode gre
 mtu 1500
 ip address 10.0.12.1 255.255.255.0
 rip 1 enable
 ip mtu 1500
 source 10.0.1.1
 destination 10.0.2.1

enter image description here

Improve this question
1
  • Did any answer help you? if so, you should accept the answer so that the question does not keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer.
    – Ron Maupin ♦
    Dec 23, 2021 at 19:56

1 Answer 1

Reset to default
4

When there's additional overhead eating into the MTU size, there are three basic approaches: increase outer MTU/frame size, decrease inner MTU, or live with fragmentation.

Routers may fragment (for IPv4) but they don't reassemble. Reassembly is done by the end destination. Trying to move reassembly from the end node to the last-hop router has no advantage in performance, latency or other (if at all, the end node may be faster with reassembly anyway).

If possible you should increase the outer frame (and MTU) size for the GRE connection to accomodate the extra overhead. Using "baby giants" removes the need to fragment and reassemble entirely. Of course, you'd need to be in control of the network for the entire path which often isn't the case when you're tunneling.

If you can't use baby giants for the tunnel, another approach is to reduce the MTU before tunneling. That removes the need for fragmentation and reassembly altogether and improves performance lost due to fragmentation.

A better approach without general MTU decrease is to use path MTU discovery (PMTUD) just like with IPv6, but that isn't always possible.

Improve this answer
6
  • thank you for your response but in this scenario I'm limited to fragmentation only. Are you sure that the destination gre router doesn't reassemble the packets after removing the gre encapsulation? I have some vague memory that IPsec does it
    – emirjonb
    Jun 24, 2021 at 11:11
  • I'm trying to do what others are trying to avoid :) "The performance impact to the router when the GRE tunnel destination router must re-assemble fragmented GRE packets"
    – emirjonb
    Jun 24, 2021 at 12:14
  • 1
    Reassembly on the tunnel terminator only works if the outer packet is fragmented, simulating a larger MTU than is actually possible - usually the inner packet is fragmented.
    – Zac67 ♦
    Jun 24, 2021 at 12:45
  • but if I set the mtu on interface tunnel as 1500 bytes am I triggering a outer packet fragmentation and achieve it? why am I still failing to communicate with end hosts with mtu bigger than 1468 C:\Users\Administrator>ping 192.168.2.10 -l 1440 Pinging 192.168.2.10 with 1440 bytes of data: Reply from 192.168.2.10: bytes=1440 time=1ms TTL=60
    – emirjonb
    Jun 24, 2021 at 14:38
  • 1
    Yes, possibly - only few device support that (as it's not really a good approach).
    – Zac67 ♦
    Jun 24, 2021 at 17:59

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.