Overview
The route monitoring feature on the Firewall Services Module (FWSM) allows one to install both a primary and secondary (backup) route into the routing table. The FWSM will use the primary route as long as the next-hop gateway is reachable (via ICMP pings). If the next-hop gateway becomes unreachable, the primary route is removed, and the secondary (backup) route is installed in the table. If the primary route's next-hop gateway becomes reachable again, then the primary route is restored.
The FWSM's route-monitoring feature provides a very simple way to allow a single backup gateway to be used when the primary gateway is unavailable.
Requirements
- The FWSM must be running version 4.0(1) or higher.
- The Route-monitor feature only works with static routes.
Topology
In the topology below, the FWSM's VLAN 10 interface has two routes to reach the 203.0.113.0/24 network. The first is through the Primary gateway at 10.10.10.1, and the backup is via the 10.10.10.2 gateway.
Configuration
The pre-existing configuration on the FWSM is as follows:
interface Vlan10
nameif Outside
security-level 0
ip address 10.10.10.200 255.255.255.0
!
route Outside 203.0.113.0 255.255.255.0 10.10.10.1 1
route Outside 203.0.113.0 255.255.255.0 10.10.10.2 1
With the above configuration, the FWSM will load-balance across the two gateways for traffic destined to the 203.0.113.0 network. However, that is not what we want to accomplish. Instead, we would like to use the 10.10.10.2 gateway as a backup. To acheive that goal, one only needs to add the following line to the FWSM's configuration:
route-monitor 203.0.113.0 255.255.255.0
Note that the route-monitor command takes in the network and netmask of the route you want tracked, NOT the IP/host of the device to be tracked. With the network identified, the FWSM will start sending ICMP pings to the next-hop gateway specified in the static route command.
As soon as the route-monitor command is entered, the FWSM will increase the administrative distance of the 2nd (backup) route in the configuration so that it is not used. Additionally, one will see the following messages from the FWSM:
The Metric of 10.10.10.2 is changed to 2 due to Route Monitoring.
Route Monitor requires ICMP be permitted on the interfaces which has 203.0.113.0 Route.
The second message is just a reminder that by default, the FWSM will drop all ICMP traffic destined to it (including the echo-replies from the route monitor). Therefore, you must ensure you add and icmp permit entry to allow the echo-replies from the gateways. In our case, we'll allow all echo-replies from anything on the 10.10.10.0/24 network with the command:
icmp permit 10.10.10.0 255.255.255.0 echo-reply Outside
With the above configured, our routing table now looks as follows:
FWSM(config)# show route
C 10.10.10.0 255.255.255.0 is directly connected, Outside
C 10.36.0.0 255.255.0.0 is directly connected, inside
S 172.16.0.0 255.255.0.0 [1/0] via 10.36.1.1, inside
S 203.0.113.0 255.255.255.0 [1/0] via 10.10.10.1, Outside
Note that we only see the Primary route to 203.0.113.0/24 installed in the routing table.
If we look at our configuration, we can see that the backup route to 203.0.113.0/24 is in the configuration, but its administrative distance has been increased to 2.
FWSM(config)# show run route
route Outside 203.0.113.0 255.255.255.0 10.10.10.1 1
route Outside 203.0.113.0 255.255.255.0 10.10.10.2 2
route inside 172.16.0.0 255.255.0.0 10.36.1.1 1
Operation
While route monitoring is enabled, the FWSM will send an ICMP echo-request to the next-hop gateway every 300 ms. This is configurable by using the optional query-interval keyword at the end of the route-monitor command. The acceptable range for the query is from 100 ms - 3 sec.
If the next-hop gateway becomes unreachable, then after 5 missed echo-replies - or 1.5 seconds (300 ms * 5), the FWSM will increase the administrative distance of the primary route, to remove it out of the routing table, and the backup route is installed. The number of missed echo-replies before the FWSM determines a failure occurred is also configurable using the optional max-failures keyword at the end of the route-monitor command. The acceptable range is from 3-10.
FWSM(config)# show route
C 10.10.10.0 255.255.255.0 is directly connected, Outside
C 10.36.0.0 255.255.0.0 is directly connected, inside
S 172.16.0.0 255.255.0.0 [1/0] via 10.36.1.1, inside
S 203.0.113.0 255.255.255.0 [2/0] via 10.10.10.2, Outside <----- Backup route now installed
with admin distance of 2
Also, one can view the configuration to see that the administrative distance of the primary route is now larger (3) than that of the backup route (2)
FWSM(config)# show run route
route Outside 203.0.113.0 255.255.255.0 10.10.10.2 2 <----- Backup with admin distance of 2
route Outside 203.0.113.0 255.255.255.0 10.10.10.1 3 <----- Primary with admin distance of 3
route inside 172.16.0.0 255.255.0.0 10.36.1.1 1
Verification
To verify that route-monitor is working properly, you can enable the debug route-monitor command. You will see the success or failure of the pings to the next-hop gateways.
FWSM(config)# debug route-monitor
Route-Monitor Debug is on
RM: Sending Ping to 10.10.10.1; Success
RM: Sending Ping to 10.10.10.2; Success
RM: Sending Ping to 10.10.10.1; Success
RM: Sending Ping to 10.10.10.2; Success
RM: Sending Ping to 10.10.10.1; Success
RM: Sending Ping to 10.10.10.2; Success
When the next-hop gateway becomes unreachable, the debugs will change to:
RM: Sending Ping to 10.10.10.1; Failure
RM: Sending Ping to 10.10.10.2; Success
RM: Sending Ping to 10.10.10.1; Failure
RM: Sending Ping to 10.10.10.1; Failure
RM: Sending Ping to 10.10.10.2; Success
RM: Sending Ping to 10.10.10.1; Failure
RM: Sending Ping to 10.10.10.1; Failure