实施 HSRP Over LANE

下载选项

  • PDF     (344.2 KB)
    在各种设备上使用 Adobe Reader 查看
  • ePub     (101.3 KB)
    在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上使用各种应用查看
  • Mobi (Kindle)     (154.6 KB)
    在 Kindle 设备上查看或在多个设备上使用 Kindle 应用查看
已更新: 2005 年 6 月 5 日
文档 ID:10446

非歧视性语言

此产品的文档集力求使用非歧视性语言。在本文档集中，非歧视性语言是指不隐含针对年龄、残障、性别、种族身份、族群身份、性取向、社会经济地位和交叉性的歧视的语言。由于产品软件的用户界面中使用的硬编码语言、基于 RFP 文档使用的语言或引用的第三方产品使用的语言，文档中可能无法确保完全使用非歧视性语言。 深入了解思科如何使用包容性语言。

关于此翻译

思科采用人工翻译与机器翻译相结合的方式将此文档翻译成不同语言，希望全球的用户都能通过各自的语言得到支持性的内容。 请注意：即使是最好的机器翻译，其准确度也不及专业翻译人员的水平。 Cisco Systems, Inc. 对于翻译的准确性不承担任何责任，并建议您总是参考英文原始文档（已提供链接）。

简介

本文档旨在概述在LAN仿真(LANE)环境中实施热备份路由器协议(HSRP)时可能遇到的问题。它描述了LANE上HSRP的许多细节，并提供了各种场景的故障排除提示。

先决条件

要求

本文档没有任何特定的要求。

使用的组件

本文档不限于特定的软件和硬件版本。

规则

有关文档规则的详细信息，请参阅 Cisco 技术提示规则。

背景信息

总之，HSRP的目的是允许子网中的主机使用单个“虚拟”路由器作为默认网关 — 多台路由器参与HSRP协议，以便选举活动路由器，该活动路由器在活动路由器发生故障时承担默认网关和备用路由器的角色。结果是，即使物理第一跳路由器发生更改，默认网关也始终显示为up。RFC 2281中提供了HSRP的完整说明 leavingcisco.com。

HSRP设计用于支持多路访问、组播或广播的LAN（通常是以太网、令牌环或光纤分布式数据接口[FDDI]）。 因此，HSRP在ATM LANE上应能正常工作。

可能会出现多种涉及HSRP和LANE交互的情况：

  1. 自Cisco IOS®软件版本11.2起，HSRP可以通过LANE“本地”运行。在这种情况下，直接在LAN仿真客户端(LEC)所在的ATM子接口上配置standby命令。请参阅下图。

    hsrp1.gif

  2. 还有一个实例，在LAN接口上配置了HSRP，但子网的一部分覆盖LANE云。这由带ATM接口的LAN交换机（例如带LANE模块的Cisco Catalyst 5000）的中间层完成。 请参阅下图。

    hsrp2.gif

  3. 最后，出现一种“混合”情况，即某些HSRP路由器通过LANE连接，而其他路由器则位于LAN交换机后面的LAN中。

    hsrp3.gif

案例分析

1)LANE上的本地HSRP

参与HSRP的路由器通过广播介质发送“hello”数据包，以便了解彼此并选举活动和备用路由器。这些数据包发送到组播地址224.0.0.2，生存时间(TTL)为1，组播目标MAC地址为0100 5E00 0002。

LANE在此不引入新问题，因此RFC 2281 leavingcisco.com 中描述的详细信息仍然适用 — 通过交换hello、coup和resign数据包，选择活动和备用路由器。

hello数据包通过广播和未知服务器(BUS)发送，以下是debug atm packet（在组播转发虚电路[VC]上）和debug standby将显示的：

Medina#show run
[snip]interface ATM3/0.1 multipoint
 ip address 1.1.1.3 255.255.255.0 
 no ip redirects 
 no ip directed-broadcast
 lane client ethernet HSRP
 standby 1 ip 1.1.1.1
