Interface MTU packet size

Changing the maximum transmission unit (MTU) on FortiGate interfaces changes the size of transmitted packets. Most FortiGate device's physical interfaces support jumbo frames that are up to 9216 bytes, but some only support 9000 or 9204 bytes.

To avoid fragmentation, the MTU should be the same as the smallest MTU in all of the networks between the FortiGate and the destination. If the packets sent by the FortiGate are larger than the smallest MTU, then they are fragmented, slowing down the transmission. Packets with the DF flag set in the IPv4 header are dropped and not fragmented .

On many network and endpoint devices, the path MTU is used to determine the smallest MTU and to transmit packets within that size.

• ASIC accelerated FortiGate interfaces, such as NP6, NP7, and SOC4 (np6xlite), support MTU sizes up to 9216 bytes.

• Some small desktop FortiGate models, such as the 30E and 50E, and FortiGate Rugged models, such as the 30D and 35D, support MTU sizes up to 1500 bytes.

• FortiGate VMs can have varying maximum MTU sizes, depending on the underlying interface and driver.

• Virtual interfaces, such as VLAN interfaces, inherit their MTU size from their parent interface.

To verify the supported MTU size:

config system interface
    edit <interface>
        set mtu-override enable
        set mtu ?
            <integer>    Maximum transmission unit (<min>-<max>)
    next
end

To change the MTU size:

config system interface
    edit <interface>
        set mtu-override enable
        set mtu <max bytes>
    next
end

Maximum MTU size on a path

To manually test the maximum MTU size on a path, you can use the ping command on a Windows computer.

For example, you can send ICMP packets of a specific size with a DF flag, and iterate through increasing sizes until the ping fails.

• The -f option specifies the Do not Fragment (DF) flag.

• The -l option specifies the length, in bytes, of the Data field in the echo Request messages. This does not include the 8 bytes for the ICMP header and 20 bytes for the IP header. Therefore, if the maximum MTU is 1500 bytes, then the maximum supported data size is: 1500 - 8 - 20 = 1472 bytes.

To determine the maximum MTU size on a path:

1. In Windows command prompt, try a likely MTU size:

   >ping 4.2.2.1 -l 1472 -f

   Pinging 4.2.2.1 with 1472 bytes of data:
   Reply from 4.2.2.1: bytes=1472 time=41ms TTL=52
   Reply from 4.2.2.1: bytes=1472 time=42ms TTL=52
   Reply from 4.2.2.1: bytes=1472 time=103ms TTL=52
   Reply from 4.2.2.1: bytes=1472 time=38ms TTL=52
   
   Ping statistics for 4.2.2.1:
       Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
   Approximate round trip times in milli-seconds:
       Minimum = 38ms, Maximum = 103ms, Average = 56ms

2. Increase the size and try the ping again:

   >ping 4.2.2.1 -l 1473 -f
   
   Pinging 4.2.2.1 with 1473 bytes of data:
   Request timed out.
   
   Ping statistics for 4.2.2.1:
       Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

   The second test fails, so the maximum MTU size on the path is 1472 bytes + 8-byte ICMP header + 20-byte IP header = 1500 bytes

Maximum segment size

The TCP maximum segment size (MSS) is the maximum amount of data that can be sent in a TCP segment. The MSS is the MTU size of the interface minus the 20 byte IP header and 20 byte TCP header. By reducing the TCP MSS, you can effectively reduce the MTU size of the packet.

The TCP MSS can be configured in a firewall policy, or directly on an interface.

To configure the MSS in a policy:

config firewall policy
    edit <policy ID>
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "10.10.10.6"
        set dstaddr "all"
        set schedule "always"
        set service "ALL"
        set tcp-mss-sender 1448
        set tcp-mss-receiver 1448
    next
end

To configure the MSS on an interface:

config system interface
    edit "wan2"
        set vdom "root"
        set mode dhcp
        set allowaccess ping fgfm
        set type physical
        set tcp-mss 1448
        set role wan
    next
end