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.

R1_London(config)# interface ethernet 0/0
R1_London(config-if)# standby 1 ip 192.168.1.3

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:

R2_London(config)# interface ethernet 0/0
R2_London(config-if)# standby 1 ip 192.168.1.3

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.

C:\Users\London_Administrator>ping 192.168.1.3

Pinging 192.168.1.3: bytes=32 time<1ms TTL=255
Pinging 192.168.1.3: bytes=32 time<3ms TTL=255
Pinging 192.168.1.3: bytes=32 time<2ms TTL=255
Pinging 192.168.1.3: bytes=32 time<1ms TTL=255

Ping statistics for 192.168.1.3:
	Packets: Sent = 4, Receieved = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 0ms, Maximum = 3ms, Average = 1ms

C:\Users\London_Administrator>
C:\Users\London_Administrator>

Success!

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

R1_London#
R1_London#show standby

Ethernet0/0 - Group 1
  State is Active
  Virtual IP address is 192.168.1.3
  Active virtual MAC address is 0000.0c07.ac01
    Local virtual MAC address is 0000.0c07.ac01 (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 1.632 secs
  Preemption disabled
  Active router is local
  Standby router is 192.168.1.1, priority 100 (expires in 11.200 sec)
  Priority 100 (default 100)
  Group name is "hsrp-Et0/0-1" (default)

R1_London#
R1_London#

And for R2:

R2_London#
R2_London#show standby 

Ethernet0/0 - Group 1
  State is Standby
  Virtual IP address is 192.168.1.3
  Active virtual MAC address is 0000.0c07.ac01
    Local virtual MAC address is 0000.0c07.ac01 (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 2.064 secs
  Preemption disabled
  Active router is 192.168.1.2, priority 100 (expires in 9.232 sec)
  Standby router is local
  Priority 100 (default 100)
  Group name is "hsrp-Et0/0-1" (default)

R2_London#
R2_London#

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).

R1_London(config)# interface ethernet 0/0
R1_London(config-if)# standby 1 priority 150
R1_London(config-if)# standby 1 preempt

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:

R1_London(config)# interface ethernet 0/0
R1_London(config-if)# standby 1 track 1 decrement 80

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:

R2_London(config)# interface ethernet 0/0
R2_London(config-if)# standby 1 preempt

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:

R1_Tokyo(config)# interface ethernet 0/1
R1_Tokyo(config-if)# standby 1 ip 192.168.2.3
R2_Tokyo(config)# interface ethernet 0/1
R2_Tokyo(config-if)# standby 1 ip 192.168.2.3

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:

C:\Users\Tokyo_Administrator>ping 192.168.2.3
 
Pinging 192.168.2.3: bytes=32 time<1ms TTL=255
Pinging 192.168.2.3: bytes=32 time<2ms TTL=255
Pinging 192.168.2.3: bytes=32 time<3ms TTL=255
Pinging 192.168.2.3: bytes=32 time<1ms TTL=255
 
Ping statistics for 192.168.2.3:
	Packets: Sent = 4, Receieved = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 0ms, Maximum = 3ms, Average = 1ms
 
C:\Users\Tokyo_Administrator>
C:\Users\Tokyo_Administrator>

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:

R2_Tokyo(config)# interface ethernet 0/1
R2_Tokyo(config-if)# standby 1 priority 150
R2_Tokyo(config-if)# standby 1 preempt

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):

R2_Tokyo(config)# interface ethernet 0/1 
R2_Tokyo(config-if)# standby 1 track 1 decrement 80

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

R1_Tokyo(config)# interface ethernet 0/1
R1_Tokyo(config-if)# standby 1 preempt

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.

Leave a Reply

Your email address will not be published.