High Availability..

HSRP for the WAN:

My first post will be my recent findings and experimentation with Layer 3 High Availability.. Specifically using HSRP.

I must say - these techniques have mostly been transparent to me so far in my career/studies, and finally having a grasp on their architectures is very rewarding.

HSRP and VRRP are incredibly similar.. the main difference being HSRP is a Cisco proprietary protocol, where VRRP is a standards based protocol. Both are designed to provide the exact same redundancy - mainly gateway or Layer 3 redundancy for clients. The opportunity to use both of these protocols is abundant, and any enterprise network is bound to use either of these protocols or GLBP somewhere along the line, whether it be internal or WAN facing.

Recently I was tasked with providing for a redundant solution using two WAN facing routers connecting to various remote offices. The two redundant routers on the head office side are running GRE tunnels over a Service Provider MPLS network in order to reach their intended destinations. The goal was to have two routers, one one of them which will run as a hot standby router, and the other will be the primary forwarder. The design goal was simple.. run HSRP on the internal interfaces (LAN) and tweak OSPF metrics in order to favor the primary router if it up and running. The task also involved adding static routes on the area office and head office side in order to prevent recursive routing. Recursive routing is when the routing engine believes the best way to reach the tunnel destination is through the tunnel itself.. however this process creates somewhat of a continuous loop. The router sends the data to the tunnel interface.. however the tunnel interface references the tunnel destination for a real physical destination and since the routing table would point to the tunnel interface as the path to reach that destination, you would have a continuous loop. Thankfully the software is smart enough to place an error in this situation, rather than a continuous loop crashing the router.

So now that this solution is working.. it is important to remember.. That the Active router or forwarder will continue to be the forwarder even if its primary link to the WAN is down completely. This would create a complete black hole, where traffic would be sent to the active and have absolutely no path outbound. The solution is to use HSRP tracking!! We can track the WAN interface on both WAN routers, decrementing its priority in the case the WAN interface were to either have its line-protocol or ip-routing capability go down. In our case, we used line-protocol, as this is more deterministic. The HSRP priority is the only way to measure which router should be the forwarder of the HSRP group... and one major caveat to remember is to NOT forget to use the preempt command. Using preempt will allow your standby router to immediately take over the active HSRP router if its own priority exceeds that of the active. This is ESSENTIAL in this design.. as the active router's WAN connection could down, it's priority could drop to 0.. however if the standby router does not PREEMPT (the default is to NOT preempt), there will be no failover to the standby. You see, HSRP standby by default will only take over the active role if the active router completely disappears and stops sending hello messages to the multicast address of 224.0.0.2 (UDP 1985). This is not ideal in our design.. so we will simply add the "standby # preempt" command, to remedy this situation.

Sample Configuration:

Router 1 (Active)

interface Gig0/0

ip address 192.168.0.2 255.255.255.0

standby 1 ip 192.168.0.1

standby 1 authentication ISPexpert

standby 1 preempt

standby 1 priority 200

standby 1 track interface Gig0/1 line-protocol decrement 100

//Gig0/1 is the WAN interface

Router 2 (Standby)

interface Gig0/0

ip address 192.168.0.3 255.255.255.0

standby 1 ip 192.168.0.1

standby 1 authentication ISPexpert

standby 1 preempt

standby 1 priority 150

standby 1 track interface Gig0/1 line-protocol decrement 100

In this situaiton, this is really all we need to do from an HSRP perspective.

I will be posting more information on GRE tunnels and topics such as VRRP and GLBP... as they have proven to have certain complexity and esoteric tendency which are not fully documented by Cisco or anywhere else I have tried to research...

Bye for now..

Kyle