HSRP and EIGRP: Part 2

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 (1.1.1.2), 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###
!
!
<<<Output Omitted>>>
!
!
interface GigabitEthernet0/0
ip address 172.150.1.10 255.255.255.128
duplex auto
speed auto
standby version 2
standby 1 ip 172.150.1.1
standby 1 priority 110
standby 1 preempt
standby 1 track 1 decrement 20
###Tracks reachability of 1.1.1.2, and decreases HSRP router priority by 20 points if 1.1.1.2 goes down, triggering an HSRP failover###
standby 1 track 2 decrement 20
###Tracks reachability of 2.2.2.2, and decreases HSRP router priority by 20 points if 1.1.1.2 goes down, triggering an HSRP failover###
!
!
<<<Output Omitted>>>
!
!
ip sla 1
icmp-echo 1.1.1.2 source-ip 1.1.1.10
frequency 5
ip sla schedule 1 life forever start-time now
###Sets up the pings every 5 seconds to 1.1.1.2, using the local routers external IP as the source-ip###
ip sla 2
icmp-echo 2.2.2.2 source-ip 1.1.1.10
frequency 5
ip sla schedule 2 life forever start-time now
###Sets up the pings every 5 seconds to 2.2.2.2, 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.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s