The Ultimate FortiOS CLI Reference for the NSE 4 Exam – Part 1: System Health & Routing

3 June 2026 FortinetNSE4FortiOSCLINetworking

Passing the NSE 4 exam is not just about memorising what commands exist — it’s about understanding why a command’s output looks the way it does, and being able to read a screen of raw CLI text under time pressure and extract the single indicator that answers the question. This guide treats each command as a window into a specific FortiOS subsystem. For every command you’ll get the exact syntax, the internal daemon or kernel layer being interrogated, a realistic scenario where you’d actually type it, a mock terminal output, and — critically — a callout of the exact fields, flags, and counters the exam expects you to know.

Module 1: Core System Health & Port Layout

`get system status`

Command Syntax & Architectural Impact

get system status

This command queries reportd (the reporting daemon) and miglogd (the management information gathering log daemon), pulling a consolidated snapshot of system identity, firmware version, licensing state, and operational mode. It does not interact with the data plane — no session table reads, no packet flow involvement. The output is drawn entirely from the management plane: /proc files for uptime and CPU architecture, kernel module state for VDOM and virtual clustering status, and the FortiGuard licence cache held in /var/run.

Understanding the architectural split here matters: this command tells you what the firewall is and whether it’s authorised to do its job. It will not tell you how busy it is — that’s get system performance status.

Real-World Use Case Scenario

A change-freeze window is open and a junior engineer has just applied a firmware upgrade on the wrong unit — the standby member of an active-passive HA pair. You remote in and need to quickly confirm: (1) which firmware build is running on this specific chassis, (2) whether it still believes itself to be in an HA cluster, and (3) whether the FortiGuard subscription that covers IPS signatures is still valid. You cannot go to the GUI — the management VLAN is unreachable from your jump host. get system status gives you all three answers in under five seconds.

Live Output Breakdown

FortiGate-600F # get system status
Version: FortiGate-600F v7.4.3,build2573,240401 (GA)
Virus-DB: 91.09170(2024-04-01 12:05)
Extended DB: 91.09170(2024-04-01 12:05)
IPS-DB: 6.00741(2024-04-01 11:22)
IPS Extended DB: 6.00741(2024-04-01 11:22)
Serial-Number: FG6H0E5818900001
License Status: Valid
License Expiration Date: 2025/04/01
VM Resources: N/A
Log hard disk: Available
Hostname: FW-CORE-01
Operation Mode: NAT
Current virtual domain: root
Max number of virtual domains: 10
Virtual domains status: 1 in NAT mode, 0 in TP mode
Virtual domain configuration: disable
FIPS-CC mode: disable
Current HA mode: a-p, master
Branch point: 2573
Release Version Information: GA
System time: Wed Apr 03 09:14:22 2024

Key Exam Indicators

Field	What to look for
`Version`	Build string must match expected firmware. `v7.4.3,build2573` — the build number is the tie-breaker when two units show the same version string but diverge in patch content.
`License Status: Valid` / `License Expiration Date`	If this reads `Invalid` or the expiry is in the past, FortiGuard-dependent features (AV, IPS, Web Filter, Application Control) fall back to their last-downloaded signatures. The FortiGate does not stop passing traffic — but it stops updating and may alert.
`Current HA mode: a-p, master`	The two tokens matter independently. `a-p` = active-passive topology. `master` = this unit is currently primary. If this were `slave`, all traffic is being processed on the other unit and you are on the wrong box. Exam questions frequently ask you to identify which HA role a unit holds from this output.
`Operation Mode: NAT`	If this reads `Transparent`, routing, DHCP, and DNS behaviours change fundamentally. Transparent mode boxes have no IP on their forwarding interfaces.
`Virtual domain configuration: disable`	If this is `enable`, VDOMs are active and your `get router info routing-table all` output will only show the root VDOM. Always check this before drawing routing conclusions.

`get system performance status`

Command Syntax & Architectural Impact

get system performance status