[snip]
Medina#show lane client
LE Client ATM3/0.1  ELAN name: HSRP  Admin:
up  State: operational
Client ID: 2                
LEC up for 14 minutes 34 seconds
ELAN ID: 0
Join Attempt: 7
Last Fail Reason: Config VC being released
HW Address: 0050.a219.5c54   Type: ethernet            
Max Frame Size: 1516
ATM Address: 47.00918100000000604799FD01.0050A2195C54.01
VCD  rxFrames  txFrames  Type      ATM Address
  0        0         0  configure  47.00918100000000604799FD01.00604799FD05.00
 12        1         3  direct     47.00918100000000604799FD01.00604799FD03.01
 13        2         0  distribute 47.00918100000000604799FD01.00604799FD03.01
 14        0       439  send       47.00918100000000604799FD01.00604799FD04.01
 15       453        0  forward    47.00918100000000604799FD01.00604799FD04.01
Medina#show atm vc 15
ATM3/0.1: VCD: 15, VPI: 0, VCI: 40
UBR, PeakRate: 149760
LANE-LEC, etype:0xE, Flags: 0x16C7, VCmode: 0x0
OAM frequency: 0 second(s)
InARP DISABLED
Transmit priority 4
InPkts: 601, OutPkts: 0, InBytes: 48212, OutBytes: 0
InPRoc: 0, OutPRoc: 0, Broadcasts: 0
InFast: 0, OutFast: 0, InAS: 0, OutAS: 0
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0
OAM cells received: 0
OAM cells sent: 0
Status: UP
TTL: 0
interface =  ATM3/0.1, call remotely initiated,
call reference = 8388610
vcnum = 15, vpi = 0, vci = 46, state = Active(U10)
 , multipoint call
Retry count: Current = 0
timer currently inactive, timer value = 00:00:00
Root Atm Nsap address: 47.00918100000000604799FD01.00604799FD04.01
, VC owner: ATM_OWNER_UNKNOWN

重要的是查看LAN仿真客户端(LEC)通过总线接收的内容（例如，通过组播转发）：

Medina#debug atm packet 
interface atm 3/0.1 vcd 15
ATM packets debugging is on
Displaying packets on interface ATM3/0.2 VPI 0, VCI 46 only
Medina#debug standby
Hot standby protocol debugging is on
*Feb 18 06:36:05.443: SB1:ATM3/0.1 Hello in 1.1.1.2
Active pri 110 hel 3 hol 10 ip 1.1.1.1
*Feb 18 06:36:08.007: SB1:ATM3/0.1 Hello out 1.1.1.3
Standby pri 100 hel 3 hol 10 ip 1.1.1.1
*Feb 18 06:36:08.439: ATM3/0.1(I):
VCD:0xF VPI:0x0 VCI:0x40 Type:0xE, LANE, ETYPE:0x000E
LECID:0x0004 Length:0x4A
*Feb 18 06:36:08.439: 0004 0100 5E00 0002 0000 0C07
AC01 0800 45C0 0030 0000 0000 0111 D6F8 0101
*Feb 18 06:36:08.443: 0102 E000 0002 07C1 07C1 001C
AAEE 0000 1003 0A6E 0100 6369 7363 6F00 0000
*Feb 18 06:36:08.443: 0101 0101 0001 0001 000C

此十六进制转储转换为以下内容：

VCD:0xF VPI:0x0 VCI:0x28: VCD number 15, VPI=0 and VCI=400
004: LECID from the sender of the packet
0100 5E00 0002: Destination MAC address for HSRP hellos
0000 0C07 AC01: Virtual MAC address of HSRP (the last octet is actually the standby group number)
0800: Type = IP
45C0 0030 0000 0000 0111 D6F8: IP header - UDP packet
0101 0102: Source IP = 1.1.1.2
E000 0002: Destination IP = 224.0.0.2
07C1 07C1 001C AAEE: UDP header - Source & Destination ports = 1985
00: HSRP version 0
00: Hello packet (type 0)
10: State (of the sender) is Active (16)
03: Hellotime (3 sec)
0A: Holdtime (10 sec)
6E: Priority = 110
01: Group
00: Reserved
6369 7363 6F00 0000: Authentication Data
0101 0101: Virtual IP address = 1.1.1.1

值得注意的是，hello数据包是由具有虚拟MAC地址(VMAC)作为源MAC地址的活动路由器发出的 — 这是理想的，因为转发这些数据包的学习网桥（交换机）将使用VMAC的适当位置更新其内容可寻址存储器(CAM)表。

