Hot Standby Routing Protocol (HSRP)

Topology

Background

Hot Standby Router Protocol (HSRP) is a Cisco-proprietary redundancy protocol for establishing a fault-tolerant default gateway. It is described in RFC 2281. HSRP provides a transparent failover mechanism to the end stations on the network. This provides users at the access layer with uninterrupted service to the network if the primary gateway becomes inaccessible. This lab focuses on HSRP because it is commonly found in industry. The Virtual Router Redundancy Protocol (VRRP) is a standards-based alternative to HSRP and is defined in RFC 3768. The two technologies are similar in operation and configuration. Once you are familiar with HSRP configuration of VRRP is not difficult.

Preparation

This lab is written for EVE.

• Download the unconfigured HSRP lab topology here: HSRP Lab
• Unzip the file on your computer.
• Start the EVE virtual machine.
• Open a browser and enter the EVE server IP address.
• Login to EVE with "admin" and "eve".
• Install the HSRP lab topology you downloaded.

Basic device configuration

We will begin by naming the devices, addressing the interfaces and allowing Telnet to the distribution routers. Note that there is no configuration required for the Switch. In this lab we are solely concerned with routing.

• Configure a meaningful hostname on each router. It is particularly important on the Distribution layer devices because we will use the hostname to determine which router is the active HSRP device later in the exercise.

• Configure the following IP addresses on the devices and remember to use the "no shutdown" command.

CORE ROUTER         IP ADDRESS     SUBNET MASK
Ethernet 0/0    192.168.0.5    255.255.255.252
Ethernet 0/1    192.168.0.9    255.255.255.252
Loopback 0          192.168.0.1    255.255.255.252

DISTRIBUTION_1      IP ADDRESS     SUBNET MASK
Ethernet 0/0    192.168.10.2   255.255.255.0
Ethernet 0/1    192.168.0.6    255.255.255.252

DISTRIBUTION_2      IP ADDRESS     SUBNET MASK
Ethernet 0/0    192.168.10.3   255.255.255.0
Ethernet 0/1    192.168.0.10   255.255.255.252

PC0  IP ADDRESS     SUBNET MASK    GATEWAY
     192.168.10.11  255.255.255.0  192.168.10.2*

PC1  IP ADDRESS     SUBNET MASK    GATEWAY
     192.168.10.12  255.255.255.0  192.168.10.3*

*Notice that each PC is using a different gateway.  This is deliberate.

• On each of the distribution routers add the following commands to allow us to Telnet to them later in the lab.

Router(config)#line vty 0 4
Router(config-line)#password cisco
Router(config-line)#login
Router(config-line)#transport input telnet

Testing OSI layer 1 and 2

• At this point you should be able to ping between directly connected interfaces (within the same subnet). This is a test of the first two layers of the OSI model. You won't be able to ping end-to-end because we don't yet have any routing (layer 3 of the OSI).

Add routing

We will use OSPF routing in this exercise. Advertise all the networks using the following commands.There are less verbose ways of advertising OSPF links than the commands shown here but this technique provides one line per interface which is easy to understand and provides maximum control. The wildcard masks are merely the inverse of the subnet mask. Although this lab is not about OSPF you should take the time to understand why these commands are necessary.

CORE ROUTER
router ospf 1
network 192.168.0.0 0.0.0.3 area 0
network 192.168.0.4 0.0.0.3 area 0
network 192.168.0.8 0.0.0.3 area 0

DISTRIBUTION_1
router ospf 1
network 192.168.0.4 0.0.0.3 area 0
network 192.168.10.0 0.0.0.255 area 0

DISTRIBUTION_2
router ospf 1
network 192.168.0.8 0.0.0.3 area 0
network 192.168.10.0 0.0.0.255 area 0

Testing - Layer 3

At this point you should have end-to-end connectivity.

• Check that devices can ping any IP address. In particular you should be able to ping from the command-line on the PCs to the Loopback interface on the Core Router (192.168.0.1).
  • If you have trouble, start by making sure that you have point-to-point connectivity between directly connected interfaces as required by the previous testing step. Layer 3 is carried by layers 1 and 2 so they need to work first.
  • If you still have trouble, use the command "show ip route" on each router. You should see at least some routes with an "o" next to them indicating that OSPF is exchanging routes.

There is no point in moving forward in this lab if you don't have full connectivity at this point. You need a solid foundation to build on. If you are completing this lab on your own and still have problems you can download the completed EVE file to compare with your own. But please make sure you overcome any hurdles you have with the basics.

Save everything

This would be a good time to save your router and EVE lab states. We will be shutting down routers to simulate failures. Just like real life, if you pull the plug and didn't save the configuration you will need to re-enter it!

• On each router save the configuration to NVRAM (Flash) with:

Router#copy running startup

The next step is crucial...