This command polls hatalk (HA telemetry, even on standalone units), the kernel /proc/stat interface for per-CPU utilisation, and the session management daemon scanunitd for session rate statistics. The memory figures come directly from the Linux kernel memory allocator (/proc/meminfo) — FortiOS reserves a fixed kernel pool and a dynamic user-space pool; the percentages in the output reflect user-space consumption only, not total RAM.

The session rate counter (Sessions/second) is a 5-second rolling average maintained in shared memory by the session daemon. The total sessions figure queries the session table held in kernel space.

Real-World Use Case Scenario

Your NOC receives alerts that throughput on a FortiGate-400F has dropped 60% in the last ten minutes. Packet loss is being reported by users but the uplinks show utilisation well below capacity. You suspect the unit has hit a CPU or memory threshold — either a security profile is overloading the IPS engine (CP9 offload has fallen back to software), or a scanning loop is consuming proxy worker threads. Before opening a TAC case, you need a snapshot of CPU state across all cores, current memory pressure, and session table depth to distinguish between: (a) a genuine DDoS, (b) a misconfigured security profile causing proxy overflow, or (c) a memory leak in a daemon.

Live Output Breakdown

FortiGate-400F # get system performance status
CPU states: 12% user 3% system 0% nice 85% idle
CPU0 states: 15% user 4% system 0% nice 81% idle
CPU1 states: 11% user 3% system 0% nice 86% idle
CPU2 states: 10% user 2% system 0% nice 88% idle
CPU3 states: 12% user 3% system 0% nice 85% idle
Memory: 16384704k total, 11203208k used (68%), 5181496k free
Average network usage: 1354 kbps in 1 minute, 1421 kbps in 10 minutes, 1388 kbps in 30 minutes
Average sessions: 42318 sessions in 1 minute, 41890 sessions in 10 minutes, 40100 sessions in 30 minutes
Average session setup rate: 312 sessions/second in last 1 minute
Virus caught: 0 total in 1 minute
IPS attacks blocked: 2 total in 1 minute
Uptime: 47 days,  5 hours,  32 minutes

Key Exam Indicators

Field	What to look for
`CPU states` (aggregate line)	High `user` percentage (>70%) typically points to software-path packet processing — traffic that has not been offloaded to the NP or CP ASIC. High `system` percentage (>20%) can indicate kernel-level thrashing, often from excessive session table lookups under a flood.
`Memory: … used (68%)`	FortiOS degrades gracefully as memory fills. At ~75% it begins rejecting new proxy sessions. At ~90% it triggers an emergency `conserve mode`, which halts new security-profile inspections and can bypass AV/IPS scanning. Exam questions will describe symptoms of conserve mode (traffic passing without inspection) and ask which counter to check.
`Average session setup rate: 312 sessions/second`	Cross this against the platform’s datasheet `cps` (connections per second) specification. If setup rate approaches or exceeds the rated `cps`, the session daemon is the bottleneck, not CPU or memory.
`Average sessions` (1 min vs 10 min vs 30 min)	A spike in 1-minute average with stable 30-minute average is a sudden burst (potential DDoS/scan). A steadily climbing curve across all three windows is organic growth or a slow leak.

`get system interface physical` and `diagnose hardware deviceinfo nic <interface>`

Command Syntax & Architectural Impact

get system interface physical
diagnose hardware deviceinfo nic <interface>

get system interface physical reads interface state from the kernel netlink socket — the same mechanism the OS uses to populate ip link show. It shows the logical view: IP, mask, MAC, link state as the operating system reports it.

diagnose hardware deviceinfo nic <interface> drops one level lower: it queries the NIC driver directly via the FortiOS HAL (Hardware Abstraction Layer), bypassing the kernel network stack. This is the only command that exposes L1/L2 hardware-level counters — specifically error frames, CRC errors, and rx/tx drops attributed to the physical layer rather than the session table. On platforms with NP (network processor) ASICs, it also shows NP offload engine binding.

The architectural significance: a port can report up in get system interface physical (meaning the kernel sees a carrier signal) yet be silently dropping frames at the NIC level due to a speed/duplex mismatch — and only diagnose hardware deviceinfo nic will expose those hardware drop counters.

Real-World Use Case Scenario

