Lab: HSRP Example

Building on top of the HSRP Concept Notes I posted previously, here we will demonstrate a practical example of how HSRP is configured and how it works.

Let’s begin.

Topology

Scenario

You work for a company specialising in Car Sales. This company has 2 sites, one in London and the other in Tokyo.

Both sites have 2 Edge Routers connecting to the ISP. Your job is to use HSRP to ensure that regardless of what Edge Router is being used to send/receive traffic between sites, traffic will be continuous and will experience minimal disruption if either Edge Router fails.

London Site Requirements:

  • R1 should be the main device through which traffic flows by default
  • If the Ethernet 0/0 Interface connected to R1 goes down, R1 should no longer be used as the active device and R2 should instantly take over

Tokyo Site Requirements:

  • R2 should be the main device through which traffic flows by default
  • If the Ethernet 0/1 Interface connected to R2 goes down, R2 should no longer be used as the active device and R1 should instantly take over

You have access to one PC in each of the London and Tokyo sites to carry out basic testing.

Solution

From the topology, we can understand that we will need to configure 2 instances of HSRP, one for each site. Let’s start with the London site and then move on to Tokyo.

London:

First thing we need to do is enable HSRP for the 2 Routers. Starting on R1_London, we can see that the interface we want to configure HSRP on is ethernet 0/0.

We will use a Group Number of 1 and assign an IP of 192.168.1.3 to the newly made Virtual HSRP instance.

Now we will apply a similar configuration to the ethernet 0/0 interface on the R2_London Router.

Remember to keep the same Group Number as we did for R1_London:

Lastly, we need to ensure that the Default Gateway for our devices are set to use this new HSRP Virtual IP. For the sake of simplicity we have not mentioned any DHCP servers and will set the Default Gateway manually on our Windows Hosts:

We should also ping the Virtual Gateway IP just to make sure everything is running smoothly so far.

Success!

While we are here, let’s also verify our HSRP status on both Routers:

And for R2:

HSRP is now up and running for the London site, but wait! Remember the requirements we had to meet? Let’s look at them again:

London Site Requirements:

  • R1 should be the main device through which traffic flows by default
  • If the Ethernet 0/0 Interface connected to R1 goes down, R1 should no longer be used as the active device and R2 should instantly take over

Although we have HSRP configured, we haven’t told it how to act according to what we want.

R1 should be the main device through which traffic flows by default

We can satisfy this requirement using our own custom Priority levels.

In HSRP that when it comes to Priority Levels, the default is 100 but higher is always better/preferred. We didnt configure any Priorities yet, and we can confirm from the ‘show standby’ outputs from both devices above that they are both set to Priority 100.

Since we want R1 to be the Active Router by default, we will up the Priority to a nice round figure of 150. We will also add in the ‘preempt’ command so that if R1 happens to boot up after R2 (for whatever reason), it will pre-emptively take the role of Active Router instead of waiting to do so at the next boot (which is HSRP default behaviour).

Great! Let’s look at the second and final requirement for London:

If the Ethernet 0/0 Interface connected to R1 goes down, R1 should no longer be used as the active device and R2 should instantly take over

To meet this requirement, we need to implement Interface Tracking on R1 Ethernet 0/0.

Since our Priority is 150 for R1 and 100 for R2, we need to make sure that if the Ethernet 0/0 interface goes down, then the Priority on R1 becomes smaller than 100 so that R2 can instantly take over. 80 sounds good. This means that if Ethernet 0/0 goes down, the Priority for R1 will become 70 and allow R2 to take over.

Using a tracking object number of 1, let’s configure the decrement value on R1:

The fact that the word ‘instantly’ was mentioned in regards to R2 taking the role of Active Router indicates that R2 must also be configured with the ‘preempt’ command:

Awesome! Now we have fully configured our London site.

Let’s zoom through to configuring Tokyo now.

Tokyo:

Here’s another look at the topology so you don’t have to scroll all the way up:

Seeing as the Tokyo configuration is very similar to London’s, we can speed through things a bit quicker.

Let’s start by enabling HSRP on both Routers:

Set the Default Gateway on our test Windows Endpoint to use the Tokyo Virtual HSRP IP:

Just like before, lets do a test to see if our Windows machine can reach the Virtual IP without any problems:

Success!

Let’s take a look at our Tokyo site requirements:

Tokyo Site Requirements:

  • R2 should be the main device through which traffic flows by default
  • If the Ethernet 0/1 Interface connected to R2 goes down, R2 should no longer be used as the active device and R1 should instantly take over

Starting with the first requirement:

R2 should be the main device through which traffic flows by default

We can change the Priority to a value which is higher than the current default (100). Keeping in line with the London site (although not necessary), we will use the same value of 150 for R2, and the same ‘pre-empt’ command:


Moving on to the second requirement:

If the Ethernet 0/1 Interface connected to R2 goes down, R2 should no longer be used as the active device and R1 should instantly take over

Again, we will implement this using Interface Tracking (with the same decrement of 80):


Not forgetting our friendly ‘preempt’ command on R1 to allow it to take over ‘instantly’:

And we are done!

Summary

We have now configured resiliency using HSRP on both sites according to the required conditions. Traffic disruption in event of failure of either Router will be minimal.

1 thought on “Lab: HSRP Example

Leave a Comment