Cisco Policy Route with IP SLA Failover

Customer has 2 physical circuits, Comcast Business Cable with 1 static IP, and a multi-t1 bundle to Verizon Business. Comcast will be used as the primary egress for internet browsing. Inbound email, web, and RDP services are mapped via static nats on a Cisco ASA that handles the Verizon connection. The Comcast connection has its own ASA for firewalling. Traffic needs to be sticky (i.e. it must go back out the same firewall it came in on or else the stateful packet inspection on the ASAs as well as the outbound NATs will break and the traffic will drop.

The inside core router that is the default gateway and connects to remote frame-relay sites has a local policy map (source-based routing config) so that it can push traffic to and from the servers out Verizon. All other traffic flows out Comcast by default.

We need an IP SLA monitor on the internal router that pings (thru the verizon side ASA) the verizon uplink serial IP address. If Verizon goes down, or the Verizon ASA firewall dies, we want all traffic to fail over to Comcast completely - without checking the policy routing map. The reason for this is that there are 2 internal DNS servers on the network also have other inbound services on them, so when Verizon goes down, users on the network cannot resolve DNS queries properly because the 2 DNS servers cannot get out the Verizon path.

We also want an IP SLA on the comcast side so that if Comcast or the Comcast ASA firewall goes down, all internet traffic will fail over to Verizon.

1.1.1.1 = the ip address of the Comcast uplink or upstream router that is reachable 
across the Comcast cable link.

2.2.2.2 = the ip address of the verizon uplink reachable across the t1 bundle

10.0.0.254 = inside ip of comcast ASA firewall 
10.0.0.252 = inside ip of Verizon ASA firewall

These commands setup the ip sla monitors and tracking objects:
ip sla 1
 icmp-echo 1.1.1.1
 frequency 30
ip sla schedule 1 life forever start-time now
ip sla 2
 icmp-echo 2.2.2.2
 frequency 30
ip sla schedule 2 life forever start-time now

track 1 rtr 1
track 2 rtr 2

Our primary default route is via comcast, and is tracked against track object 1. When
the monitor for 1 fails, the route will be deleted, and traffic will be routed based on the
2nd backup route, which has a higher admin distance; distance 240 is preferred over
250.

ip route 0.0.0.0 0.0.0.0 10.0.0.254 240 name def_rt_via_comcast track 1
ip route 0.0.0.0 0.0.0.0 10.0.0.252 250 name def_rt_via_vz

These 2 routes are needed so that the monitoring points (our ip pipe upstreams) are forced
to go out via the correct firewall. Otherwise a failure condition may not be detected at the firewall level for example if the outside Comcast IP is pinged ok, but traffic flows via the
verizon circuit.

ip route 166.61.239.57 255.255.255.255 10.100.200.252 name vz_uplink
ip route 173.15.204.182 255.255.255.255 10.100.200.254 name ip_sla_comcast_track

This route-map defines our source ip routing policy. If the source (sending address) of the
packet matches access-list 161, then traffic will be sent via the verizon ASA firewall (.252).
If the tracking object for track 2 (verizon upstream) goes down, then the policy will be de-activated and ignored, until the reach-ability for track object 2 is restored.

route-map use_vz_t1 permit 10
 match ip address 161
 set ip next-hop verify-availability 10.0.0.252 1 track 2

This is how the routing policy is bound to an input interface on the router - all PC and
server traffic flows to this ip address where it will then send the traffic to one of the 2
upstream ASAs based on the tracking and the policy status.

interface FastEthernet0/1
description Default Gateway all PC and server traffic flows to this ip addres 
 ip address 10.0.0.253 255.255.255.0
 no ip redirects
 ip policy route-map use_vz_t1

This statement binds the policy to packets locally generated from the router itself - i.e.
pings, telnet, or other management traffic that is SOURCED from the router. If the router
does not have an ip address listed in acl 161, then this statement will not really do
anything. It is useful though for testing a policy locally on a router, before placing it on
the whole network.

On nuance with the access list is that because Cisco does not allow us to use a default next ip hop check all traffic that matches a permit statement in acl 161 will flow according to the policy next hop. Thus we need to exclude all intra-lan traffic from the policy using deny statements in acl 161:

ip local policy route-map use_vz_t1

access-list 161 remark these hosts/servers must use verizon t1 for inet
access-list 161 remark all other hosts use comcast.
access-list 161 remark do not use the ip policy for private lan to
access-list 161 remark private lan traffic:
access-list 161 deny   ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
access-list 161 deny   ip 10.0.0.0 0.255.255.255 192.168.0.0 0.0.255.255
access-list 161 deny   ip 10.0.0.0 0.255.255.255 172.16.0.0 0.15.255.255
access-list 161 deny   ip 192.168.0.0 0.0.255.255 10.0.0.0 0.255.255.255
access-list 161 deny   ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255
access-list 161 deny   ip 192.168.0.0 0.0.255.255 172.16.0.0 0.15.255.255
access-list 161 permit ip host 10.0.0.3 any
access-list 161 permit ip host 10.0.0.12 any
access-list 161 permit ip host 10.0.0.2 any
access-list 161 permit ip host 10.0.0.1 any

We can monitor the state of our tracking object - in this example track object 2, which
has 79 ok pings and no failures:

sh ip sla statistics 2

Round Trip Time (RTT) for	Index 2
	Latest RTT: 3 milliseconds
Latest operation start time: 15:33:05.486 est Wed Jan 13 2010
Latest operation return code: OK
Number of successes: 79
Number of failures: 0
Operation time to live: Forever

We can also inspect the policy map to see if the policy is active - and in this case it is
marked as [up] since the tracking object (2) is good as we saw above.

sh route-map use_vz_t1 
route-map use_vz_t1, permit, sequence 10
  Match clauses:
    ip address (access-lists): 161 
  Set clauses:
    ip next-hop verify-availability 10.0.0.252 1 track 2  [up]
  Policy routing matches: 254531728 packets, 1867101653 bytes