某云计算中心核心为两台S10512做IRF2,接存储资源的汇聚交换机S5800通过两条万兆链路做链路聚合和S10512连接。当前发现下挂存储资源不定时无法被其他设备访问。现场查看,故障发生时S5800上TEN1/0/2接口下挂的服务器Server2死机,从S5800 PING S10512、从S5800 PING 下挂的部分服务器及存储,无法PING通,将TEN1/0/2的端口SHUT DOWN,所有业务恢复正常。后用户将该死机设备重启后,业务恢复正常。
收集故障发生后的诊断信息。
interface Ten-GigabitEthernet1/0/2
port link-mode bridge
port access vlan 3880
speed 10000
duplex full
flow-control
Ten-GigabitEthernet1/0/2 current state: UP
IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 7425-8ad8-7484
Description: Ten-GigabitEthernet1/0/2 Interface
Loopback is not set
Media type is optical fiber,Port hardware type is 10G_BASE_SR_SFP
10Gbps-speed mode, full-duplex mode
Link speed type is force link, link duplex type is force link
Flow-control is enabled
The Maximum Frame Length is 10000
Broadcast MAX-ratio: 100%
Unicast MAX-ratio: 100%
Multicast MAX-ratio: 100%
Allow jumbo frame to pass
PVID: 3880
Link delay is 0(sec)
Port link-type: access
Tagged VLAN ID : none
Untagged VLAN ID : 3880
Port priority: 0
Peak value of input: 11798276 bytes/sec, at 2000-04-26 12:08:37
Peak value of output: 12628909 bytes/sec, at 2000-04-28 00:25:07
Last 300 seconds input: 483 packets/sec 476244 bytes/sec 0%
Last 300 seconds output: 383 packets/sec 364907 bytes/sec 0%
Input (total): 448824528 packets, 452985151230 bytes
446929080 unicasts, 244 broadcasts, 34 multicasts, 1895170 pauses
Input (normal): 446929358 packets, - bytes
446929080 unicasts, 244 broadcasts, 34 multicasts, 1895170 pauses
Input: 0 input errors, 0 runts, 0 giants, 0 throttles
0 CRC, 0 frame, - overruns, 0 aborts
- ignored, - parity errors
Output (total): 552361011 packets, 672669008394 bytes
552072494 unicasts, 63534 broadcasts, 19706 multicasts, 205277 pauses
Output (normal): 552155734 packets, - bytes
552072494 unicasts, 63534 broadcasts, 19706 multicasts, 205277 pauses
Output: 0 output errors, - underruns, - buffer failures
0 aborts, 0 deferred, 0 collisions, 0 late collisions
0 lost carrier, - no carrier
发现当前端口下都开启了flow control配置,所有端口出方向均有pauses帧。除了上联S105的接口,其余端口入方向都有少量pause帧,1/0/2口入方向pause帧尤为多。怀疑现场的现象与流控有关。
配置flow-control命令后,当本端发生拥塞时,设备会向对端发送流量控制报文,告知对端本端已产生拥塞,不要再向本端发送报文;当本端收到对端的流量控制报文后,会停止报文发送。具体说来,当端口收到pause帧之后,这个端口短时间内停止向对端发送报文,这个时间参数携带在pause报文中。端口若连续收到多个pause帧势必导致缓冲区积压报文;进一步讲,如果有其他端口正往这个端口转发报文,那么这些端口入方向就会积压报文,报文积压至一定数量会触发端口向外发送PAUSE帧。对端设备收到pause帧后将停止向该端口发送报文,从而导致所有经过这些链路的流量都会中断。
因此推测该问题是TEN1/0/2下挂设备异常,持续发送pause帧所致。可通过如下步骤确认:
1、在网络正常时查看1/0/2口入方向pause帧的增长,和其他端口出方向pause帧增长情况
2、在问题复现时查看1/0/2口入方向pause帧的增长,和其他端口出方向pause帧增长情况,与正常情况对比;
3、在问题复现时关闭S5800上的流控,测试网络的连通性。
现常反馈进一步测试信息如下:
1、在服务器死机之前,查看各端口的PAUSE帧情况,TEN1/0/2端口的IN和OUT方向基本没有PAUSE帧,其它部分端口有,基本是在OUT方向,增长速度较慢,不定时增长;
2、服务器死机后,先清除接口计数,再查看PAUSE帧情况,在TEN1/0/2端口的IN方向有PAUSE帧,增长速度较快且匀速,其它端口的OUT方向有PAUSE帧,增长速度较快且匀速;在S5800上无法已PING通交换机下挂的部分服务器及上连的S10512;
3、将TEN1/0/2接口下的flow-control关闭,在S5800上能PING通交换机下挂的所有服务器及上连的S10512,将TEN1/0/2接口下的flow-control开启,故障现象重新复现。
至此可判断故障现象由服务器不定时死机,对外发送大量pause帧引起。
流控的应用一般多见于存储网络,流控一定程度上能够缓减网络拥塞,提高链路带宽的利用率。正常情况下也很少会遇到流控导致网络中多台设备不通的问题,因为pause携带的时间参数很短,网络流量也不会持续突发。像本例中服务器异常死机不断发送pause帧现象比较少见。根据这个案例可以提供一个排查网络不通的另一个排查点,若网络不通,接口下又有大量pause帧时,可根据流控原理,网络的互访关系排查下流控导致不通的可能性。
1、在交换机上关闭流控;
2、或者服务器侧能有机制避免设备出现异常,如检测异常立即重启;
3、建议不要上行口上开启流控,避免单台服务器异常,上行流量全部中断。
该案例暂时没有网友评论
✖
案例意见反馈
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作