So, back to HSRP and EIGRP. From Part 1, connectivity in the lab setup was working fine during my tests until I disconnected the Data Centers HSRP interfaces. Then we lost ping completey to our remote site. It took a while to figure out, but here’s what was happening.
On the EIGRP/VPN side, we had two VPN tunnels setup on the Remote Router – one tunnel to each of our Corporate Routers. All three routers are running EIGRP, which gave the Remote Router two routes to the Corporate network. When I disconnected the HSRP interface on Data Center Router 1 (126.96.36.199), the primary VPN tunnel went down, as well as the primary EIGRP route, and the Remote Router switched over to the secondary VPN tunnel, and EIGRP route number two. So far, so good.
However, back in the Data Center, our PC Host is still trying to reach the Remote Router through the primary VPN tunnel, and Corporate Router 1 is still forwarding traffic through EIGRP route number one, having no knowledge of EIGRP route number two (on Corporate Router 2). Packets from the PC Host are forwarded to the Remote Router on the primary VPN Tunnel (which is down), but the only available return path from the Remote Router is the secondary VPN Tunnel. This is a problem. But what is the solution?
Like usual in Cisco-land, there are multiple solutions. After having a lengthy chat with my good buddy Google, I choose this one: use IP SLA to track the availability of both the internal and external interfaces of the Data Center Routers. Then, make the HSRP failover on our Corporate Routers occur whenever any of those interfaces went down. This way, whenever the Data Center HSRP failover occurs, our HSRP failover would also occur, thus insuring our Hosts and Remote Routers would always be communicating over the same VPN Tunnels, and the same routes.
Below is a sample config snippet for the statements to make this happen on our Corporate Router 1.
NOTE: this IOS version is 15.0, but for the HSRP, IP SLA and tracking cmds, it’s functionally the same as 12.4.
track 1 ip sla 1 reachability
### Establishes the object tracking of IP SLA 1, which will be used by HSRP###
track 2 ip sla 2 reachability
### Establishes the object tracking of IP SLA 2, which will be used by HSRP###
ip address 188.8.131.52 255.255.255.128
standby version 2
standby 1 ip 184.108.40.206
standby 1 priority 110
standby 1 preempt
standby 1 track 1 decrement 20
###Tracks reachability of 220.127.116.11, and decreases HSRP router priority by 20 points if 18.104.22.168 goes down, triggering an HSRP failover###
standby 1 track 2 decrement 20
###Tracks reachability of 22.214.171.124, and decreases HSRP router priority by 20 points if 126.96.36.199 goes down, triggering an HSRP failover###
ip sla 1
icmp-echo 188.8.131.52 source-ip 184.108.40.206
ip sla schedule 1 life forever start-time now
###Sets up the pings every 5 seconds to 220.127.116.11, using the local routers external IP as the source-ip###
ip sla 2
icmp-echo 18.104.22.168 source-ip 22.214.171.124
ip sla schedule 2 life forever start-time now
###Sets up the pings every 5 seconds to 126.96.36.199, using the local routers external IP as the source-ip###
No doubt this wasn’t the solution running through your mind, or you’ve a more efficient config. Either way, I’d love to hear your solutions. After all, I’m just a CCNA thrashing around in a CCNP world. However, if this is new to you like it is to me, here’s some pointers to what Cisco has say about HSRP
, IP SLA
and object tracking