FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
johnathan
Staff
Staff
Article Id 408783
Description This article describes how to troubleshoot a route not being installed in the FIB even though it is selected in the routing table.
Scope FortiOS.
Solution

Under certain circumstances, a static route may be chosen as the best route but never actually work as intended.

It is important to understand the concept of the RIB (routing table) vs the FIB. The following article describes this in detail:
Technical Tip: FortiGate - Viewing FIB/RIB routing information in CLI

 

When running 'get router info routing-table database', the following output is shown for the routes to 10.1.1.10:

 

FortiGate (root) # get router info routing-table database
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
V - BGP VPNv4
> - selected route, * - FIB route, p - stale info

Routing table for VRF=0
...
S > 10.1.1.0/23 [1/0] via badTunnel tunnel 1.1.1.75, [1/0]
S > 10.1.1.10/32 [10/0] via badTunnel tunnel 1.1.1.75, [1/0]
S *> 10.2.1.146/32 [10/0] via goodTunnel tunnel 1.1.1.245, [1/0]
...

Notice how the route is selected ('>'), but not installed ('*>' ) like the other static route.
When listing the routes inside of the FIB, it is possible to see this route is missing.
Run 'diagnose ip route list | grep x.x.x.x' to check this:

 

FortiGate (root) # diagnose ip route list | grep 10.1.1.
<no output>

To see why this route is failing to be installed, it is possible to take the following debug:

 

diagnose ip router command show debug nsm kernel

diagnose ip router command show debug nsm level info
diagnose debug enable

While this is running, disable and then re-enable the static route so the FortiGate will try and re-install the route.
There should be an error as soon as the FortiGate tried to install the route. Here is an example of this output:

 

...
NSM: netlink_talk: netlink-cmd type RTM_NEWROUTE(24), seq=6679
NSM: netlink-cmd error: Invalid argument, type=RTM_NEWROUTE(24), seq=6679, pid=0

...

 

To disable NSM debugs:


diagnose ip router command show debug nsm level error

diagnose ip router command show no debug nsm kernel

diagnose debug disable

diagnose debug reset


In this specific case, the error is 'Invalid argument, type=RTM_NEWROUTE(24)'.
This lined up with known issue 1160832, which is applicable when the gateway for a static route conflicts with a local address on the firewall. Technically as this is a tunnel there is no gateway, but this was still applicable to the tunnel ID.

In 8.0.x which contains the fix for this bug, objects with an overlapping IP can no longer be configured and this issue will not happen in the first place.


In order to resolve the issue, 'arp-reply' was disabled on the VIP and IP Pool which overlapped with 1.1.1.75.

After making this change and enabling and disabling the static routes, they were successfully installed:


FortiGate (root) # get router info routing-table database
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
V - BGP VPNv4
> - selected route, * - FIB route, p - stale info

Routing table for VRF=0
...
S *> 10.1.1.0/23 [1/0] via badTunnel tunnel 1.1.1.75, [1/0]
S *> 10.1.1.10/32 [10/0] via badTunnel tunnel 1.1.1.75, [1/0]
S *> 10.2.1.146/32 [10/0] via goodTunnel tunnel 1.1.1.245, [1/0]
...