A FortiGate-200F connects to a legacy Cisco 3550 distribution switch. The link appears up in the FortiOS GUI, the STP port is forwarding, and ping tests between connected subnets succeed. However, throughput never exceeds ~40 Mbps and users experience intermittent TCP retransmissions. The FortiGate port is set to auto negotiation but the Cisco port has been hard-coded to 100/full by a previous engineer who “fixed” a different autoneg problem years ago. The mismatch produces a half-duplex collision domain on the FortiGate side — the NIC driver sees excessive late collisions and back-off events, but the kernel’s logical interface reports the link as clean because carrier is present and frames do arrive.

Live Output Breakdown

FortiGate-200F # get system interface physical
== [onboard]
==[port1]
        mode: static
        ip: 203.0.113.1 255.255.255.252
        ipv6: ::/0
        status: up
        speed: 1000full (Desired: 1000full)
        MTU: 1500
==[port2]
        mode: static
        ip: 10.10.0.1 255.255.255.0
        status: up
        speed: 100full (Desired: auto)
        MTU: 1500
==[port3]
        mode: static
        ip: 0.0.0.0 0.0.0.0
        status: down
        speed: auto (Desired: auto)
        MTU: 1500

FortiGate-200F # diagnose hardware deviceinfo nic port2
Driver Name         :   FortiASIC NP6LITE Adapter
Version             :   2.2
Speed               :   100
Duplex              :   HALF
Link                :   up
...
Rx Pkts             :   48291042
Rx Bytes            :   38291048448
Rx Errors           :   0
Rx Drops            :   91847
Rx Frame Errors     :   3412
Rx CRC Errors       :   1290
Tx Pkts             :   31029481
Tx Bytes            :   19047382912
Tx Errors           :   0
Tx Drops            :   0
Tx Late Collisions  :   22847
Tx Excessive Retries:   8910

Key Exam Indicators

Field	What to look for
`speed: 100full (Desired: auto)` in `get system interface physical`	When `speed` ≠ `Desired`, a hard-coded peer forced a negotiation outcome. The FortiGate accepted the hard-coded value. This is not necessarily a problem unless the peer is half-duplex while the FortiGate expects full.
`Duplex: HALF` in `diagnose hardware deviceinfo nic`	Combined with the `speed` mismatch above, this confirms a half-duplex collision domain. Every TCP bulk transfer will produce collisions and Ethernet back-off, explaining the throughput cap.
`Rx Drops`, `Rx Frame Errors`, `Rx CRC Errors`	These are hardware-layer drops before the kernel even sees the frame. They will not appear in `diagnose sys session list` or any session-layer counter. If sessions look healthy but users complain about drops, start here.
`Tx Late Collisions` / `Tx Excessive Retries`	Present only on copper interfaces in a half-duplex collision domain. Zero on any modern full-duplex link. Non-zero values are a definitive duplex mismatch indicator.

Module 2: Advanced Routing & Forwarding

`get router info routing-table all`, `get router info routing-table database`, and `get router info kernel`

Command Syntax & Architectural Impact

get router info routing-table all
get router info routing-table database
get router info kernel

These three commands expose three distinct layers of the FortiOS routing architecture, maintained by two different subsystems: the zebra routing daemon and the Linux kernel.

get router info routing-table all reads the RIB — the Routing Information Base. Per Fortinet’s own documentation, this is what FortiOS calls “the routing table”: the best route per destination that each routing protocol has submitted after its own internal selection. Connected, static, OSPF, BGP, and RIP routes all compete here; only the winner per prefix appears. This is the control-plane view of what is reachable and how.

get router info routing-table database reads the full routing database — a superset of the RIB that shows every route candidate zebra knows about, including routes that lost the selection process. Multiple entries for the same prefix appear here with different administrative distances and metrics. Routes marked with > have been selected into the RIB; those without it are known but inactive. Use this command when a route is missing from routing-table all — it reveals whether the route was ever learned at all and what its parameters are.

