IP SLA with HSRP

My friend recently had an implementation involving an EoSDH connection from one site to another involving 2 routers. LAN side of Site 1 requires HSRP to be running and it needs to track the EoSDH connection so the Active HSRP will shift to R2 incase of primary link failure. The problem is most EoSDH connection like his implementation has no way of detecting Layer 1 and Layer 2 failures upstream because there are switches installed in the customer premise and even within the ISP EoSDH connection. Houston we have a problem! :)

As a solution he can have a transit connection between R1 and R2 and run OSPF but configure the routes received from R2 to have a higher admin distance than the OSPF which has 110. He could also use IP SLA feature to detect failures and track it in the HSRP group so that any breaches on the configured IP SLA will make HSRP decrement priority. The diagram is shown below similar to most setups.

Cisco IOS IP SLAs is a feature included in the Cisco IOS Software that can allow administrators the ability to
Analyze IP Service Levels for IP applications and services.IP SLA's uses active traffic-monitoring technology to
monitor continuous traffic on the network. This is a reliable method in measuring over head network performance.
Cisco Routers provide IP SLA Responders that give accuracy of measured data across a network.
-Wikipedia- 

In our diagram, the requirement is to run HSRP on the LAN and connect the primary router R1
and backup router, R2 to Site 2 which has R3. Connections to R1 -R3 and R2 - R3 should be in
different subnets. Imagine the network after SW1 towards R3 will be on the ISP side and could
have several switches towards R3. R1 is the Active HSRP router and R2 is the Standby.

The challenge here is how to track the EoSDH link which is like a FastEthernet/ GigabitEthernet network run across the
WAN. Tracking the interface of R1 or R2 connected to the switch won't do any good in HSRP because, even if there is
an upstream failure, that connection will still remain up. HSRP only decrements priority once it detects the router's interface
down. The solution to this problem is to configure IP SLA.

Before we proceed the routers' initial configs are shown below.

R1#
interface FastEthernet0/0
ip address 10.10.20.1 255.255.255.0
duplex full
!
interface FastEthernet1/0
ip address 192.168.100.10 255.255.255.0
duplex full
speed auto
standby 12 ip 192.168.100.1
standby 12 preempt
!
router ospf 1
log-adjacency-changes
passive-interface FastEthernet1/0
network 10.10.20.0 0.0.0.255 area 0
network 192.168.100.0 0.0.0.255 area 0

R2#
!
interface FastEthernet0/0
ip address 10.10.30.2 255.255.255.0
duplex full
!
interface FastEthernet1/0
ip address 192.168.100.20 255.255.255.0
duplex full
speed auto
standby 12 ip 192.168.100.1
standby 12 priority 91
!      
router ospf 1
log-adjacency-changes
passive-interface FastEthernet1/0
network 10.10.30.0 0.0.0.255 area 0
network 192.168.100.0 0.0.0.255 area 0

R3#
!
interface Loopback0
ip address 192.168.33.33 255.255.255.255
!
interface FastEthernet0/0
ip address 10.10.20.3 255.255.255.0
duplex full
!
interface FastEthernet1/0
ip address 10.10.30.3 255.255.255.0
duplex full
speed auto
!
router ospf 1
log-adjacency-changes
network 10.10.20.0 0.0.0.255 area 0
network 10.10.30.0 0.0.0.255 area 0
network 192.168.33.33 0.0.0.0 area 0
distance 254 10.10.30.2 0.0.0.0

Now, lets configure and SLA that constantly pings the Loopback address of R3 from R1. We will set the frequency of 10 , timeout and threshold of 2000.

R1(config)#ip sla monitor 1
R1(config-sla-monitor)#type echo protocol ipIcmpEcho 192.168.33.33
R1(config-sla-monitor-echo)#timeout 2000
R1(config-sla-monitor-echo)#threshold 2000
R1(config-sla-monitor-echo)#frequency 10

The frequency means it will do a ping in every 10 seconds to check if the configured netework is still reachable. The timeout and threshold values will determine if there is a "breach" in the configured SLA. Now let's start the SLA now and let it continue "forever" as long as the router is alive. You can also set other parameters like what time of the day this will start and what time it will end.

R1(config)#ip sla monitor schedule 1 start-time now life forever

Let's do a "debug ip icmp" and see if it is really doing its job now.

R1#debug ip icmp
ICMP packet debugging is on
R1#
*Sep  2 10:57:31.507: ICMP: echo reply rcvd, src 192.168.33.33, dst 10.10.20.1
*Sep  2 10:57:41.523: ICMP: echo reply rcvd, src 192.168.33.33, dst 10.10.20.1
*Sep  2 10:57:51.523: ICMP: echo reply rcvd, src 192.168.33.33, dst 10.10.20.1
*Sep  2 10:58:01.547: ICMP: echo reply rcvd, src 192.168.33.33, dst 10.10.20.1

Ok, its clear its receiving replies every 10 seconds. We are not done yet, we have to configure this to be tracked by HSRP.

R1(config)#track 1 rtr 1 reachability
R1(config-track)#int fa1/0
R1(config-if)#standby 12 track 1 decrement 11

The command "track 1 rtr 1" means that the IP SLA 1 is marked as tracked number 1. It doesn't matter what track number you use. Now, the HSRP config means that if the SLA is "breached" decrement by 11. First let's see the statistics of the configured IP SLA.

R1#sh ip sla monitor statistics 1
Round trip time (RTT)   Index 1
Latest RTT: 28 ms
Latest operation start time: *11:04:01.523 UTC Wed Sep 2 2009
Latest operation return code: OK
Number of successes: 42
Number of failures: 0
Operation time to live: Forever

I will shut down the connection from R1 to R3. The threshold and timeout are set to 2000 but if there isn't a reply its also a breach. Let's check what happens to the HSRP.

R1#sh standby br
         P indicates configured to preempt.
         |
Interface   Grp Prio P State    Active          Standby         Virtual IP
Fa1/0       12  89   P Standby  192.168.100.20  local           192.168.100.1

When the router is able to ping again the loopback of R3. The HSRP state will become active again.