FortiGate · FortiOS 7.4

FortiGate interface, ARP and error counter commands

Quick answer #

A link-up indication proves only part of the path. Check the operational link, changes in error counters and resolution of the directly connected next hop. These observations help separate a cabling or Layer 2 issue from a routing or firewall-policy issue.

Scope: FortiGate physical interfaces and IPv4 ARP; FortiOS 7.4-family examples. Hardware counters differ by appliance/NPU/driver; VMs differ.

Inspect the physical interface #

Inspect the physical interface
FortiOS 7.4 · Traffic VDOM; administrative scope as described below

Read-only

Replace these example values: wan1.

diagnose hardware deviceinfo nic wan1

Replace wan1 with the physical port. Record operational link state, speed and duplex before reading counters. The names and availability of counters vary with the driver and hardware; do not expect an entry from an NP7 appliance to appear on every VM or older platform.

Take a second reading after a short, known test interval. A large historical counter has little diagnostic value without knowing whether it is still increasing. Save the elapsed time and traffic conditions with both samples. Do not reset counters merely to make comparison easier; subtraction preserves the original evidence.

Interpret counter changes carefully #

Increasing CRC errors are a useful reason to investigate the physical path, including optics, cable and the far-end port. They do not identify which component is faulty. Driver drops, hardware drops and host-to-NPU drops describe different observation points and must not be collapsed into a single packet-loss percentage. Compare the matching counter on the adjacent device where possible.

Inspect next-hop resolution #

In the relevant traffic VDOM, run:

Inspect next-hop resolution
FortiOS 7.4 · Traffic VDOM; administrative scope as described below

Read-only
get system arp
Read-only
diagnose ip arp list

Find the gateway or directly attached host on the correct interface. The remote server itself normally will not have an ARP entry when it is reached through a router. A missing remote-server MAC is therefore not a fault if the next-hop gateway resolves correctly.

Observe ARP without clearing it #

Observe ARP without clearing it
FortiOS 7.4 · Traffic VDOM; administrative scope as described below

Diagnostic state

Replace these example values: wan1.

diagnose sniffer packet wan1 'arp' 4 30 l

Press Ctrl+C when finished; a packet-count limit is not a time limit.

Output may contain sensitive operational data.

Press Ctrl+C when finished; the count limit alone will not terminate an idle capture. Repeated requests without a visible reply focus attention on the local broadcast domain, VLAN tagging and adjacent equipment. Confirm the correct logical VLAN and physical parent before interpreting a capture on a trunk.

Build the next action from evidence #

If link and counters are stable but the next hop does not resolve, investigate Layer 2 reachability. If the next hop resolves and the request leaves, proceed to route, policy and return-path checks. Avoid changing speed, clearing the ARP table or bouncing the port during initial collection, because those actions can interrupt other traffic and erase useful state.

Sources

Documentation reviewed: 8 October 2026