get router info kernel reads the FIB — the Forwarding Information Base, also called the kernel routing table. This is the Linux kernel’s actual forwarding table — the ground truth for packet forwarding decisions. The FIB is mostly derived from the RIB, but it can contain routes that are not in the routing table at all. The canonical example is SSL-VPN tunnel routes: FortiOS injects these directly into the kernel for each connected VPN user, bypassing zebra entirely. When the kernel performs a route lookup for an incoming packet, it uses the FIB, not routing-table all. In normal operation the two are nearly identical; discrepancies indicate either a routing daemon/kernel sync issue or a FortiOS-injected route.

The full pipeline: routing protocols → zebra selects best routes → RIB (routing-table all) → best routes pushed down to kernel → FIB (get router info kernel) → kernel uses FIB for actual packet forwarding. The routing-table database sits alongside as zebra’s complete scratchpad of all candidates before and after selection.

Real-World Use Case Scenario

A branch FortiGate has two uplinks: a primary MPLS circuit (learned via OSPF, AD=110) and a backup broadband link with a floating static default route (AD=210). After an MPLS flap, traffic did NOT failover to broadband — the branch was unreachable for 4 hours. get router info routing-table all shows no default route during the outage, confirming the floating static never won selection. get router info routing-table database shows whether the static was known to zebra at all and with what next-hop — pointing directly at a misconfiguration. get router info kernel confirms whether the kernel FIB was equally empty, ruling out the rare case where zebra had selected a route but failed to push it down to the kernel.

Live Output Breakdown

FortiGate-100F # get router info routing-table all
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
       O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default

O*E2 0.0.0.0/0 [110/1] via 10.0.0.2, port1, 00:18:34
C    10.0.0.0/30 is directly connected, port1
C    10.10.10.0/24 is directly connected, port2
O    172.16.0.0/16 [110/20] via 10.0.0.2, port1, 00:18:34


FortiGate-100F # get router info routing-table database
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
       O - OSPF, IA - OSPF inter area
       ...
       * - candidate default, > - selected route, p - stale info

S *> 0.0.0.0/0 [1/0] via 10.0.0.1, port1             <- primary static (AD=1), selected
S    0.0.0.0/0 [210/0] via 203.0.113.254, port3       <- floating static (AD=210), NOT selected
O *> 0.0.0.0/0 [110/1] via 10.0.0.2, port1, 00:18:34 <- OSPF default, currently winning
C *> 10.0.0.0/30 is directly connected, port1
C *> 10.10.10.0/24 is directly connected, port2
O *> 172.16.0.0/16 [110/20] via 10.0.0.2, port1, 00:18:34


FortiGate-100F # get router info kernel
Kernel IP routing table
Destination     Gateway         Genmask         Flags   Ref Use Iface
0.0.0.0         10.0.0.2        0.0.0.0         UG      0   0   port1
10.0.0.0        0.0.0.0         255.255.255.252 U       0   0   port1
10.10.10.0      0.0.0.0         255.255.255.0   U       0   0   port2
172.16.0.0      10.0.0.2        255.255.0.0     UG      0   0   port1
10.200.0.5      0.0.0.0         255.255.255.255 UH      0   0   ssl.root  <- SSL-VPN, not in RIB

Key Exam Indicators

Field	What to look for
`routing-table all` = RIB	Fortinet’s term for this output is “the routing table” — the control-plane best-path winners. Do not confuse this with the FIB.
`get router info kernel` = FIB	The kernel forwarding table — what the FortiGate actually uses to forward packets. In normal operation it mirrors the RIB; differences indicate a FortiOS-injected route or a sync issue.
`>` marker in `routing-table database`	Marks routes that have been selected and are present in the RIB. Routes without `>` are known to `zebra` but lost the selection — they are not being used for forwarding.
`[110/1]` format	Always `[administrative-distance/metric]`. AD=110 is OSPF. AD=1 is static. AD=210 is a floating static. AD=20 is eBGP. AD=200 is iBGP. These are the values the NSE 4 exam tests directly.
Floating static in `database` without `>`, absent from `routing-table all`	Correct healthy behaviour while the primary route is up. If it still lacks `>` after the primary withdraws, the next-hop is unreachable or the egress interface is down — `zebra` considers the route invalid and will not select it.
Route in `get router info kernel` absent from `routing-table all`	A FortiOS-injected route that bypassed `zebra` entirely — SSL-VPN user routes and certain HA routes are the most common examples. These are normal and expected.
`O*E2 0.0.0.0/0`	The `*` marks the candidate default. `E2` = OSPF External Type 2 — metric does not accumulate as the route propagates through the OSPF domain. `E1` accumulates internal cost. Knowing E1 vs E2 is an exam requirement.

