交换机端口假死

1、交换机端口假死用“重启”来应付“假死”现象蔓延不得不根治？拯救步骤1：查看日志/端口的状态拯救步骤2：将端口从错误状态中恢复回来拯救步骤3：显示被置于错误状态端口的恢复情况交换机端口假死 用“重启”来应付单位中有若干台cisco3550勺交换机，分别放在相应的网络中担当着骨干交换机的角色， 有一台用在单位上互联网的局域网中， 还有一台则用在单位的数字电视前端系统的局域网中。不知道大家有没有遇见过跟我一样的现象，即 cisco交换机上的某些正在工作的端口， 突然变成关闭状态了， 该端口上即使插着网线，端口上的指示灯仍然不亮 （这种故障往往是在下面所连接的网络出现故障的时侯出现） 。 以前这种情况

2、多出现在位于单位上互联网的那台交换机上， 当这种情况发生时， 为了迅速排除故障， 我们会先调整一个端口， 即将网线从有问题的端口上拨下来，再插到一个空闲的端口上，这时一般网络故障就排除了。而且时间一长我们发现， 那个处于关闭状态的端口并不是真正损坏了， 当我们重新启动一下交换机后， 那个端口又“复活”了。 由于那台上互联网的交换机还有一些空闲端口， 而且我们可以指定这台交换机在一个网络使用相对较少的时间重启（比如凌晨4 点），所以端口“假死”这个故障虽然存在，但由于我们一般可以通过重启交换机的方法解决，所以也就没有放在心上。“假死”现象蔓延不得不根治？但是最近几天单位那台连接数字电视前端系统的

3、交换机上也出现了端口“假死”的现象， 故障原因很快查清了： 是因为该端口下面连接的一台交换机出现了环路，这台ciscos换机上相应的端口就被系统自动关闭了，这种措势是必要的， 因为可以防止环路的扩散， 但是当下面的交换机环路故障解除后， 该端口并没有又恢复到正常工作状态，更要命的是：一、更换端口 ; 二、重启交换机都无法实现， 因为一来这台交换机上空闲端口很少了， 二来这台交换机需要始终处于工作状态， 如果一旦重新启动， 这几分钟的网络中断就会影响到数字电视的播出，所以是绝对不能重启的。出现了这个问题， 我们不得不重视起交换机端口“假死”的现象， 寻求在交换机不重启的状态下将该端口“拯救”回来

4、的方法。拯救步骤 1 ：查看日志/ 端口的状态登录进入交换机后，执行show log ，会看到如下的提示：21w6d: %ethcntr-3-loop_back_detected: keepalive packet loop-back detected on fastethernet0/20.21w6d: %pm-4-err_disablelo:opback error detected on fa0/20, putting fa0/20 in err-disable state以上信息就明确表示由于检测到第20端口出现了环路，所以将该端口置于了 err-disable 状态。查看端口的状态s

5、witch# show inter fa0/20 statusportnamestatusvlanduplex speed typefa0/20link to databackup err-disabled562auto auto 10/100basetx这条信息更加明确的表示了该端口处于 err-disabled 状态。既然看到了该端口是被置于了错误的状态了， 我们就应该有办法将其再恢复成正常的状态。拯救步骤 2 ：将端口从错误状态中恢复回来进入交换机全局配置模式，执行errdisable recovery cause ? ，会看到如下信息：switch(config)#errdisable

6、 recovery cause ?allenable timer to recover fromall causesenable timer to recover from bpdubpduguardguard error disable statechannel-misconfig misconfig disable statedhcp-rate-limitdhcp-rate-limit error disable state dtp-flapdtp-flap error disable state gbic-invalidgbic error disable stateenable tim

7、er to recover from channelenable timer to recover fromenable timer to recover fromenable timer to recover from invalidl2ptguardenabletimertol2protocol-tunnel error disable statelink-flapenabletimertolink-flap error disable stateloopbackenabletimertoloopback detected disable statepagp-flapenabletimer

8、topagp-flap error disable statepsecure-violationenable timer to recoverrecover fromrecover from recover fromrecover from from psecureviolation disable statesecurity-violation enable timer to recover from 802.1x violation disable stateudldenable timer to recover fromudldbpduguard security-violatio ch

9、annel-misconfig vmpspagp-flap dtp-flaplink-flap gbic-invalid l2ptguard psecure-violation gbic-invalid dhcp-rate-limit unicast-floodloopbackudld error disable stateunicast-floodenable timer to recover from unicastflood disable statevmpsenable timer to recover fromvmps shutdown error disable state从列出的

10、选项中， 我们可以看出， 有非常多的原因会引起端口被置于错误状态， 由于我们明确的知道这台交换机上的端口是由于环路问题而被置于错误状态的，所以就可以直接键入命令：switch(config)#errdisable recovery cause loopback是啊， 就这么简单的一条命令， 就把困挠我们很长时间的问题解决了， 真的 就这么神奇。那么如何验证这条命令是生效了呢？拯救步骤 3 ：显示被置于错误状态端口的恢复情况switch# show errdisable recoveryerrdisable reasontimer statusdisableddisableddisableddi

11、sableddisableddisableddisableddisableddisableddisableddisableddisableddisableddisabledenabledtimer interval: 300 secondsinterfaces that will be enabled at the next timeout:interfaceerrdisable reasontime left(sec)fa0/86loopback27fa0/17loopback267fa0/20loopback250从以上显示的信息可以看出， 这台交换机有三个端口 （fa0/8、fa0/17

