Monitor static route tracking:

You can monitor the status of a tracking process with any of the following EXEC commands:

Firewall# show track Firewall# show route Firewall# debug track

Firewall# debug sla monitor trace

Reachable Static Route Example

A firewall has two paths to the outside Internet, using two independent ISPs, as shown in Figure 3-10. The firewall can be configured with two default routes that point to the two ISP routers, 10.1.1.100 and 10.1.1.200. Outbound traffic toward the Internet is balanced across the two default routes, and across the two ISPs.

Figure 3-10. An Example Network Using Reachability Information [View full size image]

The firewall is also configured to track the reachability of each ISP, so that the appropriate static route can be deactivated if an ISP connection is down. SLA monitor test 1 is configured to perform echo tests on the ISP1 router at 10.1.1.100, while SLA test 2 checks the ISP2 router at 10.1.1.200. The following commands can be used to configure the reachability tests and static routes:

Code View: Scroll / Show All

Firewall(config)# sla monitor 1

Firewall(config-sla-monitor)# type echo protocol ipIcmpEcho 10.1.1.100 interface outside Firewall(config-sla-monitor-echo)# frequency 30 Firewall(config-sla-monitor-echo)# threshold 1000 Firewall(config-sla-monitor-echo)# timeout 3000 Firewall(config-sla-monitor-echo)# exit Firewall(config-sla-monitor)# exit

Firewall(config)# sla monitor schedule 1 life forever now !

Firewall(config)# track 1 rtr 1 reachability !

Firewall(config)# sla monitor 2

Firewall(config-sla-monitor)# type echo protocol ipIcmpEcho 10.1.1.200 interface outside Firewall(config-sla-monitor-echo)# frequency 30 Firewall(config-sla-monitor-echo)# threshold 1000 Firewall(config-sla-monitor-echo)# timeout 3000 Firewall(config-sla-monitor-echo)# exit Firewall(config-sla-monitor)# exit

Firewall(config)# sla monitor schedule 2 life forever now !

Firewall(config)# track 2 rtr 2 reachability !

Firewall(config)# route 0.0.0.0 0.0.0.0 10.1.1.100 track 1 Firewall(config)# route 0.0.0.0 0.0.0.0 10.1.1.200 track 2

Notice that each static route uses a different tracking process. That means either static route can be deactivated depending on the status of its respective next-hop router. Static route tracking is a rather silent process, and the firewall will not give you any obvious signs that it is actually testing the reachability.

To see this in action, you can use the show route command to display the current routing table contents. If both ISP router targets are reachable, then both static routes are shown, as in the following output:

Code View: Scroll / Show All Firewall# show route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, 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, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area

* - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route

Gateway of last resort is 10.1.1.100 to network 0.0.0.0 C 127.0.0.0 255.255.0.0 is directly connected, cplane

C 192.168.100.0 255.255.255.0 is directly connected, inside S* 0.0.0.0 0.0.0.0 [1/0] via 10.1.1.100, outside

[1/0] via 10.1.1.200, outside

Here, both static routes are listed, although no indication that they are conditional is listed. You can always confirm the static route configuration with the show run route command:

Firewall# show run route

route outside 0.0.0.0 0.0.0.0 10.1.1.100 track 1 route outside 0.0.0.0 0.0.0.0 10.1.1.200 track 2 Firewall#

You can also see the current status of a track process with the show track [track-id] command: Firewall# show track 1

Track 1

Response Time Reporter 1 reachability Reachability is Up

1 change, last change 00:01:03 Latest operation return code: OK Latest RTT (millisecs) 1

STATIC-IP-ROUTING 0 Firewall#

You can also enable debugging output for the tracking process. Use the debug sla monitor trace command to get some real-time indication of SLA probes as they are sent. However, to see messages indicating a change in reachability, you can use the debug track command, as in the example that follows. After each reachability change is announced, the routing table is shown for clarity. Notice how the static route to ISP2 is missing after track process 2 announces that the target is unreachable, and how the static route returns when the target comes up again.

Code View: Scroll / Show All Firewall# debug track Firewall#

Firewall#

Firewall# Track: 2 Change #1 rtr 2, reachability Up->Down Firewall# show route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, 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, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area

* - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route

Gateway of last resort is 10.1.1.100 to network 0.0.0.0 C 127.0.0.0 255.255.0.0 is directly connected, cplane

C 192.168.100.0 255.255.255.0 is directly connected, inside S* 0.0.0.0 0.0.0.0 [1/0] via 10.1.1.100, outside

Firewall# Firewall#

Firewall# Track: 2 Change #2 rtr 2, reachability Down->Up Firewall#

Firewall# show route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, 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, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area

* - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route

Gateway of last resort is 10.1.1.100 to network 0.0.0.0 C 127.0.0.0 255.255.0.0 is directly connected, cplane

C 192.168.100.0 255.255.255.0 is directly connected, inside S* 0.0.0.0 0.0.0.0 [1/0] via 10.1.1.100, outside

[1/0] via 10.1.1.200, outside Firewall#

Configuring RIP to Exchange Routing Information

Cisco firewalls can passively listen to RIP updates (either version 1 or 2) to learn routing information. Routing advertisements from the firewall are limited to one type—a firewall interface as a default route. RIP can be used in either of the following versions:

• RIP version 1, which supports only classful networks. Advertisements are broadcast unencrypted.

• RIP version 2, which supports classless networks. Advertisements can be authenticated by a cryptographic function for security purposes.

RIP routing information is used by the firewall as shown in Figure 3-11. Figure 3-11. Firewall Using RIP for Routing Information