`get system arp`

Command Syntax & Architectural Impact

get system arp

This command reads the kernel ARP cache (/proc/net/arp), but FortiOS post-processes the output to layer in information from its own proxy ARP and gratuitous ARP tracking tables. The result is a consolidated view of: (1) dynamically learned ARP entries from connected subnets, (2) static ARP entries configured under config system arp-table, and (3) any proxy ARP mappings where the FortiGate is responding on behalf of another host.

Architecturally, every L3 forwarding decision for a directly-connected subnet requires the ARP table to resolve next-hop MAC addresses. A missing or incorrect ARP entry will produce Destination Host Unreachable at the IP layer even when the routing table is correct.

Real-World Use Case Scenario

A server on 10.10.10.100 is not reachable from any client, despite having a correct default gateway pointing at the FortiGate’s 10.10.10.1 interface. Pings from the FortiGate itself to 10.10.10.100 time out. The server’s NIC is up, it has a valid IP, and netstat shows no firewall rules blocking ICMP. You suspect an ARP problem — either the server’s MAC is not cached, or there’s an ARP spoofing event where a different MAC is squatting on that IP.

Live Output Breakdown

FortiGate-100F # get system arp
Address          Age(min)   Hardware Addr      Interface
10.0.0.2         0          00:0c:29:3a:1b:4c  port1
10.10.10.50      2          00:50:56:a1:22:33  port2
10.10.10.100     -          incomplete          port2
10.10.10.200     8          00:50:56:b2:44:55  port2

Key Exam Indicators

Field	What to look for
`incomplete` in Hardware Addr column	The FortiGate has sent ARP requests for this IP but received no reply. The host is either down, blocking ARP, or on a different VLAN/segment than the FortiGate interface. This is the definitive indicator for “ARP unreachable.”
`Age(min): 0`	The ARP entry was just refreshed — active communication is occurring. FortiOS default ARP timeout is ~5 minutes. An age approaching 5 minutes that never resets indicates one-way traffic (server responding but host not initiating).
`Age(min): -`	Some FortiOS versions show `-` for static ARP entries that never expire. Confirm with `config system arp-table` if you see this.
Interface column	Mismatched interface (e.g. an IP on port2’s subnet appearing under port1) indicates either a routing loop is delivering ARP from the wrong segment, or proxy ARP is active and possibly misconfigured.

`execute ping-options` + `execute ping`

Command Syntax & Architectural Impact

execute ping-options source <IP>
execute ping-options df-bit {yes|no}
execute ping-options data-size <bytes>
execute ping-options repeat-count <n>
execute ping-options timeout <seconds>
execute ping <destination>

execute ping by default sources from the interface closest to the destination according to the routing table, uses 56-byte ICMP payloads, and does not set the DF bit. These defaults are useless for diagnosing complex routing paths. execute ping-options allows you to override each parameter before the ping runs — the options are consumed by the diagnostic ICMP engine once and then reset.

The source IP override is architecturally important: it forces the FortiGate to use a specific interface’s IP as the source, which means the return path must route back to that interface. This lets you verify asymmetric routing or policy-based routing behaviour: if pings succeed only when sourced from one IP but not another, the return path for the second source is broken.

The DF bit + data-size combination implements a manual Path MTU Discovery probe. By setting df-bit yes and incrementally increasing data-size, you can binary-search the MTU bottleneck along a path — exactly what pmtud-sweeper automates, but here done interactively at the FortiGate CLI. Fragmentation-needed ICMP errors from the limiting hop will cause the ping to fail, identifying the choke point.

Real-World Use Case Scenario

