You want to configure HSRP on a Token Ring network.
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 (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)#end Router1#
The second router is similarly configured:
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)#end Router2#
As we discussed in Chapter 15, 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 make use of a Routing Information Field (RIF) that contains MAC address information.
This is particularly important when the two HSRP routers reside on different physical rings connected by a bridge. 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 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 use this feature only 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 usable HSRP groups because there are only three distinct MAC addresses. With this option, however, 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 non-Token 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. We also recommend using the Burned-In Address in these types of environments.
You should be aware of two important limitations to this command. First, and most important, 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 update its ARP cache only 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. Therefore, 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.
Recipe 22.1, Recipe 22.2; Chapter 15
 |
|
|
| Top |