07-26-2017 07:05 AM - edited 03-05-2019 08:54 AM
Dear all,
i would like to request our help regard to fragmentation.
Client-Server topology.
Server send packets with 1500 Bytes with prohibited fragmentation (DF bit set).
WAN links, use GRE tunnels with IPSec encapsulation, as the result of this MTU on WAN links (1400 Bytes).
WAN router, follow server's request and do not fragment packets, drop packets and inform servers about maximum packet size.
Any idea how to resolve this issue?
Thanks in advance.
Solved! Go to Solution.
07-26-2017 07:48 AM
Resolve what issue? You can either allow fragmentation or allow TCP windowing to do it's job.
07-26-2017 08:20 AM
As Collin has noted, if the source host is setting the DF bit, and it's notified that packet needs fragmentation, normally source host should auto adjust MTU and resend. This is "normal" although it incurs additional delay every time (usually host will retry full size packets after some time period) it happens.
As an alternative, it's possible to disregard the packet's DF bit, fragment it, and forward it anyway. This avoids the delay every time host needs to adjust MTU but it does create fragmented packets.
Another alternative, if the path over which the tunnel rides supports a MTU that will contain the standard Ethernet max MTU of 1500 and tunnel overhead, those packets will not need to be fragmented.
For TCP packets, Cisco's ip tcp adjust-mss interface command can be use to insure the MTU is "right" at session setup and doesn't need to be re-adjusted.
07-26-2017 07:48 AM
Resolve what issue? You can either allow fragmentation or allow TCP windowing to do it's job.
07-26-2017 08:20 AM
As Collin has noted, if the source host is setting the DF bit, and it's notified that packet needs fragmentation, normally source host should auto adjust MTU and resend. This is "normal" although it incurs additional delay every time (usually host will retry full size packets after some time period) it happens.
As an alternative, it's possible to disregard the packet's DF bit, fragment it, and forward it anyway. This avoids the delay every time host needs to adjust MTU but it does create fragmented packets.
Another alternative, if the path over which the tunnel rides supports a MTU that will contain the standard Ethernet max MTU of 1500 and tunnel overhead, those packets will not need to be fragmented.
For TCP packets, Cisco's ip tcp adjust-mss interface command can be use to insure the MTU is "right" at session setup and doesn't need to be re-adjusted.
07-26-2017 12:28 PM
Hi
Just adding to the discussion, the value for ip tcp adjust-mss must be at least 40 bytes less than the MTU value, example:
int tu100
ip mtu 1400
ip tcp adjust-mss 1360
:-)
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: