| Description | This article discusses the usage of ICMP and IPv4 Time-to-Live (TTL) as a means of detecting duplicate addresses on the network/traffic being routed to the wrong device, and it also includes a scenario-based example for this topic. |
| Scope | FortiGate |
| Solution |
IPv4 TTL (as well as IPv6 Hop Limit) is a counter associated with every IP packet that a device sends out. The main intent of this counter is to limit the total number of routers that can handle a packet before the packet must be discarded (i.e. to prevent packets from entering a perpetual routing loop situation).
This counter is most easily visible when sending an ICMP ping request to a destination from a device's command line prompt:
Important note: The TTL value seen in the results of ICMP pings is set by the destination host that is responding to the ping, not by the sender. For example, FortiOS will respond with a TTL of 255 when pinged, which is then decremented by one for each router along the path until it arrives back to the client that initiated the ping. This is important because if the TTL changes unexpectedly, then it can be a signal that an issue is occurring on the network.
For example, when pinging the FortiGate from a local device on the same subnet/broadcast domain, the expectation would be that the returned TTL is 255 since there are no other routers in-between the local device and the FortiGate. If the TTL suddenly changes to a different value (e.g. TTL=64), then that would indicate that the ICMP ping response is coming from a device other than the FortiGate that is using the same IP address. This could cause issues with traffic flow, as traffic would no longer flow along the previously-expected path.
As an example, consider the following scenario: Internet Traffic is intermittently failing for brief periods, then starts working again without any configuration changes. In this example scenario, the administrator has received reports that the user's internet traffic will randomly stop working for a brief period, then it will eventually start flowing again without any changes. In particular, VoIP traffic (such as Microsoft Teams or Google Meet) appears to stall randomly during meetings, disrupting audio and video feeds.
To investigate this issue, the administrator runs a continuous ping from a local host to the FortiGate's IP address (since it is the local default gateway for the network), and the following is seen at the same time that users are reporting disruptions to network traffic:
C:\Users\Administrator>ping -t 192.168.100.1 Pinging 192.168.100.1 with 32 bytes of data: Reply from 192.168.100.1: bytes=32 time<1ms TTL=255
In this case, the change in TTL indicates that a device other than the FortiGate is responding to ICMP ping requests from this local client. This could only occur if another device on the network was configured to respond to ARP requests for the FortiGate's assigned IP address.
The administrator opens Wireshark on the local workstation and filters for ICMP and ARP traffic related to the FortiGate's IP address (for example: (arp || icmp) && ip.addr == 192.168.100.1). The expectation is to only see the FortiGate's MAC address associated with this IP address, but when the issue is occurring, the administrator observes a rogue device (in this case, a misconfigured network switch) replying to ARP requests for the FortiGate's IP address using its own MAC address. This causes users to send traffic towards the network switch for a short period rather than the FortiGate, which in-turn causes traffic to fail to reach the Internet successfully. Once the network switch is shut down and subsequently reconfigured, users no longer experience the intermittent disruptions to the network. |