• As you are emulating the routers in EVE you need to select More Actions -> Export all CFGs. This copies the configuration files from the individual routers into the EVE lab environment. Once this step is completed, it is safe to reboot the routers as their configuration will be restored.
• EVE allows you to choose whether to start the devices using a previously saved configuration or a blank state. You choose this function from the File:Startup-config-button-eve.png button in EVE. Check that the slide button is ON for your Distribution routers. You can also click on the routers name to see what configuration file EVE is storing for that device.

Gateway failure without HSRP

To illustrate the need for first hop redundancy (HSRP) we will look at the effects of a gateway failure with no HSRP.

• On each PC open a command-line window and ping the Core Router loopback (192.168.0.1) continuously with the following command.

ping 192.168.0.1 -t 

It should be reliable and stable.

• Now right-click on Distribution1 and select the "STOP". This simulates a catastrophic failure of the router.

• Observe the pings from the PCs. You should see that PC0 fails because it is configured to use Distribution1 as its gateway. PC1 should not be affected as it is configured to use Distribution2 as a default gateway. Note: You may find that both hosts have their communication disrupted. Wait a minute or so and PC1's communication should be restored. The reason this may occur is that traffic from PC1 travels via Distribution2 but the return path may still be via Distribution1. After a period of time, OSPF reroutes the return traffic. This isn't an issue with the gateway, but rather an OSPF routing issue.

At this point, you should reflect on the different ways you could address the problem faced by PC0 and restore its connectivity. Without intervention, PC0 will not have connectivity. Many of the solutions will not be transparent to the user.

• Turn Distribution1 back on and wait for connectivity to resume. Using physical Cisco routers if you watch the LEDs (orange - blocking) you would notice that Spanning Tree is adding to the delay in restoring connectivity. The use of spanning-tree "portfast" to speed up this process could be considered in real implementation.

Implementing Hot Standby Router Protocol

• Add the following commands to Distribution1 and Distribution2

Distibution1(config)#interface e 0/0
Distibution1(config-if)#standby 1 ip 192.168.10.1
Distibution1(config-if)#standby 1 priority 105
Distibution1(config-if)#standby 1 preempt

Distibution2(config)#interface e 0/0
Distibution2(config-if)#standby 1 ip 192.168.10.1
Distibution2(config-if)#standby 1 preempt

Focus question: Which router will take on the active role and why?

____________________________________________________________________________________________

When you configure the standby commands you will see the HSRP roles in the messages displayed on the command line.

Verifying HSRP operation

• Use the "show standby" command examine the status of HSRP on Distribution1 and Distribution2.

Distibution1#show standby
Ethernet0/0 - Group 1
 State is Active
   12 state changes, last state change 00:47:49
 Virtual IP address is 192.168.10.1
 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.59 secs
 Preemption enabled
 Active router is local
 Standby router is 192.168.10.3, priority 100 (expires in 8 sec)
 Priority 105 (configured 105)
 Group name is hsrp-Et0/0-1 (default)

Distribution2#show standby
Ethernet0/0 - Group 1
 State is Standby
   14 state changes, last state change 00:48:08
 Virtual IP address is 192.168.10.1
 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.342 secs
 Preemption enabled
 Active router is 192.168.10.2, priority 105 (expires in 7 sec)
   MAC address is 0000.0C07.AC01
 Standby router is local
 Priority 100 (default 100)
 Group name is hsrp-Et0/0-1 (default)

Configure hosts for HSRP

In order to make use of the highly available virtual gateway, hosts should use the Virtual router address as their gateway.

• Change the gateway address of the hosts to 192.168.10.1

• Verify that the virtual gateway works by starting a continuous ping from each PC to the loopback (192.168.0.1).

Save everything

Again we will be shutting down routers to simulate failures.

• On each router save the configuration to NVRAM (Flash) with:

Router#copy running startup

The next step is crucial...

• As you are emulating the routers in EVE you need to select More Actions -> Export all CFGs.

Failure of a physical gateway router with HSRP

We will now simulate a variety of failures so that we can observe the operation of HSRP.

• Continue to ping from each PC to the loopback so we can observe any lose of connectivity.
• Turn off the active router, which should be Distribution1, to simulate a failure. Observe the pings from the hosts and the command line messages on the HSRP standby router.

You should see the standby router change to active and there should only be a brief interruption to the packet flow.

The duration of the interruption is longer in EVE than it would be if using real equipment. With real equipment, turning off the router would also remove the electrical connection to the attached links. As a link-state-protocol, OSPF recognises the loss of connectivity and recalculates a new path immediately. Unfortunately EVE does not simulate the electrical properties of the link and OSPF must wait for a number of lost hellos with its neighbour before declaring it lost.

Focus question: How could you reduce the period of disruption?

________________________________________________________________________________

• Restore power to the failed router to simulate its repair and return to service.

Because we configured "pre-empt" it should resume the active HSRP role. Observe the continuous pings from the hosts. It is likely that there will be a brief interruption. For this reason you should give consideration as to whether "preempt" is desirable in your network.

To reinforce the concept of a physical router taking on the role of a virtual router try the following:

• From the Core router, use the command line to Telnet to the virtual router (192.168.10.1). The password will be "cisco" as this is what you configured under "line vty 0 4".

