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.