HSRP的密钥在IP地址和MAC地址之间的映射中。

在最简单的表达式中，虚拟IP地址永久绑定到虚拟MAC地址，唯一需要担心的是交换机始终知道此虚拟MAC地址的位置。这是确保的，因为hello由VMAC发出。

Medina#show standby
ATM3/0.1 - Group 1
  Local state is Standby, priority 100
  Hellotime 3 holdtime 10
  Next hello sent in 00:00:00.006
  Hot standby IP address is 1.1.1.1 configured
  Active router is 1.1.1.2 expires in 00:00:08
  Standby router is local
  Standby virtual mac address is 0000.0c07.ac01

另一个选项是路由器使用其固化(备用 — bia)地址映射到虚拟IP地址。在这种情况下，虚拟IP和MAC地址之间的映射会随着时间而改变 — 新活动路由器发出地址解析协议(ARP)以通告新的虚拟IP到MAC地址映射。ARP只是未经请求的ARP响应。-

注意：某些（较旧）IP堆栈可能不理解ARP。

Medina#show standby
ATM3/0.1 - Group 1
  Local state is Standby, priority 100, use bia
  Hellotime 3 holdtime 10
  Next hello sent in 00:00:02.130
  Hot standby IP address is 1.1.1.1 configured
  Active router is 1.1.1.2 expires in 00:00:09
  Standby router is local
  Standby virtual mac address is 0050.a219.5c54

注意：要介绍LANE，关键是在虚拟IP到MAC地址映射之上，必须对VMAC到网络服务接入点(NSAP)地址映射进行记帐。此映射只需通过LAN仿真地址解析协议(LE-ARP)过程解析即可：希望将流量发送到活动网关的LEC将使用LE-ARP作为VMAC(或物理MAC（如果使用固化MAC地址[BIA]）。

现在，考虑当新路由器变为活动状态时会发生什么情况：为了向LEC通知活动网关的新位置（新的VMAC到NSAP映射），必须修改LE-ARP表。默认情况下，LE-ARP条目每五分钟超时一次，但在大多数情况下，依赖此超时是不可接受的 — 收敛必须更快。该解决方案取决于采用新活动状态的LEC是运行LANE第1版还是第2版(有关LANE规格，请参阅 leavingcisco.com ATM Forum.com):

  • LANE第1版

    当路由器变为活动状态时，除了RFC 2281中描述的步骤外 leavingcisco.com，它还会发送LE-NARP，以使新的VMAC到NSAP地址绑定已知。根据LANE规范，当接收到LE-NARP时，LEC可以选择清除或更新与MAC地址对应的LE-ARP条目。思科内部的趋势是采用更保守的方法并选择清除LE-ARP条目 — 这将导致LEC立即重新生成LE-ARP，而无需等待五分钟超时。

    注意：此解决方案可能导致以下描述的兼容性问题。

  • LANE第2版

    在LANE第2版中，LANE第1版的某些缺点得到缓解：LE-NARP已被无目标LE-ARP和无源LE-NARP取代。无目标LE-ARP可被视为通告新绑定的工具，而无源LE-NARP的目的是使现有的MAC到NSAP地址绑定过时。实施方式是，如果路由器从Standby（备用）更改为Active（主用），它会发出无目标LE-ARP（用于通告MAC到NSAP的映射），如果从Active（主用）更改为Standby（备用），它会发出无源LE-NARP（用于使MAC到NSAP绑定过时）。

问题 — 互操作性

问题经常出现，值得进行更深入的检查。LANE第1版规范规定，LE-NARP必须指定“旧绑定”，该绑定通过指定（旧）目标NSAP(T-NSAP)地址而已过时。通常，参与HSRP的路由器不会维护彼此之间的数据定向。

因此，新活动路由器不知道此信息，它将选择不填写此字段，因为它不知道更好。这是对规范的轻微违规，如果T-NSAP地址字段全为零，某些供应商将忽略这些数据包。遗憾的是，没有解决方法 — 如果忽略LE-NARP，请依靠LE-ARP超时（通常为五分钟）来获取正确的绑定。

当LE-ARP或LE-NARP发送时，T-NSAP地址字段全为零，称为“无目标”。 如上所述，随着LANE第2版（和ATM多协议[MPOA]）的出现，这已成为标准，问题已不复存在。

在LANE第1版中，如果出现问题，将执行以下操作：

  • 如果路由器知道“旧绑定”，则最好遵循规范。这些调试现在在控制分发VC上进行：

    ATM0/0.1(I):
VCD:0xD Type:0x6, LANE, ETYPE:0x0006 LECID:0xFF00 Length:0x70
FF00 0101 0008 0000 0000 0018 0003 0000 0000 0000 0000 0000 0001 0000 0C07
AC01 4700 9181 0000 0000 101F 2D68 0100 50A2 195C 5401 0000 0000 4700 9181
0000 0000 101F 2D68 0100 102F FBA4 0101 0000 0000 0000 0000 0000 0000 0000
FF00: Marker = Control Frame
0101: ATM LANE version 10
008: Op-code = LE_NARP_REQUEST
0000: Status
0000 0018: Transaction ID0003: Requester LECID0000: Flags
0000 0000 0000 0000: Source LAN destination 
(not used for an LE-NARP)
0001 0000 0C07 AC01: Target LAN destination
(the 0001 indicates a MAC address as opposed to a route descriptor)
4700 9181 0000 0000 101F 2D68 0100 50A2 195C 5401: Source NSAP address
(new NSAP address to be bound)
0000 0000: Reserved
4700 9181 0000 0000 101F 2D68 0100 102F FBA4 0101: Target NSAP address
(old NSAP address to be rendered obsolete)

  • 如果它不知道“旧约束”，它会尽其所能，至少会宣传新约束：

    ATM0/0.1(I):
VCD:0xD Type:0x6, LANE, ETYPE:0x0006 LECID:0xFF00 Length:0x70
FF00 0101 0008 0000 0000 0014 0003 0000 0000 0000 0000 0000 0001 0000 0C07
AC01 4700 9181 0000 0000 101F 2D68 0100 50A2 195C 5401 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

    注意：这次T-NSAP地址为空。

同样，使用LANE第2版客户端时，行为完全在规范范围内。

注意：支持MPOA的软件也支持LANE第2版。

故障排除提示

LANE上的本地HSRP不应产生太多问题，而不是由于LE-NARP没有T-NSAP而导致的潜在互操作性问题。

如果路由器在确定它们是活动还是备用时遇到困难，请使用debug standby命令查看两端是否都看到问询。否则，总线可能无法正确转发数据包。

2)LANE后路由器上的HSRP

