Like This Blog 0

Added by Mark Jacob February 12, 2016

In a previous blog I configured and HSRP pair using an entirely IPv6-oriented topology. I demonstrated the lightning quick failover that can be achieved with carefully crafted timers. However, a careful reader might have noticed that I didn’t consider the path BACK to my source of origin in my topology. So let’s address that today.

Figure 1 shows the topology I will be using for this blog:

Figure 1-Blog topology

 You will note that the topology here is identical to the previous blog. In fact, I would recommend that you read that blog to get a solid foundation for what will follow today.

Picking up directly at the conclusion of the HSRP IPv6 blog, I am now concerned with how the return traffic will reach my PING-initiating client, coincidentally named Client. Even though I am using IOS 15.3, the simple option to add the ‘track’ keyword at the end of an IPv6 route statement is not available. My next best option was to use the Embedded Event Manager to accomplish a path change in the event of a route failure. Now I am not the creator of this type of solution, as I was able to locate several other references on the web that use similar logic. I just wanted to apply it specifically to my situation and share with you what I did. The router of focus here is the Gateway router, as it is the deciding factor in how return traffic reaches the Client machine. I began by configuring two default IPv6 routes from Gateway – one to HSRP1 and one to HSRP2. Since I have configured the network to ensure that HSRP1 is the active router in the HSRP pair, my static route from Gateway to HSRP2 is just a ‘spare’ route in case of failure of the main path. For this reason, and using an option that IS available, I assigned an Administrative Distance of 254 to this backup route. The relevant config for those two routes is shown in figure 2:

Figure 2-default routes

I left my primary route in the default state – I did not modify its Administrative Distance as all I really care about is that it looks better than the backup route. Now for the fun part. I want the Gateway router to fail over to the secondary default route if connectivity is lost on the primary. First, I need something to track. IP SLA is still a good solution here, and it is supported in this IOS using IPv6. Figure 3 displays the relevant IP SLA config on Gateway:

Figure 3-IP SLA config

Now I can create an EEM entry because I have a something to track. Figure 4 shows the EEM piece (Note: Not on the ICND exam.):

Figure 4-EEM with IPv6

With this configuration in place, I will once again test an extended PING from the Client to the loopback IPv6 address on ISP. Let take note of the console messages as they appear as the network recovers from the simulated failure. The first thing I did was to kill g0/0 on HSRP1. Figure 5 shows HSRP1 reacting and relinquishing the active HSRP role:

Figure 5-HSRP failover activity after simulated failure

Now let’s view the console messages that appeared on Gateway when it reacted to the failure, shown in figure 6:

Figure 6-EEM console messages after simulated failure

We also care for how long Client was unable to reach its destination. Figure 7 shows a few pings being dropped:

Figure 7-Client loses a few pings during convergence event

What about when connectivity is restored? Let’s see the console messages when Gateway realizes its primary default route can be reinstalled, shown in figure 8:

Figure 8-Gateway’s default reinstalled by EEM

I generated the above output by re-enabling the g0/0 interface on HSRP1. This meant that HSRP1 once again became the active HSRP router and Gateway’s EEM configuration installed the primary default route back into the routing table. The secondary route faded to insignificance once more, as its AD is set to 254.  While this solution is not nearly as simply adding the ‘track’ keyword to the ipv6 route command, it does serve its function, which is to provide a working return path in the case of HSRP failover.

If you have any comments or questions, please feel free to post them….
Until next time.

Mark Jacob
Cisco and CompTIA Network + Instructor – Interface Technical Training
Phoenix, AZ