查看:1246|回复：3
cisco 3560三层交换机g0/1端口mac： a40c.c371.7581
g0/2端口mac：a40c.c371.7582
f0/1 至 f0/24端口mac：a40c.c371.7583 至 a40c.c371.759a
那么在mac地址表里经常出现的a40c.c371.75ff代表什么的地址呢？
这个交换机的真实地址？有什么命令查看？
是不是和stp有关
引用:原帖由 谷雨记 于
15:15 发表
是不是和stp有关 交换机本身而不是端口的mac地址怎么看？
明白了，ff那个是svi地址。我搜索了一下，网上说所有vlan的svi接口应该都有同一个mac地址才对。我在交换机里看了下，为什么有的vlan svi mac相同有的有不同呢？糊涂了。。。
sw3560_core#sh int vl86
Vlan86 is up, line protocol is up
&&Hardware is EtherSVI, address is a40c.c371.75ff (bia a40c.c371.75ff)
&&Internet address is 192.168.2.89/29
sw3560_core#sh int vl3&&
Vlan3 is up, line protocol is up
&&Hardware is EtherSVI, address is a40c.c371.75c2 (bia a40c.c371.75c2)
&&Internet address is 192.168.1.3/29
sw3560_core#sh int vl256
Vlan256 is up, line protocol is up
&&Hardware is EtherSVI, address is a40c.c371.75ff (bia a40c.c371.75ff)
&&Internet address is 10.12.6.1/24查看: 3439|回复: 14
mac地址表老化
在线时间 小时
阅读权限150
&成长值: 18480
在stp生成树中，如果拓扑发生了变化，根网桥会发出TCN，那么网桥就会把自己的mac地址表老化。
这里的老化是什么意思了？
是删除自己的mac地址表吗？如果是删除，为什么直接说删除，要说老化了。
后来我百度了一下，老化时间是300s，如果真是300s，那拓扑早就收敛完了，难道这里有另外一个老化时间？
谢谢，帮忙解答一下。
在线时间 小时
阅读权限91
收到TCN后 就会把原先300s的老化时间改为15s，就是指这个意思
在线时间 小时
阅读权限80
在线时间 小时
阅读权限20
不是另一个老化时间，而是一种需要，当根桥接收到这个TCN BPDU时，根桥意思到自己是网络的根，并通过这个BPDU知道网络拓扑发生变化，于是自已在TCN BPDU中设置一个被置位了的BPDU。这个BPDU表明，将网络的老化MAC地址表速度老化（清除交换机的MAC地址和端口的对应关系），这个时间值就等于1个转发延时20S再加上15S的老化时间。以迅速清除网络中老化的MAC地址表。
在线时间 小时
阅读权限80
在线时间 小时
阅读权限50
在线时间 小时
阅读权限150
&成长值: 18480
ciscohuawei 发表于
不是另一个老化时间，而是一种需要，当根桥接收到这个TCN BPDU时，根桥意思到自己是网络的根，并通过这个BP ...
兄弟，按你的意思是在35s内，就把mac地址表清除了，是吧？
在线时间 小时
阅读权限40
在线时间 小时
阅读权限150
&成长值: 18480
一旦根网桥得知网络中发生了拓扑更改，它会开始发送设置了拓扑更改 (TC) 位的配置 BPDU。设置了该位的 BPDU 传播到网络中的每台交换机。最后，所有交换机都意识到拓扑更改，然后将自己的MAC地址表老化时间由默认的300秒缩短为转发延迟时间15秒。
4）这样将导致获悉MAC地址比正常时更快被刷新，从而删除由于拓扑变化导致的MAC地址表污染。然而，在这段时间内，正在通信的任何工作站都将位于MAC地址表中，根网桥设置 TC 位的持续时间是最大老化时间加上转发延迟秒数，默认情况下为 20+15=35 秒。
在线时间 小时
阅读权限20
本帖最后由 ciscohuawei 于
16:08 编辑
根桥在通过更改自己的配置BPDU，根交换机来指明正发生拓扑变更的情况。根交换机在配置BPDU中设置一段时间的拓扑变更，这段时间就等于转发延迟和最大寿命计时器的总和。
而其它指定交换机在从根交换机接收TC配置BPDU消息的时候，它将使用转发延迟计时器来更新其地址表中的条目。这比平时300秒的默认值更快的时间来进行更新。这能够确保因为拓扑结构变化而不再能够到达的站点将更快地被更新掉。交换机将继续这种过程直到不再从根交换机接收TC BPDU消息为止。
在线时间 小时
阅读权限20
不是35S就把MAC地址表清除了，是15S内。35是用于设置一段时间的拓扑变更所用（包括15S的CAM表寿命老化时间）
在线时间 小时
阅读权限20
发现楼主在抛砖引玉哟，呵呵。
相信还会有高手出来有更精辟的分析，呵呵{:soso_e121:}
在线时间 小时
阅读权限150
&成长值: 18480
ciscohuawei 发表于
发现楼主在抛砖引玉哟，呵呵。
相信还会有高手出来有更精辟的分析，呵呵
我也是后来才找到的资料，
在线时间 小时
阅读权限20
嗯，大家共同努力！{:soso_e185:}
在线时间 小时
阅读权限150
&成长值: 18480
ciscohuawei 发表于
嗯，大家共同努力！
兄弟，NP过没
Powered by地址转发表
address forwarding table
一种新的异构网络链路层拓扑发现算法 - 豆丁网
路层拓扑发现的任务是确定交换域中节点的连接关 系。链路层中的主要设备是交换机，每台交换机都维护一张 地址转发表(Address Forwarding Table, AFT)。地址转发表的 记录格式可以简单地表示为信息对，其中，port 称为转发端口；MAC 称为转发地址。
基于5个网页-
Address Forward Table
拓扑发现 网络流量 随机过程 线性相关
【页码】：-
【出版年】：2007.11
【下载地址】： 下载pdf全文
IP网络物理拓扑发现通常依据设备的地址转发表（AFT,Address Forward Table）实现,相关数据通过简单网管协议（SNMP,Simple Network Management Pro
基于2个网页-
Forward Data-Base
基于MIB-II和Bridge-MIB的拓扑发现算法
交换机同时负责维护自己的生成树状态表（Spanning Tree Protocol，STP）和MAC地址转发表（Forward Data-Base，FDB）,并保存在标准SNMPv2-SMI（Structure of Management Informat
基于1个网页-
address forward table
地址转发表
基于1个网页-
Address Forward Table
AddressForwardingTable
address forwarding table
- 引用次数：20
Based on the analysis of the existing algorithm of MAC address forwarding table, it presents a kind of new physical topology discovery algorithm depended on spanning tree protocol.
在分析原有基于MAC地址转发表算法的基础上，提出一种新的基于生成树协议的拓扑发现算法。
参考来源 -
address forward table
- 引用次数：2
参考来源 - 以太网链路层拓扑发现软件的设计与实现
addresses forwarding table
- 引用次数：1
参考来源 - 数据链路层拓扑发现关键技术研究
address forwarding table
- 引用次数：1
参考来源 -
&2,447,543篇论文数据，部分数据来源于
另一方面，通过地址转发表信息来辅助确定子网中交换机与共享网段、不可网管交换机之间的连接关系。
On the other hand, it determines the connection among the switches, sharing network segment, and non-managerial switches with the FDB.
算法的主要特点是在交换机地址转发表不完整的情况下，有效地实现正确的拓扑推理。
An important feature of the algorithm is that it can infer the network physical topology correctly on the lack of the integrality of the forwarding database of switches.
通过在中间节点的转发表中填充的 VID/MAC元组中的VID和目标MAC地址的组合来标识边缘节点间 的路径。
A path between edge nodes is identified by a combination of a VID and destination MAC address in a VID/MAC tuple populated in the forwarding tables of intermediary nodes.
$firstVoiceSent
- 来自原声例句
请问您想要如何调整此模块？
感谢您的反馈，我们会尽快进行适当修改！
请问您想要如何调整此模块？
感谢您的反馈，我们会尽快进行适当修改！& ☆关注我们：
11 大量TC报文导致框式交换机ARP学习异常故障案例
涉及产品和版本
S交换机所有产品和版本
如图1-20所示，Switch-A和Switch-B通过Eth-Trunk链路直连，起VRRP协议，Switch-A为VRRP主设备，Switch-B为VRRP备设备。Switch-A和Switch-B做三层网关，下挂多台接入交换机做二层，均使能了STP协议进行破环。二层交换机直接接入用户。
图1-20 大量TC报文导致框式交换机ARP学习异常组网图
Switch-A交换机上ARP学习异常，有很多Incomplete的ARP表项，下面用户终端的ARP时有时无，业务不稳定。
Switch下挂的二层交换机上，STP域的边缘端口均没有配置stp edged-port enable，这些端口状态发生变化时会发送TC报文，Switch收到后进行STP收敛处理，立即清除ARP表项或进行老化探测处理Switch上因为ARP数量比较多，发送大量ARP请求报文进行探测，收到用户的ARP应答报文比较多，超过了cpcar值，部分ARP应答报文丢弃，这些ARP将被老化删除，对应用户业务不能使用。Switch频繁收到这样的TC报文，业务更加不稳定。
1.&登陆设备进行观察，查看VLANIF27接口下的ARP。该VLANIF接口接入的是经常在线的用户的服务器。长时间观察，发现接口下的ARP总数有时在50个左右，有时在20个左右，数量不稳定。同时还有Incomplete状态的ARP，IP地址也不固定。学习到的ARP表项的老化时间有时都为0。
从现象看，Switch应该是收到了TC报文，进行了老化ARP的操作。
2.&通过display stp tc命令也可以看到端口收到的TC报文情况：
3.&分析日志，日志中也显示收到TC报文、进行ARP表项老化处理的记录：
同时有arp-reply报文的cpcar丢弃记录：
基于上面的信息，分析得出：Switch频繁收到TC报文，进行老化ARP表项的操作。设备需要发送大量ARP探测报文，用户终端回应arp-reply报文的数量也很多，超过了cpcar的car值，部分应答报文丢弃，ARP表项就会老化删除，影响到业务应用。
Switch收到的TC报文是下面的接入交换机发送的。接入交换机直接连接PC，端口使能了STP，但是没有配置stp edged-port enable。PC在开机和关机时，很多边缘端口UP、DOWN，交换机就会反复发送TC报文。
将这些边缘端口配置stp edged-port enable后，经过几天的观察，没有再出现问题了，用户的业务运行正常。
总结与建议
类似的问题出现过很多次，交换机做网关，下挂二层交换机接入用户，网络中使用STP协议破环。通常，二层交换机上的STP边缘端口都没有配置stp edged-port enable。用户PC上线、下线，端口就会反复UP/DOWN，设备向STP根节点发送TC报文。网关设备频繁进行STP收敛，清除ARP，导致ARP学习异常。
这种应用场景下，推荐配置：
1.&交换机上配置stp converge normal，这样交换机收到TC报文，不会立即清除ARP，而是发起ARP探测，探测失败才会删除ARP，对流量转发不会造成很大的影响；
2.&二层交换机的STP边缘端口上配置stp edged-port enable，这样边缘端口的状态变化不会引起网络反复进行STP收敛。
12 大量TC报文导致CPU高的故障案例
涉及产品和版本
S交换机所有产品和版本
1.&&通过网管监控的CPU利用率情况，如图1-21所示：
图1-21 通过网管监控看到的CPU利用率
2.&同时设备上还出现CPU占用率过高的日志信息。
3.&同时设备上还有大量的ARP报文超过CPCAR后丢弃的日志记录。
4.&采集端口TC（Topology Change）报文收发情况。
如图1-22所示，所有使能STP的端口，接收的TC报文计数均在增长。
图1-22 端口TC报文计数增长对比图
问题根因说明
通过查看端口的TC报文计数，发现端口收到大量的TC报文，且在不断增长。触发MAC删除、ARP表项刷新，设备处理大量arp-miss、arp-request和arp-reply报文，导致CPU升高，OSPF Hello报文、VRRP心跳报文不能及时处理，出现震荡。
问题判断方法
1.全局配置stp tc-protection。
配置此命令后可以保证设备频繁收到TC报文时，每2秒周期内最多只处理1次表项刷新。从而减少MAC、ARP表项频繁刷新对设备造成的CPU处理任务过多。
2.&全局配置arp topology-change disable及mac-address update arp。
当设备收到TC报文后，默认会清除MAC、老化ARP。当设备上的ARP表项较多时，ARP的重新学习会导致网络中的ARP报文过多。配置arp topology-change disable、mac-address update arp后，在网络拓扑变化时，可以根据MAC地址的出接口变化刷新ARP表项出接口。可以减少大量不必要的ARP表项刷新。
V100R006版本开始支持mac-address update arp，V200R001版本开始支持arp topology-change disable命令。
在部署STP时，建议配置TC保护功能，所有连接终端的接口配置成边缘端口，这样可以避免某些端口的状态变化引起整个STP网络震荡而重新收敛。在处理CPU高的问题时，多关注cpcar丢包情况。
13 MSTP环路导致CPU占用率高的故障案例
涉及产品和版本
S1/V200R002/V200R003
MSTP网络中出现S5700交换机CPU使用率高。
MSTP环网中，因各类原因引起拓扑重新计算，网络中会发布大量拓扑改变BPDU报文，使得设备占用CPU进行计算，从而导致CPU使用率高。
1.&执行命令display interface brief，查看端口带宽使用率是否较高。
2.执行命令display stp tc-bpdu statistics，查看端口TC/TCN报文收发计数，发现设备收到大量的TC报文。
由于网络中无法确定引起拓扑改变的故障点，为解决本设备CPU使用率高的问题，可进行如下操作：
−&使能arp topology-change disable，即当网络的拓扑变化的时候，系统的ARP表项不再进行老化或者删除操作的功能
−&使能mac-address update arp，即当MAC地址的出接口变化时，通知更新ARP表项的出接口。
V100R006版本开始支持mac-address update arp，V200R001版本开始支持arp topology-change disable命令。
CPU使用率明显下降，问题解决。
总结与建议
当在MSTP网络中发现设备使用率高的问题时，应首先查看设备是否收到大量TC报文。若收到大量TC报文，可以采用关闭ARP随拓扑变化老化删除功能，启用MAC地址出接口变化同步更新ARP表项的功能来解决。
14 S9300端口配置处理BPDU报文导致STP收敛异常的故障案例
涉及产品和版本
框式交换机所有版本
问题现象描述及组网
如图1-23所示，S9300（V100R003C00SPC200）与S8500组成RRPP环，其中S9300为RRPP主节点，红色标注的为RRPP阻塞口。下挂的S3328、S5624均使能STP，S9300、S8500透传STP报文。用户反馈S3328上STP可以正常收敛（红色标注的为STP阻塞口），但S5624上的STP一直震荡。
图1-23 S9300端口配置处理BPDU报文导致STP收敛异常的故障案例组网图
问题根因说明
S5624全局、端口默认使能NDP，S9300连接S8500、S5600端口下由于配置了bpdu bridge enable，导致S5624发送的NDP报文成环，冲击S5624的CPU，无法正常处理STP报文。
问题判断方法
分析S9300、S8500上连接S5624、S3328的端口配置，除端口下允许通过的VLAN不同外，其他配置都相同。
S9300端口配置如下：
实验室复现环境中发现当S9300、S8500、S5600互连端口均UP后，S5600的CPU利用率很快上升到100％。对S5600端口收到的报文进行分析，发现端口收到了大量NDP报文（目的MAC：0a）。
S5600全局和端口默认使能NDP，端口会定期发送NDP报文。NDP报文到达S9300后，S9300 RRPP主、副端口下均配置了bpdu bridge enable，副端口虽然被RRPP阻塞，NDP报文可以正常转发。从而导致NDP报文在S8500、S9300间成环，并通过GE1/0/2端口转发到S5600。大量NDP报文冲击S5600，STP报文不能正常处理。而S3328全局、端口默认不使能NDP，收到NDP报文后会丢弃，所以STP收敛正常。
删除S9300连接S8500、S3328、S5600端口下的bpdu bridge enable配置。
S2版本端口下的bpdu enable命令，V100R003、V100R006版本端口下的bpdu bridge enable命令用来使能端口转发BPDU报文，端口对收到的目的MAC属于BPDU MAC并且没有上送CPU处理的报文不会丢弃，直接硬件转发。端口的二层协议透传功能不需要借助bpdu enable或bpdu bridge enable配置。BPDU MAC可以通过display bpdu mac-address命令查看。
盒式交换机V100R006之前的版本使能二层协议透传功能的端口，除配置bpdu-tunnel enable或l2protocol-tunnel enable外，S2300全局、S端口下需要配置bpdu enable，相关报文才能被上送到CPU处理。
15 ATAE设备STP超时时间计算不合理导致STP网络振荡的故障案例
涉及产品和版本
S交换机所有产品和版本
交换机和ATAE老版本使用STP对接，交换机为根桥，交换机上配置stp timer hello为1秒，上游交换机短时间繁忙或网络有少量丢包，可能会导致ATAE STP超时振荡。
ATAE老版本超时时间=HelloTime × 3，没有TimeFactor时间超时因子，所以当根桥配置HelloTime时间为1s时，ATAE超时时间就是3s，当上游设备繁忙或网络有少量丢弃，ATAE STP就容易超时振荡。
ATAE新版本已经和S系列交换机一样，超时时间已经修改为HelloTime × TimeFactor× 3，HelloTime默认为2s，TimeFactor默认为3，所以默认超时时间为18s。
1.ATAE老版本是否配置stp timer-factor时间因子；
2.STP根桥上HelloTime时间是否为1s，即查看配置是否为stp timer hello 100（其中100的单位为厘秒，1s=100厘秒）；
3.另外还可以在STP振荡期间，获取报文确认是否是ATAE超时首先发出源MAC是00e0-fc09-bc-f9 STP报文的。
下面有2种解决方案：
方案1：ATAE升级到支持TimeFactor时间因子的新版本。
方案2：ATAE交换板仍然使用STP，修改主备根交换机的HelloTime时间至少为stp timer hello 300，使得ATAE超时时间至少达到9s，延长超时时间。
如果交换机在配置的超时时间内没有收到上游设备发送的BPDU，就认为上游设备已经出现故障，交换机会重新进行生成树拓扑的计算。
但是有时交换机在较长的时间内收不到上游设备发送的BPDU，是由于上游设备的繁忙造成的，在这种情况下一般不应该重新进行生成树计算。因此，在稳定的网络中，应将超时时间配置的长一些，以减少网络资源的浪费。
在稳定的网络中，建议将Timer Factor的值设置为5～7。
附件: 您需要才可以下载或查看附件。没有帐号？&&
UID107115&帖子2720&积分88533&经验88533 点&威望3 点&阅读权限150&注册时间&最后登录&
UID45298&帖子370&积分4678&经验4678 点&威望0 点&阅读权限100&注册时间&最后登录&
环路故障之经典案例解析（四）
16 交换机和S6500 RSTP互连端口DOWN后重新UP，但RSTP无法快速收敛故障案例涉及产品和版本
S交换机所有产品和版本
如图1-24所示，两台S6500和Switch组成RSTP环，稳定状态下阻塞点为Switch与S6500-2相连的端口。
图1-24 Switch和S6500 RSTP互连端口DOWN了重新UP后RSTP无法快速收敛组网图
通过shutdown S6500-1与Switch相连的端口，再恢复该端口来检查RSTP快速收敛机制，发现S6500-1与Switch之间的链路恢复后，S6500-1与Switch的端口一直为discarding状态，30s后才转换为forwarding状态。
使用命令debugging stp all，查看Flags字段是否有Agreement标记，如下只有Proposal：
S6500-1与Switch相连的端口UP后，S6500-1发出的Proposal报文，没有携带Agreement标记，导致接口无法快速迁移，即Proposal/Agreement机制不生效。
在Switch与S6500相连的接口下配置stp no-agreement-check。
总结与建议
当Switch和其他厂商的设备进行互通时，需要根据其他厂商设备的Proposal/Agreement机制，使用stp no-agreement-check命令来选择接口使用增强的快速迁移机制还是普通的快速迁移机制。
17 配置单播抑制导致RRPP震荡持续一个小时故障案例
涉及产品和版本
S交换机所有产品和版本
如图1-25所示， RRPP主节点不停被破环，然后网络又成环。
图1-25 RRPP环形组网
RRPP环协议震荡，持续时间1个多小时，在日志中未见有异常（比如接口震荡），也没有发现在RRPP环上的接口有出入方向的FCS等异常计数；
根据测试的结果来看,RRPP的HELLO报文在端口的未知单播流量增大的时候会被丢弃。连续丢弃3个报文后，RRPP的环状态为Failed，待收到下一个HELLO报文时,又恢复正常。RRPP的环状态就在Failed和Complete之间震荡。
1. 按照现网的配置搭建测试环境，S3328上的RRPP状态正常。
2.测试仪向S3328发送携带RRPP的contral-vlan的未知单播流量
3.查看设备的RRPP状态，出现协议震荡，且恢复时间间隔为与现网的现象相同。
4. 由复现结果可以断定，现网中由于配置未知单播抑制引发协议震荡，可执行命令undo unicast-suppression，删除未知单播抑制功能。
总结与建议
客户在RRPP环上的端口不要配置未知单播抑制。否则，未知单播流量增大的时，有可能造成RRPP的HELLO报文丢弃，影响RRPP环状态的稳定，造成协议震荡。
18 配置未知单播抑制，RRPP环出现震荡的故障案例
涉及产品和版本
S交换机所有产品和版本
如图1-26所示，SwitchA作为RRPP环的主节点，正常情况下GE1/0/0为Primary port、GE2/0/0为Secondary port（block）。
图1-26 RRPP环组网
RRPP环组网中，主节点不停被破环，然后网络又成环。
设备上配置了未知单播抑制功能，而RRPP的协议报文的目的MAC为未知单播MAC。在端口未知单播流量较多时，RRPP协议报文会被抑制掉，从而导致设备认为RRPP的环链路出现故障，从而放开阻塞，导致成环。
1. 通过display rrpp statistics命令查看到，设备不时发送或者接收到LINK DOWN报文，并且设备上的主端口和负端口的HEALTH报文Send和Rcv计数不一致；
2. 查看配置，设备上面配置了未知单播抑制命令unicast-suppression。
3. 接口视图下执行命令undo unicast-suppression，删除未知单播抑制功能，故障解除。
总结与建议
在使用RRPP、SEP、ERPS等协议，协议报文目的MAC为单播MAC时，请您不要配置未知单播抑制。
19 CX600和S3300组成的RRPP环路业务中断故障案例
涉及产品和版本
S交换机所有产品和版本
如图1-27所示， CX600和S3300组成的RRPP环形 组网，出现下挂业务中断现象。
图1-27 CX600和S3300组成的RRPP组网图
RRPP环形网络中CX600出现和S3328相连接口频繁UP/DOWN的问题，随后CX600所在RRPP环出现成环问题，并且该CX600下挂的其他RRPP环也出现了环路，导致了下挂业务异常，将出现问题的RRPP环手动断开后，业务恢复。
出现问题的原因是由于链路质量不好，在拔插光纤时CX600和S3328两边接口UP出现了时间差，导致RRPP协议报文丢失，所以报文开始大量复制并迅速成环，结果在很短时间（1s）内就超过流量调度芯片能力挤占业务报文和协议报文带宽，造成RRPP环不能正常恢复，从而更加剧环路，并影响所有连接到同一个数据VSI中的所有RRPP环，导致S3300下挂的业务异常。
1. 登录CX600设备，发现透传RRPP协议报文的子接口没有配置任何提升RRPP协议报文调度优先级的命令，RRPP协议报文在CX600上完全按照普通的数据报文转发，一旦出现超带宽的流量，RRPP协议报文很可能被随机丢弃。
通过查询流量调度芯片TM的计数发现，有超时和检测错误出现，说明当时设备的流量非常大，超过了该芯片能处理的能力，这种情况下报文丢弃严重。
2.分析日志发现CX600上连接RRPP环的端口变DOWN后，此时RRPP环的主节点肯定会放开副端口，但是由于和交换机UP时间不一致，有很大几率导致1s钟左右的环路。如果下一个RRPP协议报文能够正常收到都会阻断副端口，防止成环，但是现网中RRPP报文被大量丢弃。
3. Loopdetct检测到环路，阻断相关子接口，上报trap告警。因为loop-detect报文是公司私有协议报文不带任何优先级信息，该报文很可能被丢弃，所以不是所有的环都会出现阻断信息。
总结与建议
1. 现网S3328，端口已经配置trust 802.1p以及qos wrr queue-index 7 weight 0 ，对于RRPP协议报文优先通过给予了保证。只需要再在CX600端口上配置trust upstream default以及trust 8021p，就保证RRPP协议报文优先通过。
2.在CX600上部署防攻击方案，保证在出现环路时，CX600上路由协议正常运行。
20 RTN设备与S交换机对接ERPS无法工作故障案例
涉及产品和版本
S交换机所有产品和版本
如图1-28所示，RTN网络为了提高网络可靠性，添加了两台交换机SwitchA和SwitchB，将RTNA和RTB链式网络改造为环状网络，同时在交换机和RTN上部署ERPS协议。
图1-28 RTN设备与交换机对接ERPS无法工作组网图
网络中发现RTN的owner节点和交换机的ERPS连接点均被阻塞。
RTN设备与交换机发送的ERPS报文不一致，RTN设备发送的ERPS报文中的EtherType为0x8809，不符合标准（标准中该值为0x8802），导致交换机收到RTN设备的ERPS报文无法上送，从而交换机侧端口也被阻塞。
1.利用display erps verbose确认ERPS端口状态异。
RTN侧的RPL owner口已被阻塞，SwitchB上的GE2/0/36也被阻塞，说明ERPS的端口状态异常。
2.执行命令display erps statistics，查看交换机ERPS报文计数，判断交换机是否收到RTN设备发送过来的报文。
从统计计数上看，GE2/0/36没有收到过RTNB发送的ERPS报文。可在GE2/0/36的链路部署获取报文，分析RTN和交换机的发送的ERPS报文是否有差异。
本案例中，通过分析RTN和交换机发送的ERPS报文发现，RTN设备发送的ERPS报文中的EtherType为0x8809，交换机中发送的ERPS报文中的EtherType为0x8802，而标准中ERPS报文中的EtherType为0x8802，说明RTN设备实现的ERPS不符合标准，交换机无法上送RTN发送的ERPS报文，导致上面的问题发生。
此时，在能满足客户要求的前提下，工程师可以部署其它可对接的环路避免技术，例如STP。
总结与建议
在设计方案时，涉及到ERPS的对接场景，可先分析各个设备的ERPS的报文是否符合标准，将此类问题消灭在方案阶段。遇到此类ERPS对接问题，也可优先从分析ERPS报文入手。
附件: 您需要才可以下载或查看附件。没有帐号？&&
UID4534&帖子6610&积分35608&经验35608 点&威望3 点&阅读权限200&注册时间&最后登录&
注意注意，誉天5月优惠来袭，超值优惠带回家！
欲知详情，往下看
优惠内容：课程免费学，减学费，送考试，包就业
优惠细则：
一、【课程免费学】0元学hcnp就业直通车
凡报名成功0元学hcnp就业直通车课程，誉天提供免费推荐就业服务，推荐就业到各大知名企业，保障6-10万年薪。（只限50个名额，满额报名立即截至）
地址：武汉，广州，北京，杭州
二、【双直通车课程包就业】享折扣，包就业
凡报名誉天双直通车课程，任意一门享有7折优惠，同时享受包就业VIP服务。（仅限前20名）
三、【高级课程超值换购价】超值价换购誉天热门课程
凡报名誉天任意高级课程（HCIE/OCM/RHCA/CCIE），仅需5999元即可学习价值价值8600元的RHCE/OCP培训考试课程。
四、【免费补考】报名即送免费补考
凡报名誉天红帽认证RHCA培训+考试，即送万元红帽RHCA五门免费补考。（仅限前20名）
五、【减免学费】最低可减免300元现金
报读誉天RHCE/OCP认证课程，还可优惠300元，可抵现金使用
【誉天教育官方微信】（微信公众账号：誉天教育 ；或加微信号：yutianedu2013） 求调戏
▲誉天Cisco/Linux/Oracle微博[微群]
誉天微博：
誉天微群：
UID467488&帖子3&积分4&经验4 点&威望0 点&阅读权限10&注册时间&最后登录&
蛮通，电器再多，插孔一组就够！插头插座的换代品！
[通过 QQ、MSN 分享给朋友]