IPsec tunnel between two sites is established (Phase 1 and Phase 2 are up), but large file transfers fail while small files and web traffic succeed. This is the classic PMTU/MSS black hole scenario. The tunnel has an MTU of 1438 bytes after IPsec overhead. TCP sessions use MSS clamping at the initiating side but UDP traffic (DNS responses, VoIP RTP frames) is unaffected. You need to confirm: (a) which MTU is actually reachable end-to-end across the tunnel, and (b) whether the far-end router is correctly returning Fragmentation Needed ICMP messages.

Live Output Breakdown

FortiGate-100F # execute ping-options source 10.0.0.1
FortiGate-100F # execute ping-options df-bit yes
FortiGate-100F # execute ping-options data-size 1400
FortiGate-100F # execute ping-options repeat-count 3
FortiGate-100F # execute ping 172.16.10.1
PING 172.16.10.1 (172.16.10.1): 1400 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2

--- 172.16.10.1 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

FortiGate-100F # execute ping-options data-size 1350
FortiGate-100F # execute ping 172.16.10.1
PING 172.16.10.1 (172.16.10.1): 1350 data bytes
64 bytes from 172.16.10.1: icmp_seq=0 ttl=62 time=3.7 ms
64 bytes from 172.16.10.1: icmp_seq=1 ttl=62 time=3.4 ms
64 bytes from 172.16.10.1: icmp_seq=2 ttl=62 time=3.6 ms

--- 172.16.10.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss

Key Exam Indicators

Field	What to look for
`source <IP>` before pinging	The source IP determines the reverse-path. If `execute ping` succeeds with the default source but fails with a specific source, policy-based routing, or a specific firewall policy, is blocking the return path for that source.
`df-bit yes` + size failure then success at smaller size	This is the DF-bit PMTU probe in action. The transition from timeout to success pinpoints the MTU ceiling. The MTU is: `data-size (at success) + 28 bytes (20 IP header + 8 ICMP header)`. In the example: 1350 + 28 = 1378 bytes maximum packet size on the path.
`ttl=62` on returned packets	Each hop decrements TTL by 1. If the far end sends with TTL 64, receiving TTL 62 means exactly 2 hops. Mismatched TTL between forward and return probes indicates asymmetric routing.
`Request timeout` vs `Destination Host Unreachable`	`Request timeout` = packet sent, no reply received within timeout (could be filtered, dropped silently, or Fragmentation-Needed messages are being silently discarded). `Destination Host Unreachable` = an intermediate router explicitly rejected the packet and told you. Exam questions test the distinction.

Part of the NSE4 Study Series. Also see Part 5: Logging, Monitoring & Diagnostics and Part 9: Routing & SD-WAN for the exam syllabus treatment of these topics.

The Ultimate FortiOS CLI Reference for the NSE 4 Exam – Part 1: System Health & Routing

Module 1: Core System Health & Port Layout

get system status

Command Syntax & Architectural Impact

Real-World Use Case Scenario

Live Output Breakdown

Key Exam Indicators

get system performance status

Command Syntax & Architectural Impact

Real-World Use Case Scenario

Live Output Breakdown

Key Exam Indicators

get system interface physical and diagnose hardware deviceinfo nic <interface>

Command Syntax & Architectural Impact

Real-World Use Case Scenario

Live Output Breakdown

Key Exam Indicators

Module 2: Advanced Routing & Forwarding

get router info routing-table all, get router info routing-table database, and get router info kernel

Command Syntax & Architectural Impact

Real-World Use Case Scenario

Live Output Breakdown

Key Exam Indicators

get system arp

Command Syntax & Architectural Impact

Real-World Use Case Scenario

Live Output Breakdown

Key Exam Indicators

execute ping-options + execute ping

Command Syntax & Architectural Impact

Real-World Use Case Scenario

Live Output Breakdown

Key Exam Indicators

`get system status`

`get system performance status`

`get system interface physical` and `diagnose hardware deviceinfo nic <interface>`

`get router info routing-table all`, `get router info routing-table database`, and `get router info kernel`

`get system arp`

`execute ping-options` + `execute ping`