How to configure gateway redundancy with HSRP in IOS
How to configure gateway redundancy with HSRP in IOS
So you are moving from a small network to a medium network. Now it matters if the path from your clients to your default gateway is down. Or even more crucial, it matters if your clients’ default gateway can get them to external networks (such as the Internet). How can this be done? With a gateway redundancy solution! In this blog I will discuss the configuration of Hot Standby Router Protocol (HSRP). This protocol is Cisco-proprietary, but there is also a flavor for non-Cisco shops – VRRP. Their functionality is virtually the same but feel free to investigate this option if it is better for your situation. Let’s take a look at a couple of diagrams to set the stage:
In Figure 1, the client is configured with a default gateway IP address on Router DG1. This is wonderful unless the link between the client and DG1 fails. There is another way for the Client to reach the external network, but the Client is unaware of this. The network admin will either have to fix the broken link or point the Client at DG2 to correct the situation. Either solution requires interaction and configuration before the Client’s connectivity is restored. A better solution is to configure HSRP, which is a dynamic solution. See Figure 2 below:
Since the link to DG1 is down, HSRP automatically reacts, which means the Client’s data still continue to flow. These diagrams do not include all that is necessary to make HSRP function, they are just to introduce the concept. To go a little bit deeper into HSRP, we can compare it to one of the Rocky movies where Rocky says to Mick, “I see three of them!” Mick replies, “Hit the one in the middle!” Looking again at Figure 2, you can imagine that there is a router in the middle of DG1 and DG2. It is this (virtual) router in the middle that the Client ‘hits’ when sending data to its default gateway. One of the physical routers is the active member of the group, the other assumes a standby role. Between them is a virtual MAC address that is provided to the client which maps to a virtual IP address which is shared between the two routers. If the active member goes down, the standby router takes over the active role of forwarding user data. From the standpoint of the Client, nothing changes. If you examine the ARP table of the Client, it will have the same default gateway IP address and MAC address regardless of which physical router is actually moving packets. So much for introductions – let’s take a look at a network scenario where HSRP has been successfully implemented.
As shown in Figure 3, there are two routers configured as an active-standby group in HSRP. HSRP1 is the active member of the group, and HSRP2 is the standby member. The Client device (which is actually a router filling in the role of a client machine) is configured with a default gateway of 10.1.1.5, which is the virtual IP address of the HSRP pair (the one in the middle). Both HSRP routers are running EIGRP and are neighbors with the edge device of the ISP. Let’s take a look at the relevant configurations of the 2 HSRP routers.
Here is the config on HSRP1:
Here is the config on HSRP2:
You can see that both routers have been told that the virtual IP address is 10.1.1.5. Both are configured to preempt, which means each will assume the active role if the other dies, or if the active router’s priority drops below the priority value of the standby router . HSRP1 has a higher priority (110) than HSRP2 (105) which means that HSRP1 will be the active member if it is up and functioning. I have adjusted the default timers so that they say hello once per second and consider the neighbor dead after 3 seconds. The last piece of the config is that HSRP1 is also tracking something. Recall at the outset I mentioned that it is important to react if the client’s path to the default gateway is severed, but I said it was crucial that the default gateway would verify that it could actually reach remote networks. This ‘track’ statement is what allows HSRP1 to verify that it has outside reachability. If the track result is false, the priority of HSRP1 is decremented by a value of 10 (this is the default setting, which I have not changed). The consequence is that if HSRP1 loses its ability to reach the monitored destination, HSRP2 becomes the active HSRP router. A good way to visualize this is to imagine that you are in a tall burning building. You walk past a door and you see a fireman helping people through an open window. He explains that there are firefighters below catching people safely in a tarp. To track reachability is similar to the fireman looking out the window before he helps each person through to verify that the tarp is still there. Should the firefighters on the ground move to a different location, the fireman at the window will no longer be tossing people out that window. You can still reach this fireman without a problem, but the final destination is no longer through him.
Let’s see this happen in our network scenario. First, let’s verify that the Client can reach the target destination of 184.108.40.206:
Let’s see the default gateway:
Now for the ARP info:
There is some hidden information in the discovered MAC address. The virtual MAC address used by HSRP (v1) starts with 0000.0c07.acxx. The xx is our example is 64. Since MAC addresses are in hexadecimal format, this translates to the number 100 in decimal. Sounds familiar, doesn’t it? That is the group number that was configured on HSRP1 and HSRP2 (standby 100 shown above).
Now let’s examine the current path taken to get from the Client to the target IP address of 220.127.116.11:
Even though the virtual IP address is 10.1.1.5, the physical path through the network flows from the Client to HSRP1 (through the switch, of course) and on to the ISP edge device. The target IP address is actually a loopback interface on the ISP router. I will start by sending 15000 pings from the Client to 18.104.22.168 so we can see what happens to the traffic as the network has an outage. To simulate the outage, I will shutdown interface f0/0 on the ISP router and watch as HSRP does its thing and dynamically allows the Client’s traffic to continue to reach the 22.214.171.124 address:
I did the following on the Client: debug ip icmp
In this way I could monitor the length of time it took for my network to reconverge. I have configured NTP so that all my devices precisely agree on the time. Here is a screenshot of when the continuous ping first died:
As you can see, the last successful ping occurred at 11:28:27.843. Here is a screenshot showing when pings began succeeding once more:
So pings resumed at 11:28:38.783. So my network was down for a total of 10.940 seconds. During this time HSRP (and EIGRP) was reconverging! Of course this is not an enterprise-sized network, so your results may vary slightly. You can tune your HSRP timers and your EIGRP hello and hold timers to be even more aggressive, but keep in mind that to achieve faster convergence during topology changes, you must sacrifice additional CPU cycles to do it. Network admins must always walk this fine balancing act between CPU cycles and convergence times, which is typically mandated by the needs of the company which is using the network.
Once again, this is not an exhaustive coverage of the HSRP topic, but I hope it serves to introduce to you this very cool feature which provides dynamic redundancy in modern enterprise networks.
You May Also Like
In this video, you will gain an understanding of Agile and Scrum Master Certification terminologies and concepts to help you make better decisions in your Project Management capabilities. Whether you’re a developer looking to obtain an Agile or Scrum Master Certification, or you’re a Project Manager/Product Owner who is attempting to get your product or … Continue reading Agile Methodology in Project Management
In this Office 365 training video, instructor Spike Xavier demonstrates how to create users and manage passwords in Office 365. For instructor-led Office 365 training classes, see our course schedulle: Spike Xavier SharePoint Instructor – Interface Technical Training Phoenix, AZ 20347: Enabling and Managing Office 365
How does an investigator hunt down and identify unknown malware? In this recording of our IT Security training webinar on April 21, 2015, Security expert Mike Danseglio (CISSP / CEH) performed several malware investigations on infected computers and identify symptoms, find root cause, and follow the leads to determine what’s happening. He demonstrated his preferred … Continue reading Detailed Forensic Investigation of Malware Infections – April 21, 2015