如图2所示，当HSRP在LANE云后的路由器的LANE接口上配置时，情况会变得更加复杂。

注意：此图从逻辑上描述了路由器未连接ATM的事实。它不必位于与LAN交换机分离的设备中（Cisco Catalyst 5000中的路由交换模块[RSM]属于本例）。

同样，由于LANE强加的MAC地址到NSAP地址映射，因此出现了困难。如上所述，当VMAC切换到与另一个NSAP地址对应的设备（当新路由器变为活动状态）时，必须通知连接到LANE云的所有设备。通过使用LE-NARP（或无目标LE-ARP），在LANE环境的本地HSRP中非常容易实施。

第二种情况的问题是LEC不知道任何第3层信息(IP)，它们仅用于在两种不同介质（LAN和ATM）之间桥接数据包。

例如，在图2中，如果路由器2突然变为活动状态，则LAN交换机2最好将新的VMAC到NSAP映射告知连接到ATM(LANE)云的所有设备。LAN交换机2中的LEC据说是代理其后的所有MAC地址。LANE中的设备如果希望将流量发送到这些MAC地址，必须通过向此LEC直接进行数据设置。从直观上讲，人们可能认为这不会是一个大问题，因为一旦路由器2处于活动状态，它就会开始使用VMAC作为源MAC地址来源发送hello消息。然后，所有LAN交换机都会获知此信息，所有信息都会快速收敛。在非LANE环境中是如此，但LANE特殊的原因如下：

在LANE中，数据包通常可以通过两条路径传输：

  • 如果此数据包是单播，且目的地已映射到已知NSAP，并且数据直接已建立，则数据直接。

  • 未知单播和组播的BUS。

