Using HSRP on Token Ring
Problem
You want to configure HSRP on a Token Ring.
Solution
You can use HSRP on a Token Ring LAN exactly the same as in Recipe 22.1 if the only protocol on the segment is IP. However, if you have any other protocols, and particularly if the ring uses any source-route bridging, you must use a slightly different configuration:
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#interface Tokenring0
Router1(config-if)#ip address 172.22.1.3
Router1(config-if)#standby ip 172.22.1.1
Router1(config-if)#standby use-bia
Router1(config-if)#standby priority 120
Router1(config-if)#standby preempt
Router1(config-if)#exit
Router1(config)#end
Router1#
The second router is configured similarly:
Router2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router2(config)#interface Tokenring0
Router2(config-if)#ip address 172.22.1.2
Router2(config-if)#standby ip 172.22.1.1
Router2(config-if)#standby use-bia
Router2(config-if)#standby priority 110
Router2(config-if)#standby preempt
Router2(config-if)#exit
Router2(config)#end
Router2#
Discussion
The biggest functional difference between a Token Ring LAN and an Ethernet LAN is that Token Ring bridging is usually source-routed, while Ethernet almost always uses transparent bridging. Consequently, Token Ring devices use a Routing Information Field (RIF), which contains MAC address information.
This is particularly important when the two HSRP routers reside on different physical rings connected by a bridge, as in a switched Token Ring environment, for example. In this case, when HSRP changes the active router, the bridges will see the virtual MAC address suddenly jump from one ring to another, which will disrupt the RIF tables in every bridge.
So, when using HSRP in Token Ring environments, it is usually best to just use the router's burned-in address (BIA) instead of a virtual MAC address. Then HSRP will rely on gratuitous ARP packets to update the ARP cache of every device on the ring, and tell it that the default gateway router has changed.
The key command in this configuration is the use-bia command, which appears on both routers:
Router1(config-if)#standby use-bia
In this case, we are using standby group 0 because we didn't specify a group number, so the virtual MAC address would have been C0-00-00-01-00-00 if we had not changed it to the BIA. The output of a show standby command shows the address that the router is actually using:
Router1#show standby
TokenRing0 - Group 0
Local state is Active, priority 120, may preempt, use bia
Hellotime 3 holdtime 10
Next hello sent in 00:00:02.338
Hot standby IP address is 172.22.1.1 configured
Active router is local
Standby router is 172.22.1.3 expires in 00:00:09
Standby virtual mac address is 0000.300f.2186
Router1#
We chose to use standby group 0 in this example because, prior to IOS level 12.0(3.4)T, you could only use this feature with group 0. In newer IOS levels, however, this feature is available for all Token Ring HSRP groups. Without this option, there are only three HSRP groups available. With it, you can configure up to 255 groups, all of which will use the same BIA MAC address.
The use-bia option can also be useful in nonToken-Ring environments. Networks that use DECnet or Xerox Network Services (XNS) frequently encounter MAC address problems as well, even on Ethernet LANs. This is because devices that run both protocols will see two different MAC addresses for the same destination device, which causes confusion. So in these types of environments, we recommend using the burned-in address as well.
You should be aware of two important limitations to this command. First, and most importantly, when you use this option, HSRP must rely on gratuitous ARP to tell end devices that the MAC address of the default gateway has changed. However, some devices do not handle gratuitous ARP packets well. In some implementations, a device will only update its ARP cache if it receives an ARP packet in response to a specific ARP request.
The second limitation is that this option completely breaks Proxy ARP. This is because the end devices believe that the remote IP address is associated with the MAC address of the primary HSRP router. However, the backup router has no way of knowing which remote IP addresses the primary router has sent out Proxy ARP messages for. So it can't update these entries to tell the end devices to use the new MAC address instead.
We know of no workarounds for either of these problems. So please use caution when implementing this feature.