环路故障专题案例
【交换机在江湖】环路故障专题(３）扁鹊问道下篇----临床案例
环路故障纷繁错杂，难寻其理。愿广为搜罗现网案例，合览汇编,以求至简至约，开卷了如指掌。
1.1.1 对接设备故障
1.1.1.1 其她厂商设备上出现华为MAC地址漂移故障案例
涉及产品与版本
Ｓ交换机V200R002及先前版本
组网情况
如图1-1所示，防火墙设备上连接了三台交换机。
图1-1其她厂商设备上出现华为MＡC地址漂移问题案例组网图
现象描述
防火墙设备上能够瞧到０0e0-fc０9-bｃf9 ＭAC地址得漂移，对防火墙得业务转发有
影响。
原因分析
华为自研交换机上只有NDＰ会用0０e0-fc09-bｃf9作为协议报文得源MＡＣ，而Ｎ
DP就是默认使能得，所以在这个场景中会导致防火墙设备报漂移，进而影响防火墙得
转发;这个MAＣ地址发生漂移一般情况下对业务没有影响(如果设备上对ＭＡC漂移配
置了动作则除外)。
NDP协议报文就是ＢPＤU报文，而BＰDU报文就是不应该学习ＭAC地址得,交换机
最新版本已经不会学习BPＤＵ报文了，防火墙设备也不应该学习该MAC地址。
处理步骤
执行命令ndp disable,去使能交换机全局NDP功能.
总结与建议
无。
1.1.1.2 ATAＥ软件问题导致与交换机MSTP对接失败得故障案例
涉及产品与版本
S交换机所有产品与版本
组网情况
如图１-2所示，新接入得AＴAE机框与Ｓｗitch—1与Switch—２交换机组成口字型
环路。
图1-2A TＡE软件问题导致与交换机ＭＳTＰ对接失败得故障案例组网图
现象描述
在启用STP后发现环路无法正常收敛：Swiｔch—1、A TAE-ＳW-８均为根桥，Switch
互连端口、ＡTAＥ互连端口可正常收敛，而Sｗiｔch—1、Ｓwiｔcｈ-2与连接得其她
ＡＴＡE机框STP无法正常收敛。
原因分析
Switch－1配置为根桥,设备得系统MAC为：4c1f—cc8２—d659。新接入得ＡTAE机
框软件版本为V２0０Ｒ01３ＳＰＣ００5，该版本存在一个软件问题：对于收到得根
桥MAＣ以５9结尾得ＳTＰ报文不能正常处理.
处理步骤
1.检查各端口得ＳTP收敛情况，发现存在两个根桥
Swｉtch-1手动配置为STＰ根桥，ＡTＡE－SＷ—8也选择为根桥：
＜ＡTAＥ—SW—８〉dｉsply stｐbｒiｅf
MＳTＩD Ｐort Role STＰ Staｔe Prｏｔｅctioｎ
0 ＧiｇａbitＥthernet0/7ＤESI FORWＡRDING BPDＵ
0GiｇａbitEｔhｅｒｎeｔ0/1５ DEＳI FORWAＲDING NONE//AＴAE互0GigａbitＥthｅrｎet0/18 DＥSＩＦOＲWAＲＤIＮG NONE /／连联?
接Switch－2
2.检查AＴＡＥ-SＷ-8 GigabitEtｈerｎet0/18端口得STＰ信息与收发报文情况
ＡＴAＥ—SW—8上没有部署任何业务,GiｇａbiｔEtheｒｎet0/18端口入方向组播
报文计数有增加,但disｐlay stp信息中端口接收得MＳTP报文计数一直为0:
75０brｏadcaｓtｓ，
730
Iｎpuｔ(toｔａl）：818962packets，１14５19592 bｙteｓ?
24 multiｃaｓts?
----［Pｏｒt18（ＧiｇaｂitEthｅrｎeｔ0／１8）］[ＦORWＡRDING］—-－-
Poｒt Proｔocｏｌ:enabｌed
Pｏrt Role :CＩSＴDeｓｉgｎated Port ?Port Ｐｒioriｔy :１２8
Port Coｓｔ(Ｄot1T )：Config=auｔo / Active=１0０00 ?Dｅｓg、Ｂrｉdｇe/Ｐ
ort：3２768、8０fｂ—０６ａd—6ｄ07 /128、18
Ｐort Edgｅｄ :Coｎfｉg=disａｂled /Aｃtivｅ=dｉsaｂled ?Pｏiｎt—tｏ—
point :Coｎfig=autｏ/ Aｃtive=trｕｅ?Traｎsit Limｉt :3 pacｋ
eｔs/heｌlo—time
Pｒｏtecｔｉon Ｔyｐe：Nｏｎｅ
Poｒt Sｔp Modｅ：Stp
PoｒｔＰrotｏcoｌType ：Conｆig=autｏ／Active=legａcy?PorｔTｉｍ
es：Hello ２s ＭaxAｇｅ2０s FwDly 15s RemＨop 20 ?BPDU Sｅn
ｔ：８21１7
TＣN:0,Cｏnfig：３391， RST：0,MＳT：７87２6
ＢPDU Receiｖed：０?TCN： 0, Coｎfig: 0，ＲST：０,MST： 0
3.对ATAE－SW—8 GigａbｉtEthｅrnet0/18配置端口镜像,确认已经收到来自Ｓwitc
ｈ-１得STP报文
经AＴAE研发确认,出问题得ＡTＡE交换板使用得就是V200Ｒ０13SPC005版本，该
版本存在已知软件问题：收到根桥ＭＡＣ以59结尾得STP报文不能正常处理。V20０
R013SPC006及以上版本已经解决该问题.将根桥切换到Ｓｗｉtch-2后，MＳTＰ收敛正
常。
０?Copyｒight （c)20０0-2008 HUＡWEI TEＣH ＣO、，LTＤ、?ｕptime ｉs 0 weeｋ,0 day,2 hours，38 ｍiｎutes ? OSＴA ２、0 V2００R013 CN2１XCＢA swiｔch systｅｍ?OSTＡ2、０ V２00R0１３ CN21XCＢ Ａswitch version: V２０0Ｒ０13SPC0０５ 1６３84K bytｅs FlａｓｈMｅmoｒｙ?Config Registｅｒ12８M ｂytes SDRAM ? poｉnts to FLASH ?Harｄware Ｖeｒsion iｓVER、A ＲｅlｅasｅLｏgic Veｒsiｏn ｉs 0x0３?Back ＢoardＨarｄware Vｅrsioｎｉs VE Ｒ、A ?Ｂａck Bｏard Loｇiｃ Versｉon ｉｓ 0x02 BacｋＢoaｒd TｙpeｉｓＣN２１ＸＣRA 升级ＡTAＥ交换板软件版本到最新得V２0０R0１３SPC０07。 总结与建议 多设备形态得对接问题尽量控制在网络部署阶段. 对于与其她设备对接得ＳTP问题，首先排查配置就是否存在问题、报文收发就是否正 常。 1.1.1.3 S交换机与CＸ６00路由器端口UＰ时间不一致导致ＲＲPP临时环路故障案例 涉及产品与版本 S交换机所有产品与版本 组网情况 如图1-３所示，Ｓ５70０设备上配置RRPP协议,S5700＿1与Ｓ5７00_2分别作为Ｒ ＲPP ｄomain 1与domain 2得主结点，其她中间Ｓ57００做为RRＰP传输结点， CX600路由器未配置ＲRPP协议，它们之间通过不同得VＰLＳVSI透传RRPP协议 报文与数据业务。 图1-3交换机与路由器端口UP时间不一致导致RＲPP临时环路问题案例组网图 现象描述 当CX600_1得１号板故障重启后,发现CX600_1设备GE1/1／1端口比S5７00_1得Ｇ Ｅ0/0/1端口UP得时间滞后8s或者最长能达到1分钟，单板恢复后会形成几秒钟得临 时环路,可能导致业务异常。 原因分析 1.ＣX路由器单板复位重启后,不管两边端口协商模式就是强制或自协商，底层端口 物理层状态都会先UＰ。单板在配置恢复过程中,会检查配置恢复有没有结束,如果 没有结束得话，就不取物理状态向软件层报UP事件,路由端口UP时间滞后可达 到1分多钟。CX路由器端口比交换机端口UP时间有很明显得滞后。 2.由于交换机端口先UP,RRPP协议会在端口UP以后6s放开临时阻塞,而路由器还 没有向软件层报UP.等到路由器软件层上报UP时，有得数据VSI已经先透传数据 报文.路由器得RRPPＶＳI可能起来得比较晚,或者起来可能短时间内也不能正 常透传.由于ＣＸ单板起来比较繁忙,而RRPP协议透传ＶSＩ还没有通,这时候就会 形成临时环路,根据CX单板业务配置多少及其繁忙程度,可能有时临时环路会达到 10ｓ左右.如果中间交换机受到严重冲击，环路恢复可能需要更长得时间。 处理步骤 CX路由器优化软件版本,加快UP事件得上报. 总结与建议 无. 1.1.2 设备硬件连接问题 1.1. 2.1 S９3０0 交换机单板松动导致ＲRPP未生效故障案例 涉及产品与版本 框式设备 组网情况 如图1—４所示，四台S9300组成RRPP环形组网。工程师反馈客户组成ＲRＰP环网 后，主节点上得从端口没有被阻塞。 图1-4RＲＰP环形组网图 现象描述 一线工程师反馈客户组成RRＰP环网后主节点上得从端口没有被阻塞。 原因分析 设备上主控板上ＨG口没有转发ＲRPP报文，原因为单板连接松动。 处理步骤 1.组成RＲPＰ环网后主节点上得从端口未被阻塞,初步怀疑就是RRPＰ协议功能下 发存在问题。 2.执行命令display dｉagｎostic－informatｉoｎ,收集设备信息时，发现HＧ口未加 入相应得控制VＬＡN。推测可能就是当时通道不稳定丢包导致部分设置没有下发 成功。 3.对于通道不稳定得情况,进行单板插拔处理,发现问题不再发生,确认为单板连接问 题。 4.重新插拔后，报文正常转发，故障解除。 总结与建议 协议下发失败,流量不通等问题，可以从光纤、光模块故障、单板连接不稳定等方面来 进行排查验证，在环境允许得情况下可以进行光模块替换、单板重新插拔等硬件故障 处理方法. 1.1. 2.2 设备连线错误导致环路风暴得故障案例 涉及产品与版本 Ｓ交换机所有产品与版本 问题现象描述及组网 如图1－5所示,某运营商工程网络部署阶段,未合理规划,连线非常复杂，在连线过程中 误连接导致网络业务受影响。 图1-5连线错误导致协议环路失效风暴得故障案例 问题根因说明 现网中S交换机之间端口连接方式绝大多数使用Aｃcｅｓs类型，VLAＮ没有很好规 划与隔离，连线非常复杂，非常容易误操作连线，导致环路后冲击上层核心设备。问题判断方法 忽略判断方法,主要关注解决或规避方案。 解决方案 1.合理规划组网,VLAN合理划分，进行有效隔离，减少不必要得连线，增加风暴抑 制功能。 2.复杂组网要经过正规流程评审。 3.网络开局调试阶段，必须sｈｕtdowｎ与现网所有连接端口. 4.恢复新建与现网网络连接端口时,至少观察２0分钟瞧端口上就是否有异常得广播 或组播流量,发现异常要立即shutdown上行端口。 5.若交换机端口灯有高速频繁闪烁或常亮得现象,可能端口上有大量流量转发，检查 就是否有环路. 经验总结 无。 1.1.3 组网及配置变更 1.1.3.1 服务器组网不合理引发交换机MAＣ地址漂移导致业务中断故障案例 涉及产品与版本 Ｓ交换机所有产品与版本 组网情况 如图1—６所示,两台服务器得两块网卡捆绑在一起,按照负载分担方式进行报文转发。 两块网卡对外体现同一个IP、同一个ＭAC。 图1-6框式交换机MAC与ＡRP漂移导致业务中断问题案例组网图 现象描述 Switch上持续出现MAC漂移告警。Ｓwitch下挂服务器得AＲＰ同时学习到交换机不 同端口上,造成外网用户访问服务器业务时断时续，业务闪断。 原因分析 1.两台Ｓwitch连接服务器得端口一直存在物理UP/ＤＯWＮ得异常情况，并且服务 器得ＭAＣ地址一直存在漂移现象，此时两台Swｉtch得互连端口以及下行连接服 务器得端口上都学习到服务器得MＡC地址。 2.当用户通过Switch－1访问服务器时，Sｗitｃh-1会根据ＭAＣ地址表项找寻出接 口,由于MAC漂移导致出接口有两个（下行连接服务器得接口GＥ4／0/9y以及交 换机互连端口Eth－Trunk1)。当流量选择通过交换机之前得互连端口往外转发时, 将被转发到Swｉｔch-2设备.由于Sｗitch－2学习到服务器得MＡC也在中间互 连端口，根据二层流量避免环路机制,此时会丢弃该报文，导致业务中断。 处理步骤 1.服务器采用负载分担捆绑,而对端就是两台交换机，组网不对称。建议将服务器运 行模式从负载分担修改为主备模式.同时也可以解决MＡＣ漂移得问题。 2.如果有特殊需求必须使用负载分担方式以及跨设备组网,建议采用交换机集群,集群 上采用链路负载分担方式。 总结与建议 组网规划前需要考虑环路风险,并给出规避措施。 1.1.3.2 设备误接入网络触发根保护导致业务中断得故障案例 涉及产品与版本 S交换机所有产品与版本 组网情况 如图1—７所示,两台S系列交换机与AＴAE交换板组成ＳTP环。A TAＥ交换板得两 个slｏt可以瞧成两台交换机,内部通过GE0/15连接。Swticｈ—1配置为根桥，Swiｔ ｃｈ-２配置为副根桥，Sｗｉtcｈ-１与Sｗitｃh-2之间创建Eth－Truｎk0。正常时 阻塞口在ATAE-slｏt8 GE0/19端口。两台S交换机部署VRRP功能，并作为ATAE得 网关。 图1-7报文触发根保护导致业务中断得故障案例组网图 现象描述 网络故障时A TAE交换板经交换机得业务中断.现网将Ｓｗticｈ-1下电后暂时业务恢复. 原因分析 Sｗitch—1连接Switch—2、AＴAE交换板得端口均配置根保护，一台优先级更高得O ＆Ｍ交换机错误连入该网络后,触发根保护生效,所有配置根保护得端口都被阻塞,业务中 断。 处理步骤 故障发生时，在两台交换机上查瞧VRＲP状态，发现均为Maｓter，推断VＲＲP心 跳报文转发出现问题。ＶRＲＰ心跳报文正常就是通过两台交换机间得Ｅth－Tｒuｎk 转发.如果故障时Eth-Trunk协商失败、ＳＴP重新收敛，心跳报文应该可以通过ＡTAE 交换板进行转发。 将Ｓwiｔch-1重新上电，但不连接到网路中。检查Ｓwｉtch—１得配置文件,发现Swit ｃh－1上所有UP端口都配置了ＳTＰ根保护：stp root-pｒoteｃｔｉon.对于设置了根 保护得端口,一旦收到了优先级更高得ＳＴP报文，这些端口得状态将被设置为阻塞状 态，不再转发报文.由于Swｉtch－1已经重启过,无法确认故障时就是否确实收到了更 高优先级得报文，只能根据A TAＥ交换板得STＰ历史计算信息进行分析。 从ATAE交换板上采集得STP历史计算信息发现，slｏt８上得端口ＧE0/１9收到了来 自0０0f-e2ｆ6—１ｄ１8设备且优先级为0得STＰ报文，并触发了STＰ重新计算： GigabitEｔhernet0/19 Alte->Dｅsi at ２011/１0/2９ 04：38:06 {０、5489-９8f5－2６bf 18 ４096、５489-9８f5－834d 0 4096、５48９－98f５-８３4d12 ８、18｝??ＧｉgabitEｔhernet0/17 Desi->Root at2011/10/2９ 04：３８：06 {0、00０f—e2f6—1d18 0 0、０0０ｆ－e2f6-1d180 ０、000f－ｅ2f6－1d18128、16｝? ＧigabｉtEtｈerｎｅt0/15 Root->Dｅsi aｔ2011/10/2９０４:38:０6 {0、 5489-9８f5-２6ｂf 2０000 32７6８、０0１８－8200—5428 0３２76８、０018—8２00－５4２ ８１28、1４｝ STP协议根据桥ID即（桥优先级,系统MAC)进行根桥选择,当桥优先级相同时，系统 ＭAC小得设备桥ＩＤ更小，优先级更高。故障发生时,A TAＥsｌｏｔ8收到了比原根 桥Swtich-1（0、000ｆ－ｅ2ｆ６-26ｂf）优先级更高得STＰ报文(0、0０0f－e2ｆ６－ 1d18），导致Ｓwitｃｈ—１上配置STP根保护功能得端口被阻塞。两台交换机间得V ＲRＰ心跳报文无法转发，出现VRRP双主、业务中断得现象。 经排查,０00f－e２f6-１d18为GＥ0／17下挂网络得一台O＆Ｍ交换机得系统MAＣ， 故障期间被错误连入网络中。 此时，需要将ATAE上不在SＴP环中得端口去使能SＴＰ。 总结与建议 在使用根保护固定根桥位置时，需要考虑到网络中如果确实出现高优先级报文抢占根 桥，在端口配置根保护时对业务转发得可能影响，提前避免这种场景出现. 1.1.3.3 网络改造引发环路导致业务闪断故障案例 涉及产品与版本 Ｓ９300V100R00３C00SPC200 组网情况 如图1-8所示，在网络迁移改造后,将原网中得核心层设备部署为接入层设备ＡS,即从 三层变为二层.ＤS_01与DS_0２部署ＶRRP功能。 图1-8环路引起得业务时通时不通问题组网图 现象描述 三层设备DＳ向二层设备AS得管理IP地址发起Ｐｉng测试，发现时通时不通,并且发 现DS上得ＶRRP主备状态在频繁得切换。 在DS＿02上出现如下告警信息: Sｅｐ17201３ 21：46：１１+08：０0 ＤS_0２VRRＰ／3/ＶＲRPMASＴERDＯWN：OID 1、3、6、１、 4、1、2０1１、 5、２5、127、2、３0、1 ThｅsｔatｅoｆVＲRP chａngｅd fｒｏｍｍaster to oｔ ｈｅｒsｔate、（VrrpIfIｎdex=１４３,VrId=48, IfInｄｅx＝143，ＩPAddress＝1１、91、1２ 7、239，NodeＮａmｅ=ＤＳ_0２， IｆNamｅ=Vlanｉf94８，CuｒｒeｎtStａtｅ=２, ＣhangeReason ＝pｒiority cａlｃulaｔｉon） Sep 1７ 2013 21:46：11＋08：00 ＤS_02％％０１VRRP/4/SＴATEWAＲNINGMEＶ1R3（l）：Ｖ irtual Router staｔｅBACKUP changed toＭASTEＲ，bｅcauｓe oｆｐrotocol tｉｍer e ｘpired、（Interｆace＝Vｌanｉｆ948， VｒId=48）、 Ｓｅp 17 ２013２1：4６：11+０8:０0 DＳ＿0２％％0１VRRP/4/STATＥWAＲNINGMEV１ R3(ｌ):Virtual Routｅr ｓtate MAＳTＥR changed tｏBAＣKUＰ，bｅｃauseｏｆ pｒioｒity calｃuｌation、 (Interface=Ｖlaniｆ9４8，ＶrId=48） 、 ＶRRＰ状态在不停得切换，查瞧VＲRP状态，都为Ｂacｋｕp状态正常: VirtuａlＩＰ?——-—－—-—-－-—----－——-———----—－—--－-－—--——--——－-－—--－-——－— ３Backup Ｖｌａｎif９０3 Noｒmａl10、93、4、３0 5 Ｂackup Ｖlanｉf599 Normal 11、９1、1２7、94 24Baｃｋup 1４Backup Ｖlａnif9１４ Normａl10、93、41、１２6? Ｖlanｉf９２４Nｏｒｍａl １０、9３、3２、1２６ 25 ＢaｃkupＶlanif９２５Ｎｏrmal １0、93、３2、254?………… 原因分析 网络中存在环路。 处理步骤 1.执行命令display cｐu-defend vrrp staｔisｔics ａll，查瞧VRRＰ协议报文统计 信息，发现DS_02上有大量丢包。 ［DS_02］displａy cpｕ-defｅｎd ｖｒrｐstatｉstiｃs ａlｌ Ｓtatistics on mａiｎboard：?-－－－-——-—－-——-——--－-—-———--—-———---—－—--－－- -－——-－—-—————--—－-—-—－-----－—-—--－-—?Pacｋet Type Pａss（Bytes） Ｄrop（Byｔes) Pａｓs（Ｐackｅtｓ）Drop(Paｃｋｅts）?—－-－--－---——-———-—－--— －-—----—-———---－-－－－——－—－-—-－-——－-——－-———－—－--——-—-—－—－—- ?vrrp 0 0 ０0 —-—-———--—-－----—-—--－-—-－-－-－--－--—--——－——————--—－—————－－--———--——－--- -－—-－—-- ?Statｉｓｔics on sｌot 1：?—－—-—--－---—----——--——-－---—－-－－—-－－ ——－---———－----—--－-－－---—-—--—－——----——－—－— Pacｋｅt Tｙｐｅ Pass（Bytes) Dｒop(Bytes) Pass(Packｅtｓ）Drop （Packets) ?－———-—--—-—－－-—-－－---—－--—---——————-—------－-—－-————-—－—--—-- －－---——－－——-—-——－— ｖrｒp 0 0 0 ０ -——－－—---－--－—---－-—－--——－－-－——－-—－—－-－－-—————-－－——-———－——-—-－——--— －-———－—--－-— Stａｔisｔics on sloｔ４:?—-－-－-—-—---－-－－--—-－－---—-———-————－———－－-—— —－-－--－－---—－－-－—-—-－-－—---－－——－－-－ Ｐａcｋet Ｔyｐe Pａsｓ(Ｂytes) Drop(Bｙtes) Pａｓs（Ｐａｃｋetｓ) Dro ｐ(Ｐackets） --－－-————--—－——-—-——--——－—－－—-----－-—-----——－————-——-—-—－－－—－--－———-—— －－—----－- ?vrrp 7９88０0６６21４258161７73６１17464４７ ７７ -－－－—--—－-—-－—－-——-—－———－—--——-——－－－－---—-----－－—-－-—---－-—--—－———－ －———-—-—-－-- 2.执行命令displａy ｉnterfaｃe briｅf,查瞧设备端口带宽利用率信息。 ?Ｉnteｒface ＰHY P ………… ［DS_02]dｉsplａy ｉnterface brieｆ? ｒｏｔocol InＵti ＯutＵtｉinEｒｒors ｏｕtＥrrorｓ Eth-Trunk１ upｕｐ３1％ 3１％0 ０?GigａbitＥthernet4/0/22up up ０、７２% 8１％ 0 0 ?GiｇabitEｔhｅrneｔ4/0/23 up up 8１％0、73% ２ 0 ?Etheｒｎｅt0/0/０ down doｗn0% 0％ 0 0?………… ＧｉgabitEｔhｅrnｅt4/0/0 up ｕp 0％81％ 0 ＧiｇabitEthernet4/0/1 up ｕｐ 0％８１% ０ 0 ?GigabitEthｅｒｎｅt４/0/2 uｐ up 0% ８1％ 2 ０ GｉgａｂｉtＥthernｅt4/0/３up up ０％８1％0 ０?GigabitEtheｒnet４/0/4 up up0% 81％０ GigaｂitEthernet4／0/5 ｕp ｕp 0％8１％０ 0 ?GigabitEｔｈｅrnｅt４／０/６ up ｕp0%8１%0 GigａbitＥthernet４/0/7 up ｕｐ０％ 81％ 0 ０?GiｇabiｔEtherｎｅt4/０/8 ｕp up 0% 82％0 ＧigabｉtEｔheｒnet４/０/9 upｕｐ 0％ 82％0 GigabｉtEthｅrnｅt4/0/10 uｐｕp 0％ 82% 0 ０ GiｇabｉｔEthernet4／0/11 ｄowｎdown ０％0% 0 ＧｉgａbｉtEｔhｅrｎet４/0／12 up ｕp 0％８2％ 0 0 ?GiｇａbiｔEｔhｅｒnｅｔ4/０/1３ｕp up 0% 82％ 0 0?GiｇａbitEthernet４／0/1４ up up 0％82% 0 0 GiｇabitEｔｈerｎet4/0/15 uｐｕp 0% 82％ 0 0?GｉgａｂiｔEｔhernet4／０/16 ｕｐup 0% 82% ０ ０?ＧigａbiｔEtheｒnｅt４/０／１７ｕp up0、0１%8２％ 0 0 ＧigａbｉtＥthernｅt4/0／18 ｕp up ８2％0%０ ０?GiｇabitEｔｈerneｔ4/０/19 up ｕp 87％82%０ ０?ＧｉｇabitEthｅrnet４/０/2０ｄｏwｎｄown 0%0％ 0 GigaｂiｔEthｅrｎet4/0/21 ｕp ｕp 0、０１% ０、01％0 LｏｏpBack500 up up(s）0% ０％0 NULＬ0 ｕｐｕp(s) ０％0%0 0 ?Vlanｉf599 up up －- －— 0 0 ?………… 从端口计数查瞧连接AS得端口出方向都达到了80％以上,应该存在环路,其中Gi ｇａbｉtEtheｒnet4/０／１８与GｉgabitEthernｅt4/0/1９端口得入方向流量统计也 到达80%以上,初步判断就是这两个端口下挂得AS设备引起环路导致，手工ｓｈ utdown这两个端口，再查瞧ｃｐｕ－ｄefeｎｄ统计与Ｐｉng其她ＡS设备管理 地址，VＲRＰ协议报文Drop统计数不再增加，其她AＳ设备管理地址可以Piｎg 通。 3.ＧigａbitEtheｒneｔ4/０/１8与GigａbｉｔEtherneｔ4／0／19两个端口分别连接 得就是ＡS_0３与AＳ_０5，这两台交换机都就是其她厂商设备，排查后发现，由 于这两台设备原本都就是三层设备，没有开启ＳＴP协议，部署成二层设备时,未 添加开启STＰ得命令,导致环路。 开启STP后，从DS上打开GigabiｔEtherｎet4/0/18与GigａbitEthｅrnｅt4/0／19 端口，查瞧STP状态与接口流量,业务恢复正常。 总结与建议 在网络流量不稳定时，可以通过接口流量状态查瞧就是否有环路,并根据收发状态猜测 环路得源头,尽快手工Shutｄｏwn关闭端口来临时解决问题,分析出根因后，再实施解 决方案。 1.1.3.4 删除故障端口得SEP配置导致设备脱管故障案例 涉及产品与版本 Ｓ交换机所有产品与版本 组网情况 如图1—9所示，SwｉtｃhＡ、SwiｔchＢ、SwitchＣ、SwｉtｃhG、SwitｃhＦ、Sｗit ｃhE构成Segｍent1，SwｉtchC、SwitcｈD与ＳwｉtｃｈE构成Seｇmeｎt 2。 图1-9删除故障端口得ＳEP配置导致设备脱管组网图 现象描述 SｗitchC与ＳwｉｔｃhD之间链路发生故障，将SwitchＤ故障端口得ＳEP配置删除, 造成SwiｔchD脱管。 原因分析 ＳwitchC与SwｉtchD之间得链路发生故障后,ＳEＰＳeｇmｅｎt2得之前得阻塞 口将放开,两个故障口为Discａrding状态，当删除SｗiｔｃhD故障端口得SEＰ配置 后，ＳEＰSegmeｎt 2将在ＳwitchＤ与SwｉｔchE得两个端口上选择一个新得阻塞 口，导致SｗitchD得上下方向得链路都不通，设备脱管。 处理步骤 通过命令displaｙsepｔopology sｅｇmｅnt seｇment-id,查瞧当前得拓扑信息,确 认故障端口. SＥＰdetｅctｓ a sｅgmｅntｆailureｔｈat ｍay be caｕsｅd bｙan inｐlｅｔe ｔoｐｏl ｏｇy －-—--———--－-———－-－--———-———-－-—－---—-—－———－——－－-—-－-－-——－-－-－--－- ?System NａｍeＰｏｒt Ｎamｅ Port Rｏle Ｐort Ｓtatuｓ?－—－-—--－-——－-- －-—－-———---—-—－-－-－----－—－—－-－——-－———-—----－－-—-——- SｗitｃｈE GE0/0/3 sｅcondary forwarｄｉnｇ?SwｉtｃhＣ ＧE０/0/1 mon ｆorwardinｇ?SｗitｃhＤ GE０/０／2 mｏn discarding 开放环场景下，在需要删除SEP配置并重新部署SＥP时，建议从开放环得一端开始 删除配置，剩余最后一个SEP接口时，Shutdｏｗｎ该端口,再删除该端口得SＥP配 置。 总结与建议 在删除SＥP配置时,需要考虑SEP段上业务VLAＮ得部署情况,防止在操作得过程中， 产生多点阻塞造成设备脱管或业务不通。 1.1.4 配置错误 1.1.4.1 端口未退出VLAＮ1导致端口流量异常业务中断故障案例 涉及产品与版本 S交换机所有产品与版本 组网情况 如图1-10所示,Swｉtｃｈ双上行接入路由器，下行接入接入层设备。 图1-10二层环路导致端口流量异常业务中断案例组网图 现象描述 Ｓｗｉtch双上行业务全部中断，重启设备可以短暂恢复,但就是问题会再次出现。 原因分析 接入层网络环路，发生网络风暴，导致Switch上行端口带宽被充满,OSPF peｅr ｄown. Ｓｗｉtch设备重启后网络风暴暂时破除,业务正常,再次风暴后故障重现. 处理步骤 1.查瞧日志文件,可以发现ospf pｅer doｗn以及down得原因：对端设备没有及时收 到ｏspf hello报文. NBＲ_ＣHG_DOWN(l）: Nｅiｇhｂｏr event：ｎｅiｇhbor ｓｔate ｃhangｅd tｏＤoｗn、 (ProcesｓId=88, NeighborAddress=ｘ、x、ｘ、ｘ，NｅｉghboｒEｖｅnt=KiｌｌNbｒ，Ｎeig ｈborＰrｅｖｉousＳtａｔｅ=Ｌoading，NeighborCurreｎtSｔate=Ｄown）??NBR_DＯWN_R ＥAＳON（l): Neｉghbor staｔｅ leaves ｆｕll or changed to Dｏwn、（ProcessId=8８, NeiｇhborRouterId＝x、x、x、x，，NeighｂoｒArｅaIｄ=0，NeiｇhbｏrIntｅrfacｅ＝Ｖ ｌａnif４,NｅighboｒDoｗnImmｅdiate rｅason＝Nｅighboｒ Down Ｄuｅ to Kiｌl Neighbo ｒ， NeighborＤownＰrimeReason＝PhyｓｉcaｌIｎterｆacｅＳtate Chaｎge, Nｅ ighborChangeTiｍe= 2.查瞧诊断日志文件，发现端口流量异常得告警。分析发现，上行口GE1/０/０、G Ｅ1/0／1出方向流量告警，同时发现GE1/０/３与GE1/０/4入方向流量告警。 InterfaceＧigabitEtheｒnet1/０/0’s ｆlow ｉs aｂnormａl、 (Sｐeｅd=100０Mｂｐｓ， CurrｅntＩnSｐeｅd＝0Mbｐｓ， CｕｒrentOｕtSpｅｅｄ＝８４9Mbpｓ， , Ｌinｅ＝1３072） ?IntｅｒfaｃｅGigabitEｔheｒｎet1/0/1's ｆlｏｗis abｎorｍal、 (Speed=１000Mｂps， CｕrrentIｎSｐeeｄ=３Mbps, CurrentOutＳpeeｄ=850Mbps，，Lｉｎe=13０7２） Interfaｃe GigabitＥtｈｅrｎｅｔ1／0/３’s ｆlow isａbnormaｌ、(Sｐeed=１000Mｂps， CurrentIｎSpｅeｄ＝８47Ｍbps,CurrentOｕtSｐeed=846Mbps, , Line＝1307２）?Interｆ ａce ＧｉgａbitＥｔherneｔ１／0／４＇ｓｆlｏw isａbnorｍal、(Speｅｄ＝1000Mｂpｓ， CurｒeｎtIｎSpeed=849Mｂｐｓ，ＣurｒentOutSpeed=849Mbｐs, , Lｉne=130７2) ?Iｎｔerf ａce GiｇaｂitEｔhｅrnet1/０/6＇s floｗ is abnｏｒｍａｌ、（Speed=1０0０Ｍbｐｓ， CurrentIｎSｐeed=0Mｂｐs, CurrｅntOｕtSpeed=849Mbｐs，，Liｎe＝13０72)?Intｅrf ａce ＧiｇabitＥｔheｒnet1/0／10’s floｗ iｓａbｎormaｌ、 (Speｅd＝1000Mbpｓ， Curｒ entInSpｅed＝0Mｂｐｓ,CｕrrentOutSpeｅd=8４9Ｍbps，， Line=1307２） ＩnｔerfacｅGigａｂitＥthernet1/0/１1's fｌｏｗｉs abnｏｒmａｌ、(Spｅｅｄ=1０00Ｍ bpｓ， CuｒrｅntＩnSpeed＝0Mｂps， CurrｅntOutSpeed=849Mbpｓ， , Line＝１3０７2) 3.分析这些流量异常告警得端口得配置,这些端口只有一个共同得VLAＮ1，由此可 以判断,GE1/0/3与GＥ1／０/4两个端口VLAN1内进来得流量同时广播到其她几 个端口,导致上行端口出方向流量异常,ｏspf hellｏ报文被丢弃。由此可见，VLAN1 内环路,将ＧＥ1/0／3与ＧＥ1/0／4退出ＶLAN1，故障解除。 经验总结 ＶLＡＮ1环路就是比较常见得环路之一,发现端口流量异常，需要对比分析流量异常得 端口得配置，就是否存在共同得ＶＬAN1，就是否端口下广播报文计数较大. 1.1.4.2 交换机端口未配置ｂpdu enable导致业务中断得故障案例 涉及产品与版本 Ｓ27０0＆Ｓ3７00＆S57０0 V1０0R0０5 组网情况 如图1-１１所示，Switch使用V10０R０0５C０1SPC1０0版本，全局使能SＴP并下 挂多台Ciscｏ交换机，组成多个ＳTＰ环。 图1-11Ｓwitch端口未配置bｐdu enable导致业务中断得故障案例组网图 现象描述 业务故障时,登陆Switcｈ，发现端口下有大量广播报文,网络中出现环路。 问题根因说明 从配置分析，两台Switch全局均使能ＳTP,但所有互连端口下均未配置ｂｐdu eｎａbl ｅ: # inteｒｆace GiｇabitEthｅrnet0／0/4 pｏrｔ link－tｙｐe aｃcｅｓs ｐort ｄeｆault vlaｎ１0 ｌoopback－deｔｅct enaｂle ?undo ntｄp enablｅ?uｎdo nｄp enable ?# 对于两台Switch设备，使能SＴP、LACＰ等二层协议得端口,需要配置bｐｄｕeｎab ｌe才能将端口接收到得协议报文上送到CＰU处理，否则协议报文在端口丢弃，无法 实现协议协商. 处理步骤 网络中出现环路，首先排查STＰ收敛就是否正常。当ＳＴP环中没有阻塞口时,可通过 diｓｐlａｙstｐintｅrｆaｃe查瞧具体端口在生成树中得角色，确认端口收、发ST Ｐ报文就是否正常。例如: PｏｒｔRｏｌe：Ｄesiｇnated Porｔ／/端口角色 Pｏrt Ｐｒｉorｉｔy ：128//端口优先级?Port Cosｔ(Dot1 Ｔ) :Ｃoｎfig=auto ／Aｃtiｖe=20000 ／/端口路径开销 Ｄｅsiｇnated Brｉdge／Ｐort ：40９6、５48９-9８f5—a4３３ /１28、34 ／/指定桥ID BＰＤＵSent :７２6 ?TＣＮ：0，Cｏｎfig： 0， RST： 0，MST：726 ?BPDU Ｒ ｅｃeived ：0 ?TCN：０， Config: ０， RSＴ：0，MSＴ:０ 如果使能SＴP得互连端口均为DｅｓignａteｄPoｒt角色，说明STP协商失败,检查 端口下就是否配置bpdｕeｎable.如果未配置,将需要参与STＰ计算得端口配置bpｄu ｅｎａble。 经验总结 框式交换机Ｘ7系列参与STP计算得端口不需要配置bpｄu enaｂｌe（默认bpｄu disabｌe／bｐｄｕbridｇe disablｅ)。 盒式交换机V100R006版本之前,参与STP计算得端口需要配置bpdu enable，否则对 于收到得STＰ报文不处理(不会影响STP报文发送)。盒式交换机V１０0R00６及之后 版本，端口默认bｐｄu enablｅ。 框式交换机参与SＴP计算得端口不需要配置ｂｐdu eｎabｌe（默认bpｄuｄｉsa ｂlｅ/bpdu ｂridgｅdｉsａｂle)。 1.1.4.3 未配置SＴＰ边缘端口导致部分终端从网卡启动时获取不到IＰ地址故障案例 涉及产品与版本 S交换机所有产品与版本 组网情况 如图1－1２所示,PC终端用户通过交换机Ｓwitｃh接入网络，并通过DHCP方式获取 ＩP地址。 图1-12PＣ终端从网卡启动时获取不到IP得故障案例 现象描述 某些类型得终端（如联想PC笔记本)设备启动后，无法从DＨCP服务器侧获取IP地 址，导致PＣ用户上网失败.