FortiGate get router info routing-table all

Overview

get router info routing-table all displays the routes currently installed in the FortiGate routing table for the active VDOM.

It is one of the first commands to use when a FortiGate receives traffic but appears to forward it toward the wrong interface, gateway, or VPN tunnel.

Command

get router info routing-table all

What it does

The command shows active routes from sources such as:

• Connected networks
• Static routes
• RIP
• OSPF
• BGP
• IS-IS

It also identifies the candidate default route.

The exact codes displayed can depend on enabled routing protocols and FortiOS version.

When to use it

Use this command when:

• A destination is unreachable.
• Traffic exits the wrong WAN interface.
• A VPN is up but the remote subnet is not reachable.
• A new static route does not appear to be active.
• You suspect a more-specific route is overriding another route.
• You need to confirm the active default gateway.
• You need to identify whether a network is directly connected or learned dynamically.

Example output

S*      0.0.0.0/0 [10/0] via 192.0.2.1, wan1
C       10.1.10.0/24 is directly connected, VLAN10
S       10.2.20.0/24 [10/0] via IPSEC-SITE2 tunnel 198.51.100.10
O       10.3.30.0/24 [110/20] via 10.1.10.2, VLAN10

How to read common route codes

C - Connected

The subnet exists directly on a FortiGate interface.

C 10.1.10.0/24 is directly connected, VLAN10

This normally means an interface in that VDOM has an address belonging to the subnet.

S - Static

The route was configured statically.

S 10.2.20.0/24 [10/0] via IPSEC-SITE2 tunnel 198.51.100.10

O - OSPF

The route was learned through OSPF.

B - BGP

The route was learned through BGP.

* - Candidate default

A route marked with * is a candidate default route.

A common example is:

S* 0.0.0.0/0 [10/0] via 192.0.2.1, wan1

Administrative distance and metric

Routes commonly display values in brackets such as:

[10/0]

The first value represents administrative distance. The second is the metric used by the routing protocol or route type where applicable.

Do not compare routes only by administrative distance. Route selection begins with prefix specificity: a more-specific route can take precedence over a broader route.

For example:

10.1.10.0/24
10.1.10.0/26

Traffic for 10.1.10.20 matches both prefixes, but /26 is more specific and is therefore the relevant route before administrative distance becomes a deciding factor between equal-length candidates.

VDOM consideration

When VDOMs are enabled, routing commands must be executed in the relevant VDOM context.

If a route appears to be missing, verify that you are not looking at a different VDOM's routing table.

Troubleshooting workflow

1. Find the destination prefix

For a destination such as:

10.2.20.15

identify all table entries that could match the address.

2. Identify the most-specific route

Check for overlapping routes with longer prefixes.

Example:

10.2.20.0/24
10.2.20.0/26

The /26 route covers addresses from 10.2.20.0 through 10.2.20.63 and will be more specific for those destinations.

3. Check gateway or outgoing interface

Confirm that the selected next hop or tunnel is the intended path.

4. Compare with packet evidence

Use:

diagnose sniffer packet any 'host 10.2.20.15' 4 0 l

If FortiGate is selecting an unexpected path, use debug flow to see the route decision in packet processing.

How to validate

A routing check is complete when you can identify:

• The most-specific route for the destination.
• The route source.
• The outgoing interface or tunnel.
• The next-hop gateway where applicable.
• Whether another overlapping route could change the result for part of the address space.

Risks and considerations

This is a read-only diagnostic command and does not modify routing state.

The risk comes from misinterpreting the table rather than from executing the command.

Common interpretation errors include:

• Ignoring longer-prefix routes.
• Looking in the wrong VDOM.
• Assuming a configured route must be active.
• Confusing routing with firewall-policy permission.

A correct route does not prove that a firewall policy permits the traffic.

Related articles

• FortiGate debug flow
• FortiGate packet sniffer
• FortiGate execute ping
• FortiGate IPsec tunnel established but no traffic

Sources

See the authoritative Fortinet references in the article metadata.