Consider the following topology, where LocalFortigate learns the RemoteFortigate loopback prefix 10.100.2.1/32 through ISP1Fortigate and ISP2Fortigate using RIPv2.
Both paths advertise 10.100.2.1/32 to LocalFortigate with the same RIP metric.
The RIP debug output shows the prefix received from ISP1Fortigate through port2:
RIP: RECV[port2]: Receive from 10.11.11.2:520 tun_id=0.0.0.0 dst 224.0.0.9
RIP: RECV[port2]: RESPONSE version 2 packet size 164
RIP: 10.100.2.1/32 -> 0.0.0.0 family 2 tag 0 metric 2
The same prefix is also received from ISP2Fortigate through port5 with the same metric:
RIP: RECV[port5]: Receive from 10.11.12.2:520 tun_id=0.0.0.0 dst 224.0.0.9
RIP: RECV[port5]: RESPONSE version 2 packet size 164
RIP: 10.100.2.1/32 -> 0.0.0.0 family 2 tag 0 metric 2
The captured debug output confirms that both RIP neighbors advertise 10.100.2.1/32 with metric 2.
Although the same prefix is received from both neighbors with an equal metric, only one path is selected in the RIP database:
LocalFortigate # get router info rip database
Network Next Hop Metric From If Time
R 10.100.2.1/32 10.11.11.2 3 10.11.11.2 port2 02:57
The routing table also shows the selected path through ISP1Fortigate:
LocalFortigate # get router info routing-table details 10.100.2.1
Routing table for VRF=0
Routing entry for 10.100.2.1/32
Known via "rip", distance 120, metric 3, best
Last update 00:08:44 ago
* vrf 0 10.11.11.2, via port2
RIP updates containing 10.100.2.1/32 with metric 2 continue to be received through port5 while the route through port2 remains selected.
This shows that receiving another equal-metric advertisement does not replace the currently selected RIP route.
Behavior when the selected path becomes unavailable:
To verify the failover behavior, port2, which is associated with the selected route, is disabled:
config system interface
edit "port2"
set status down
next
end
The RIP debug output shows port2 going down and the selected route for 10.100.2.1/32 being deleted:
2026-09-14 02:32:29 RIP: Message type: Link Down (30)
2026-09-14 02:32:29 RIP: Name: port2
2026-09-14 02:32:29 RIP: I/F[port2]: Turn off RIP routing
...
2026-09-14 02:32:29 RIP: NSM: IPv4 Route 10.100.2.1/32 delete
A valid advertisement for 10.100.2.1/32 is then received from ISP2Fortigate through port5:
2026-09-14 02:32:29 RIP: RECV[port5]: Receive from 10.11.12.2:520 tun_id=0.0.0.0 dst 224.0.0.9
2026-09-14 02:32:29 RIP: RECV[port5]: RESPONSE version 2 packet size 164
...
2026-09-14 02:32:29 RIP: 10.100.2.1/32 -> 0.0.0.0 family 2 tag 0 metric 2
...
2026-09-14 02:32:29 RIP: NSM: IPv4 Route 10.100.2.1/32 add
The selected route is deleted, the alternate advertisement is received, and the route is added again through the alternate path. In this test, these events occurred within the same second.
The RIP database now shows the route through ISP2Fortigate:
LocalFortigate # get router info rip database
Network Next Hop Metric From If Time
R 10.100.2.1/32 10.11.12.2 3 10.11.12.2 port5 02:58
The routing table confirms the alternate path:
LocalFortigate # get router info routing-table details 10.100.2.1
Routing table for VRF=0
Routing entry for 10.100.2.1/32
Known via "rip", distance 120, metric 3, best
Last update 00:00:03 ago
* vrf 0 10.11.12.2, via port5
This behavior shows that the equal-metric routes are not installed as simultaneous paths. When the selected RIP route becomes unavailable, the alternate route can be installed after a subsequent valid RIP advertisement for the prefix is processed.
Effect of the RIP update timer:
By default, the RIP update timer is 30 seconds. The actual interval between periodic RIP updates can vary because RIP applies randomization to the update interval.
During testing with the default update timer, the selected route for 10.100.2.1/32 was removed at 02:22:17. A subsequent advertisement containing the same prefix was received from the alternate RIP neighbor at 02:22:46, after which the alternate route was installed.
An interval of approximately 29 seconds was observed between removal of the selected route and installation of the alternate route during this test.
To further verify the relationship between the RIP update interval and the observed failover behavior, the update timer was changed to 5 seconds on the RIP routers:
config router rip
set update-timer 5
end
After repeating the test, the selected route was removed at 02:32:29. An advertisement containing 10.100.2.1/32 was received from the alternate neighbor in the same second, and the alternate route was subsequently added.
Therefore, when multiple equal-metric RIPv2 paths are available, the observed failover time can depend on when the next valid RIP advertisement containing the alternate route is received.
Reducing the RIP update timer results in more frequent RIP routing updates and should be evaluated according to the network design and routing requirements.
Sniffer for RIP packets:
diagnose sniffer packet any "port 520" 4
Debug commands:
diagnose ip router rip all enable
diagnose debug enable
diagnose debug disable
diagnose ip router rip all disable
Commands to check routing entry and interface:
get router info rip database
get router info routing-table all
get router info routing-table details
get router info routing-table rip
get router info rip interface
| 
