CCNP Studies: Configuring HSRP – Part One

Greetings! I’m a network engineer in the Washington D.C. area, and I’m currently working my way through the CCNP. I want to share some of my findings as I lab and demystify the various exam topics. I hope we can create some discussion in comments with those of you who are also pursuing the CCNP, and I encourage the old hands to dive in, too. HSRP is on the cards today, and I’m going to break it into two parts. I’ll tackle part one today: a single VLAN configuration. In part two, we’ll optimize the design by adding some load balancing.

Ready? Let’s go!

Hot Standby Router Protocol (HSRP) developed by Cisco is used to provide layer 3 gateway redundancy. Commonly found at the distribution layer, HSRP uses a virtual IP and MAC address which a backup gateway will take control of in the event of failure. HSRP uses one Active and one Standby router. The virtual IP address is configured on both the Active and the Standby. There is only one virtual IP address and virtual MAC per HSRP group.

Timers

HSRP sends hellos to multicast address 224.0.0.2 (the “all routers” multicast address) every 3 seconds by default. The dead timer is 10 seconds by default. Both timers can be tuned in milliseconds to ensure fast failover. If the Standby router stops seeing hello packets from the Active it will assume it is down and will take over as the Active router. Timers on all routers must match.

HSRP requires layer 2 connectivity between routers.

HSRP State Machine

HSRP is a state machine consisting of these five states:

Initial: HSRP doesn’t run. This state is seen when an interface comes up
Listen: listens for hellos, knows the virtual IP
Speak: sends hellos and participates in the election
Standby: candidate for next active router
Active: currently forwards packets sent to the virtual IP

Let’s take a look at the topology we’ll be working with:

We will be configuring HSRP for VLAN 50. An HSRP group number needs to be defined on the SVI for VLAN 50. Make sure VLAN 50 exists on the devices first. The group number (1 in the example below) is only significant to the interface, but it’s a good idea to use different numbers if you have a more complex topology with multiple VLANs. There can be only one Active and one Standby router per HSRP group. The Standby router will only step in if the Active fails. It’s important that the HSRP Active router is also the spanning tree root in order to avoid suboptimal paths. In this topology, we want DSW1 to be our Active router, and SW1 and SW2 should forward traffic directly to it. If spanning tree wasn’t configured to match the HSRP topology, then DSW2 could be the root switch. Traffic would flow via DSW2 to DSW1 – not what we want!

Here’s the first part of the configuration:

interface Vlan50
ip address 10.10.50.2 255.255.255.0
standby 1 ip 10.10.50.1
end

We configure the VLAN 50 interface and then initiate HSRP specifying the virtual IP address 10.10.50.1.

HSRP uses a combo of virtual IP and virtual MAC address. The MAC uses the format: 0000.0C07.ACXX (XX being the group number in hexadecimal). The virtual IP and MAC will be used by the Standby router if the Active router fails.

Virtual IP address is 10.10.50.1
Active virtual MAC address is 0000.0c07.ac01

Priority

We want to ensure DSW1 is always the Active router when the network is stable, so we need to configure the priorities of DSW1 and DSW2. There are two things to configure here – priority and preemption.

The default HSRP priority is 100, which won’t appear in the configuration. We’ll set the priority of DSW1 to 150 (Range 0-255).

DSW1(config-if)#standby 1 priority 150

Preempt

An HSRP router won’t attempt to become the active router when introduced to an existing topology, even if it has a higher priority. We want DSW1 to always be the Active router if it is up and the topology is stable so we need to turn on “preempt.” Preempt will cause the router to initiate an election if it has a higher priority. If priorities are equal, the router with the highest IP address will win an election.

DSW1(config-if)#standby 1 preempt

If DSW1’s uplink to the core fails then comes back online, we want to ensure our routing protocol has completely converged prior to DSW1 assuming the Active role again. We can configure a preempt delay to allow time for this to happen.

DSW1(config-if)#standby 1 preempt delay minimum 60

Tuning the timers