Note the hostname that is displayed. This corresponds to the physical router that is currently actively implementing the HSRP virtual router.

• "exit" the Telnet session on the Core router and then "STOP" the active physical router and the Telnet to the virtual router again.

The hostname should have changed as the standby router is now taking responsibility for the virtual router at 192.168.10.1.

• Restore power to the failed distribution router and exit out of any Telnet sessions.

HSRP, upstream link failure and interface tracking

We will now examine issues that occur when the gateway router experiences connectivity problems rather than a complete failure.

• From the command line on one of the PCs perform a traceroute to see the path that packets take to 192.168.0.1.
• Examine the topology and follow the path packets are taking to the loopback.

[PC0]
VPCS> trace 192.168.0.1
trace to 192.168.0.1, 8 hops max, press Ctrl+C to stop
 1   192.168.10.2   0.595 ms  0.560 ms  0.457 ms
 2   *192.168.0.5   1.050 ms (ICMP type:3, code:3, Destination port unreachable)  *

VPCS> 

You should see they are flowing through Distribution1 as it is currently the active HSRP router.

• Now shutdown e0/1 on Distribution1 to simulate a link failure to the core router.

• Repeat the tracert to 192.168.0.1

[PC0]
VPCS> trace 192.168.0.1
trace to 192.168.0.1, 8 hops max, press Ctrl+C to stop
 1   192.168.10.2   1.451 ms  0.739 ms  0.554 ms
 2   192.168.10.3   0.940 ms  0.799 ms  0.792 ms
 3   *192.168.0.9   1.222 ms (ICMP type:3, code:3, Destination port unreachable)  * 

VPCS> 

• Once again follow the path packets are taking on the topology.

You should find that the packets are taking an inefficient path from Distribution1 to Distribution2 the Core. The problem is that Distribution1 is the HSRP active router. It would be better if Distribution2 took over this role.

Distribution1 remains active because it has the highest HSRP priority and it has a working Ethernet link between itself and Distribution2 which allows hello packets to be exchanged. So as far as HSRP is concerned there has been no failure. HSRP allows for this scenario with the HSRP track command.

• Configure the commands below on Distribution1 and consider carefully the meaning of each command.

This feature makes use of a Cisco technology called "object tracking". The first command track 1 interface Ethernet 0/1 line-protocol creates an object to be tracked and gives it an object ID of "1". The object is defined as the line-protocol on Ethernet 0/1. The line-protocol is "Ethernet". So the status of Ethernet (up or down) is what is being tracked. The final command standby 1 track 1 decrement 15 links HSRP (standby), virtual router 1 with object number 1 (created previously). When the object is triggered, the HSRP priority is decremented by 15. As the priority on Distribution1 is 105, a link failure on Ethernet 0/1 will reduce this by 15 producing an overall priority of 90. As Distribution2 is configured with the default priority (100) it becomes the Active router. This leads to a more efficient traffic flow.

Dist1(config)# track 1 interface Ethernet 0/1 line-protocol
Dist1(config-track)# exit
Dist1(config)# interface Ethernet 0/0
Dist1(config-if)# standby 1 track 1 decrement 15

Final Configurations

These are provided for reference if you get stuck or just want to confirm your configuration.

EVE HSRP Lab completed

Core

hostname Core
!
interface Loopback0
 ip address 192.168.0.1 255.255.255.252
!
interface Ethernet0/0
 ip address 192.168.0.5 255.255.255.252
!
interface Ethernet0/1
 ip address 192.168.0.9 255.255.255.252
!
router ospf 1
 network 192.168.0.0 0.0.0.3 area 0
 network 192.168.0.4 0.0.0.3 area 0
 network 192.168.0.8 0.0.0.3 area 0
!
line con 0
 logging synchronous
line aux 0
line vty 0 4
 login
 transport input none
!
end

Distribution1

hostname Dist1
!
track 1 interface Ethernet0/1 line-protocol
!
interface Ethernet0/0
 ip address 192.168.10.2 255.255.255.0
 standby 1 ip 192.168.10.1
 standby 1 priority 105
 standby 1 preempt
 standby 1 track 1 decrement 15
!
interface Ethernet0/1
 ip address 192.168.0.6 255.255.255.252
!
router ospf 1
 network 192.168.0.4 0.0.0.3 area 0
 network 192.168.10.0 0.0.0.255 area 0
!
line con 0
 logging synchronous
line aux 0
line vty 0 4
 password cisco
 login
 transport input telnet
!         
end

Distribution2

hostname Dist2
!
interface Ethernet0/0
 ip address 192.168.10.3 255.255.255.0
 standby 1 ip 192.168.10.1
 standby 1 preempt
!
interface Ethernet0/1
 ip address 192.168.0.10 255.255.255.252
!
router ospf 1
 network 192.168.0.8 0.0.0.3 area 0
 network 192.168.10.0 0.0.0.255 area 0
!
line con 0
 logging synchronous
line aux 0
line vty 0 4
 password cisco
 login
 transport input telnet
!
end