FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
ssudhakar
Staff
Staff
Article Id 280842
Description

This article outlines a method for identifying the device causing fragmentation through a ping test. However, this approach may not always be possible, especially when access to all devices along the network path is limited.

Scope All supported versions of FortiGate.
Solution

Step 1.

 

Begin by executing a traceroute command from the vdom to the destination IP address (x.x.x.x). This will provide a list of all the intermediate hops in the network path.

 

execute traceroute ‘x.x.x.x’ <- Destination IP.

 

Step 2.

 

Within the VDOM, use the following commands and initiate a series of ping tests to each of the intermediate hops, starting with a data size of 1500.

 

  • Set the ping options to enable the 'Don't Fragment' (DF) bit.
  • Set the data packet size to 1500 bytes.
  • Initiate ping tests to each of the following hop addresses:

 

execute ping-options df-bit yes
execute ping-options data-size 1500
execute ping ‘next hop address’’

 

Step 1: Sending an MTU=1500 Packet with the DF Bit.

 

In this step, send a packet with the Maximum Transmission Unit (MTU) set to 1500 and the Don't Fragment (DF) bit enabled either from the server to the client or vice versa.

 

Scenario 1a: Acknowledgment by the Receiver.

 

If the receiver acknowledges the packet, typically through an ICMP reply or a TCP acknowledgment, this indicates that there is no MTU mismatch along the communication path.

 

Scenario 1b: No Acknowledgment with Receipt of ICMP 'Fragmentation Needed'.

 

If the receiver does not acknowledge the packet and an ICMP 'Fragmentation Needed' or 'Message Too Big' message (type=3, code=4) packet is received instead, this suggests an MTU mismatch. Identify the device with the lower MTU, which is usually indicated in the ICMP message.

 

Scenario 1c: No Acknowledgment and No ICMP Message.

 

If the receiver does not acknowledge the packet and no ICMP message is received, it is likely that there is an MTU mismatch. In this case, the device with the smaller MTU may have failed to generate an ICMP message, or the ICMP message may have been dropped.

 

Step 2: Testing Without the DF Bit.

If an MTU mismatch is discovered in Step 1, proceed to send a packet with an MTU of 1500 without setting the DF bit.

 

Scenario 2a: Receiver Acknowledges the Packet.

 

If the receiver acknowledges this packet, it means that the device with the lower MTU successfully fragmented the packet, and the receiver successfully reassembled it. In this case, it is advisable to increase the Packets Per Second (PPS) to test for potential issues related to fragmenting and reassembling packets.

 

Scenario 2b: No Acknowledgment.

 

If the receiver does not acknowledge the packet in this step, there may be a fragmentation issue that needs further investigation.

 

Related articles:

Contributors