cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6237
Views
8
Helpful
3
Replies

fragment packets

Bledar Meta
Level 1
Level 1

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.

2 Accepted Solutions

Accepted Solutions

Collin Clark
VIP Alumni
VIP Alumni

Resolve what issue? You can either allow fragmentation or allow TCP windowing to do it's job.

View solution in original post

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.

View solution in original post

3 Replies 3

Collin Clark
VIP Alumni
VIP Alumni

Resolve what issue? You can either allow fragmentation or allow TCP windowing to do it's job.

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.

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

:-)




>> Marcar como útil o contestado, si la respuesta resolvió la duda, esto ayuda a futuras consultas de otros miembros de la comunidad. <<
Getting Started

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:

Review Cisco Networking products for a $25 gift card