12、、 fa0/20）会分别在276、 267、 250 秒之后恢复为正常的状态，实际情况也是这样，等了几分钟以后， 我们找了一台笔记本电脑， 分别接到这几个端口上试了一下， 端口都可以正常工作了。 这下总算在不重交换机的情况下， 将几个处于“假死”状态的端口“拯救”了回来。作为一名网络管理员， 除了日常网络故障的处理外， 还会不时碰到自己知识范围以外的东西， 但只要引起足够的重视， 总会找到解决问题的办法。 如果您在工作中也遇到交换机端口“假死”的情况，不妨用这个办法试一下。的交换机， 分别放在相应的网络中担当着骨干交换机的角色， 有一台用在单位上互联网的局域网中， 还有一台则用在单位的数字电视

13、前端系统的局域网中。 不知道大家有没有遇见过跟我一样的现象，即ciscos换机上的某些正在工作的端口，突然变成关闭状态了， 该端口上即使插着网线， 端口上的指示灯仍然不亮 （这种故障往往是在下面所连接的网络出现故障的时侯出现） 。 以前这种情况多出现在位于单位上互联网的那台交换机上， 当这种情况发生时， 为了迅速排除故障， 我们会先调整一个端口， 即将网线从有问题的端口上拨下来， 再插到一个空闲的端口上，这时一般网络故障就排除了。而且时间一长我们发现， 那个处于关闭状态的端口并不是真正损坏了， 当我们重新启动一下交换机后， 那个端口又“复活”了。 由于那台上互联网的交换机还有一些空闲端口， 而

14、且我们可以指定这台交换机在一个网络使用相对较少的时间重启（比如凌晨4 点），所以端口“假死”这个故障虽然存在，但由于我们一般可以通过重启交换机的方法解决，所以也就没有放在心上。“假死”现象蔓延不得不根治？但是最近几天单位那台连接数字电视前端系统的交换机上也出现了端口“假死”的现象， 故障原因很快查清了： 是因为该端口下面连接的一台交换机出现了环路，这台ciscos换机上相应的端口就被系统自动关闭了，这种措势是必要的， 因为可以防止环路的扩散， 但是当下面的交换机环路故障解除后， 该端口并没有又恢复到正常工作状态，更要命的是：一、更换端口 ; 二、重启交换机都无法实现， 因为一来这台交换机上空闲

15、端口很少了， 二来这台交换机需要始终处于工作状态， 如果一旦重新启动， 这几分钟的网络中断就会影响到数字电视的播出，所以是绝对不能重启的。出现了这个问题， 我们不得不重视起交换机端口“假死”的现象， 寻求在交换机不重启的状态下将该端口“拯救”回来的方法。拯救步骤 1 ：查看日志/ 端口的状态登录进入交换机后，执行show log ，会看到如下的提示：21w6d: %ethcntr-3-loop_back_detected: keepalive packet loop-backdetected on fastethernet0/20.21w6d: %pm-4-err_disablelo:opba

16、ck error detected on fa0/20, putting fa0/20 in err-disable state以上信息就明确表示由于检测到第20 端口出现了环路，所以将该端口置于了 err-disable 状态。查看端口的状态switch# show inter fa0/20 statusportnamestatusvlanduplex speed typefa0/20link to databackup err-disabled562auto auto 10/100basetx这条信息更加明确的表示了该端口处于 err-disabled 状态。既然看到了该端口是被置于了错误

17、的状态了， 我们就应该有办法将其再恢复成正常的状态。拯救步骤 2：将端口从错误状态中恢复回来进入交换机全局配置模式，执行errdisable recovery cause ? ，会看到如下信息：switch(config)#errdisable recovery cause ?causesallenable timer to recover from allbpduguard enable timer to recover from bpdu guard error disable statechannel-misconfig disable state dhcp-rate-limit err

18、or disable state dtp-flaperror disable stategbic-invalidenable timer to recover from channel misconfigenable timer to recover from dhcp-rate-limitenable timer to recover from dtp-flapenable timer to recover from invalid gbicerror disable staterecover fromrecover fromrecover fromrecover from from pse

19、curel2ptguardenable timertol2protocol-tunnel error disable statelink-flapenable timertolink-flap error disable stateloopbackenable timer toloopback detected disable statepagp-flapenable timer topagp-flap error disable statepsecure-violationenable timer to recoverviolation disable statesecurity-viola

20、tion enable timer to recover from 802.1x violation disable stateudldenable timer to recover fromudld error disable stateunicast-floodenable timer to recover from unicastflood disable statevmpsenable timer to recover fromvmps shutdown error disable state从列出的选项中， 我们可以看出， 有非常多的原因会引起端口被置于错误状态， 由于我们明确的知道这台交换机上的端口是由于环路问题而被置于错误状态的，所以就可以直接键入命令：switch(config)#errdisable recovery cause loopback是啊， 就这么简单的一条命令， 就把困挠我们很长时间的问题解决了， 真的 就这么神奇。那么如何验证这条命令是生效了呢？拯救步骤 3 ：显示被置于错误状态端口的恢复情况switch# show errdisable recoveryerrdisable reasontimer statusdisableddisableddisableddisab