This scenario illustrates GRE fragmentation.
Remember that you fragment before encapsulation for GRE, then do PMTUD for the
data packet, and the DF bit is not copied when the IP packet is encapsulated by GRE.
!
In this scenario, the DF bit is not set. The GRE tunnel interface IP MTU is,
by default, 24 bytes less than the physical interface IP MTU,
so the GRE interface IP MTU is 1476.

- The the sender sends a 1500-byte packet (20 byte IP header + 1480 bytes
of TCP payload). - Since the MTU of the GRE tunnel is 1476, the 1500-byte packet is broken
into two IP fragments of 1476 and 44 bytes, each in anticipation of the
additional 24 byes of GRE header. - The 24 bytes of GRE header is added to each IP fragment.
Now the fragments are 1500 (1476 + 24) and 68 (44 + 24) bytes each. - The GRE + IP packets containing the two IP fragments are forwarded
to the GRE tunnel peer router. - The GRE tunnel peer router removes the GRE headers from the two packets.
- This router forwards the two packets to the destination host.
- The destination host reassembles the IP fragments back into the original
IP datagram.
Additional Notes :
Under normal circumstances, when two hosts communicate via TCP,
they communicate with each other to determine the Send Maximum Segment Size (SMSS).
Often this turns out to be 1500 bytes, which not coincidentally, is the maximum amount
of payload in an Ethernet frame.
All is well until a combination of technologies combine to break the system.
First, the packets travel through a GRE (generic routing encapsulation) tunnel across
an Ethernet interface. This encapsulation tacks on 24 bytes.
1500 – 24 = 1476
Thus, if either host sends a packet that is larger than 1476, the packet must be
fragmented (typically by one of the tunnel endpoints) to cross the tunnel.
Unfortunately, the hosts do not realize this, because they have only communicated with
one another and agreed upon the 1500 value, but connectivity isn’t broken.
At this point, any one of a number of things can break this connectivity.
If the transmitting host sets the Don’t Fragment bit, the router will be forced to drop
the packet. However, it will *usually* send an ICMP (Internet Control Message Protocol)
message informing the sender to use smaller packets. But even if it sends the ICMP messages,
they are often filtered or blocked by firewalls somewhere in the path, so the host never knows
why the packet wasn’t delivered.
Another problem that can occur is a firewall that blocks fragmented packets.
Comments
(There are currently no comments for this post.)