Now let’s tune the timers from their defaults. As I mentioned earlier, HSRP timers can be set in seconds or milliseconds. We’re aiming for fast convergence here so we’ll set hellos at 200 and the dead timer at 600 milliseconds.

DSW1(config-if)#standby 1 timers msec 200 msec 600

That’s DSW1 configured, onto DSW2:

interface Vlan50
ip address 10.10.50.3 255.255.255.0
standby 1 ip 10.10.50.1
standby 1 timers msec 200 msec 600
standby 1 priority 110
end

DSW2’s priority is set at 110 in order to help guarantee the topology. A third router could be added into the mix at a later stage, potentially leaving us with two routers holding priorities of 100 so it’s best to configure priority on the Standby.

Okay, we’re in business! Let’s verify the config:

DSW1 has a priority of 150 and is configured to Preempt (P).  The Active column shows “local”, indicating DSW1 is the Active router and DSW2 (10.10.50.3) is the Standby.

Here’s the output from DSW2:

Interface tracking

So, what we have implemented now will handle a failure if DSW1 dies completely, but what we need to do is put some tests in place so DSW2 takes over if DSW1’s uplink to the core fails.

HSRP interface tracking will be used and if one of the uplinks goes down (determined by line protocol status) DSW1’s priority will be decremented by 50 causing DSW2 to take over as the Active router.

DSW1(config-if)#standby 1 track fa0/24 50

Hang on, what’s missing here? DSW2 needs preempt enabled so it can assume Active status once it seems DSW1’s priority drop to 100.

DSW2(config-if)#standby 1 preempt

Now the Ethernet cable from fa0/24 is pulled to test the failover.

Boom! There you have it, HSRP configured to serve one VLAN with tuned timers and interface tracking. Watch out for my next post where we’ll explore a more complex HSRP topology with some added load balancing.

Edward Yardley

Edward Yardley

Edward is a Network Engineer with 10 years experience in the IT industry but is a new comer to pure networking. He has worked in web development, as a systems administrator, and has recently dived into the networking world. Find him blogging @ PacketPushers.net and on Twitter.
  • Techkid

    Thanks a lot for this article. Im also studying for my CCNP. Its always good to hear from peers who are on the same journey. Cheers

    • sokolua dos santos

      Can we configure HSRP on a router ?

      • http://rowell.dionicio.net/ Rowell Dionicio

        You can configure HSRP on a router as long as the IOS supports it.

  • Kevin Breit

    Thanks for posting this. I’m studying the CCNP SWITCH and most of the text online is about the ROUTE exam, not the SWITCH.

  • vinu

    Can we track any remote ip instead of Interface line protocol state??? Pls reply
    Thanks,

    • http://twitter.com/edwardyardley Edward Yardley

      Hi vinu, yes you can using “standby 1 track (tracked object number)”. You would first need to create an IP SLA that tracked the remote IP, schedule it, and then created a tracked object for HSRP to monitor.

      • vinu

        Thanks Edward

      • Ruci Antassani

        Hi Edward, can you show me an example how to do that???
        Pls reply
        Thanks in advance

  • Willard Dennis

    Thanks for the CCNP material! Also on the journey… Keep ‘em coming!

  • http://marathon-networks.com/ Dan

    On the active node, I usually set the priority to 109. That way tracking will automatically set the value below 100 when its triggered.

  • Geoff

    Good stuff…thank you!

  • Route Switch

    This was a great write up, it answered a couple of questions I had without the 500 words of fluff, thanks

  • raju

    Keep going…. very good stuff….

  • Ian

    Great article, I’ve done a similar setup in packet tracer with dws1 and dws2 connecting to the same wan router. Before I was going to set up interface tracking I tested it by breaking the connection between DWS1 and the core wan router and pings still worked from a pc connected to SW1 to the core.

    Is this because I have OSPF running between DWS1/2 and the wan router?

    Cant see why this interface tracking would be needed then? Or is running a routing protocol between the distribution and the WAN not advised?