IBM Flex System EN4093在启动时和运行中把SFP+ trunk端口打入ERRDISABLE
两台Flex System机箱,各装一块EN4093R 10Gb Scalable Switch(选件49Y4270)作为网络模块。每次机箱断电事件之后,端口都会以error-disabled状态回来,运行过程中也会时不时掉进同样的状态,概率低一些。故障端口不总是同一批,这正是最让人头疼的地方。
环境:
- IBM Flex System EN4093 10Gb Scalable Switch,选件49Y4270
- 到核心的四端口上联trunk,IBM原厂光模块加一根后来加进去的DAC
- 一个拆分出去连接第二个机箱的QSFP+端口
- 我们这边跑MSTP,核心是另一个厂商的设备
启动之后端口列表显示:
port 5 ERRDISABLE reason: link flap detect threshold exceeded
port 17 ERRDISABLE reason: mismatched link capabilities
port 19 ERRDISABLE reason: mismatched link capabilities已经试过:
- 对受影响端口做shutdown/no shutdown,大多数能恢复,直到下一次事件发生
- 清洁并重插了trunk里的每一根光纤,现象没有变化
- 对比过对端端口配置,速率在纸面上是匹配的
到底是什么在把这些端口打进errdisable,有没有办法阻止它每次开机都发生,而不是每次都手动清一次?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
这台交换机有七种文档记载的会禁用端口的状态,彼此之间关系不大:
你遇到的是第四种,也是大多数人遇到的那种,因为这是你自己造成的:在同一条trunk里混用不同速率或类型的模块,交换机就会有意见。三个光模块旁边放一根DAC就足够了。把那根DAC拿出来,换成和另外三个匹配的模块。
对于卡在flap检测器上的那个端口,反弹它依然是文档记载的恢复方式:
之后回头检查那条链路上的生成树配置,把铜口和光口都手动过一遍。任何配置改动之后都跟一次reload,不然运行状态会悄悄和你以为设置的东西对不上。
有两件事不要指望。这七种状态里有两种,超时之后端口依然保持down,需要手动干预。也没有哪个固件版本能修复这个——厂商的说法是让你自己在配置上绕开它,所以每个trunk成员用完全相同的模块,加上干净的光纤,就是能做到的全部预防措施了。
同一份日志里出现两种不同的原因,我会先从这里入手。某个端口是不是每次都因为同一个原因恢复被禁用,还是说这次因为链路能力问题倒下的端口,下次会触发flap检测器?一个原因固定在某个端口上,和一个原因到处游走,这是两个完全不同的排查方向,而且只有其中一个最后会让你去买硬件。
第二件值得确认的事是核心那边跑的是什么生成树协议。你们用的是MSTP;如果对端往这些上联口上扔Cisco风格的PVST BPDU,这台交换机有一个保护机制会针对这个做出反应,把端口打下去,从外部看起来就正好是你现在追查的这个故障。你能不能判断,某些端口掉线的时间是不是正好和核心那边的拓扑变化对得上,而不是和你们自己的开机时间对得上?
按端口来看是一致的,但整台设备来看不是。那些倒下的trunk成员,每次恢复都是因为链路能力不匹配;端口5这个接入口,则永远只触发flap检测器,而且我找不出任何有规律的间隔。所以看起来确实是两个故障披着同一件外衣。
对端生成树的情况我现在还答不上来——核心属于另一个团队,我已经问他们那些上联口上实际发出的是什么。到目前为止我们的日志里没有任何一次掉线能和那边的拓扑变化对上,不过我当时看的是链路事件而不是专门为了这个去核对,所以我不会说这个可能性已经被排除了。
不同厂商,同样的模式。我们有一台FortiGate 201F通过SFP+挂在一台FortiSwitch 548D上,中间是Fortinet自家的DAC,这条10Gbps链路怎么都保持不住——不管怎么调速率和双工都会掉,把两端从FortiOS 7.4回退到7.2.5也没有任何变化。
最后稳定下来的是换了一根更短的Fortinet DAC,并且在那条链路上关掉了STP,从那以后就一直稳定运行。值得带走的是后来想明白的道理:无源铜缆越长,信号到达时衰减得越厉害,所以在10G速率下,任何偏长或处于临界值的DAC都该上嫌疑名单,不管上面印着什么牌子。三个光模块加一根DAC组成的errdisable trunk里,我会重点盯着那根格格不入的DAC。
在你动任何硬件之前,先做一件事:把抖动的确切节奏和日志时间戳对照着记下来。
在一台完全不相关的交换机TL-SG3452X上,每个插了模块的SFP+端口都会每隔十到十五分钟掉线再恢复,每次抖动日志里都伴随着STP消息,一开始显而易见的结论是光模块坏了——直到一根原厂的TL-SM5220-1M DAC也以完全相同的节奏抖动起来。这一个测试就打掉了光模块这个理论,转而指向固件回归;那边唯一管用的办法就是留在更老的版本上。
有规律的间隔说明有什么东西按某种周期在超时。随机的间隔说明是物理层面的问题。这是个成本很低的测试,能省下不少不必要的采购。留一份旧固件镜像备用,让回退始终是一个可行选项,也是值得的。