因此，同一MAC地址将源自LAN交换机通过两条不同路径接收的数据包。组播和未知单播将通过BUS到达，而已知单播通过数据定向到达。如果没有做出特定的努力，LAN交换机会根据收到的最后一个数据包，通过数据直接或总线继续学习此MAC地址。这是不可取的，因为BUS应仅用于为未知单播或组播发送数据包。在此阶段，BUS不会学习任何内容，但实际上，请选择执行以下操作：

Packets received over the BUS are marked with the Conditional Learn (CL) 
bit set to 1(this bit is in a control overhead specific to Cisco LAN switches). The LAN switch 
will only update its CAM table with this entry if it does not already have an entry for this 
MAC address (in this VLAN). The idea is that if a switch receives a packet from a source 
that it does not know about, at least it will now know that it is located somewhere across 
the LANE cloud. Future packets for that MAC address will be forwarded to the BUS only as 
opposed to being flooded in the entire VLAN.

要返回本示例，可以放心地假设此ELAN中的所有LEC在路由器2激活之前已经知道路由器1的VMAC-NSAP映射。所有LAN交换机也知道VMAC位于LAN交换机1后面。当路由器2变为活动状态并发送hello数据包时，这些数据包将通过总线转发到LANE云。因此，所有LAN交换机都不会使用此新信息更新其CAM表，发送到此VMAC的所有数据包将被错误定向，直到LAN交换机“忘记”此条目（默认老化时间为5分钟）。

注意：由于LEC上的LE-ARP老化计时器默认也为五分钟，因此整体连接实际上可能会丢失10分钟。减少MAC地址的老化计时器会有所帮助，但实际上无法解决问题。

有两种解决方案：

  1. 如果LAN交换机不是Cisco，请恢复到上述方法：使用烧录地址。如果路由器仅使用其MAC地址来源发送hello数据包，并且每当发生交换时虚拟IP地址会更改映射，则不会混淆这些MAC地址的位置。

  2. 如果LAN交换机是Cisco Catalyst，则由于Cisco Bug ID CSCdj58719（仅限注册客户）和CSCdj60431中所涵盖的分布式缺陷跟踪系统(DDTS)所提供的修改，请继续使用VMAC(仅注册客户)。

    实际上，当路由器处于活动状态时，除了根据RFC 2281 leavingcisco.com发送的ARP（未经请求的ARP响应）外，路由器还发送了第二个ARP，目的MAC地址为0100.0CCD.CDCDD。当Cisco Catalyst收到此数据包时，它会执行以下两项操作：

    • 它会清除它为VMAC拥有的LE-ARP条目。

    • 它通过总线学习VMAC。

因此，各个LEC中不再有过时的LE-ARP条目，VMAC的新位置将传播到所有交换机（例如，LANE云之外）。 要使此功能正常工作，必须满足以下最低软件要求：

  • 路由器必须至少具有Cisco IOS软件版本11.1(24)、版本11.2(13)或所有版本12.0。

  • LANE模块必须至少具有3.2(8)版。可接受11.3W4及更高版本。

思科建议使用最新软件。

3)混合环境

在混合环境中可能会出现最后一个问题。采用上述场景并添加直连LANE终端设备（路由器或工作站）时，需要像场景1一样通知终端设备活动网关的位置更改。如果新活动路由器连接在交换机后面，则唯一的解决方案是交换机自己代表路由器发送LE-NARP，这正是要做的。

除上述步骤外，如果Cisco Catalyst拾取发往0100 0CCD的数据包，它会发送LE-NARP（如果运行LANE版本2，则无源LE-NARP），其唯一目的是清除VMAC的LE-ARP缓存。

结论

如图所示，LANE上的HSRP在原理上运行良好，但在某些情况下，如果用户落入上述漏洞之一，可能会短时间失去连接。

重要信息！:为确保在LANE上使用HSRP成功，请至少遵循以下两条建议：

  • 为安全起见，请至少升级到Cisco IOS软件版本12.0的最新版本。

  • 在多供应商环境中，最好使用LANE第2版或固化地址以避免问题。

相关信息

修订历史记录

版本 发布日期 备注
1.0
05-Jun-2005
初始版本

此文档是否有帮助?

Feedback反馈

联系我们

本文档适用于以下产品