Brocade交换机PortErrShow命令er_bad_os各输出项释义
今天碰到一例给虚拟机分完共享磁盘后，用户反映虚拟机挂载共享磁盘速度比较慢的问题。SAN交换机是brocade的ds5300（FOS 6.4.2a），排除了阵列、交换机配置、SFP模块和光纤线等的问题后，排查发现交换机上连主机的端口的er_bad_os计数器一直在持续增大，甚至会溢出后重新从0开始计数。在网上查询后，通过修改fillword的为mode3后，er_bad_os错误停止。
以下是网上搜到的信息：
Brocade交换机上很多端口显示状态异常，通常怎样做初步的故障排查呢？答案是通过porterrshow的输出结果初步了解端口报错。
但在此之前，还有一项非常重要的内容需要检查，那就是计数器的有效性。什么是计数器的有效性？
举个简单的例子，倘若故障发生点为2015年12月12日，但是交换机上计数器的最后一次清空时间为2014年12月12日，那么该计数器便是无效的，因为该值为累计值，整一年的时间，沧海桑田，今非昔比，大量的历史累积值对当前的故障排查是没有帮助的。
那么是不是说清空计数器的时间点距离故障发生时间点越近越好？非也。若是客户在2015年12月11日清空过计数器，可是之后客户为了排查故障又执行过其它操作，如重启相关主机/重置交换机端口/更换光纤模块/光纤线等，那么该计数器也是无效的。因为此时我们看到的porterrshow输出结果中除包含故障报错增长外，还包含外界操作带来的计数器增长。
另外一种情况是在发生故障之后，计数器被清空了，若是此时的清空计数器行为是为了监测之后的故障重现，这一定是高级工程师会执行的操作，更有经验的工程师会建议先收日志再清计数器然后监测故障。若是在2015年12月12日故障发生后清空了计数器，再之后收集了日志交给工程师调查初始故障发生原因，那工程师只能含怨问苍天了。
当计数器有效时，porterrshow的输出结果才有了意义。
通常porterrshow输出内容如下：
DS_5300B_1:admin> porterrshowframes enc crc crc too too bad enc disc link loss loss frjt fbsy
tx rx in err g_eof shrt long eof out c3 fail sync sig
=========================================================================================================
0: 72.6m 712.0m 0 0 0 0 0 0 0 0 0 0 0 0 0
1: 72.8m 209.5m 0 0 0 0 0 0 0 0 0 0 0 0 0
2: 4.7m 874.0k 0 0 0 0 0 0 0 0 0 0 0 0 0
3: 546.9k 335.2k 0 0 0 0 0 0 0 0 0 0 0 0 0
4: 856.1k 488.8k 0 0 0 0 0 0 0 0 0 0 0 0 0
5: 704.7k 412.6k 0 0 0 0 0 0 0 0 0 0 0 0 0
6: 72.6m 712.1m 0 0 0 0 0 0 0 0 0 0 0 0 0
7: 72.8m 209.4m 0 0 0 0 0 0 0 0 0 0 0 0 0
8: 17.9m 12.2m 0 0 0 0 0 0 238 0 0 1 0 0 0
接下来我们解释一下各项指标代表的含义，以及我们在看到该项指标时都在关注些什么。
frames tx/rx: tx代表端口发送的数据帧，rx代表端口收到的数据帧。这两个值反映了通过该端口的数据流量，通常可用来粗略判断哪些端口为使用中，哪些端口为闲置状态。
enc_in: 8bit/10bit数据帧帧内的编码错误。数据的损坏会造成该值增长，因此该项指标用于标记数据帧内的编码错误。有时相连末端设备重置/重启也会造成该值增长。
crc_err: 数据帧 CRC 校验错误。数据帧在Payload之后，在EOF (end of frame)之前会添加一个可用于接收端口校验所接收数据是否损坏的校验码。若数据帧损坏，接收端会发现该值不一致，继而该报错值增长。
crc_g_eof: 数据帧 CRC 校验错误，且数据帧 EOF是好的。当数据帧首次被交换机检测到CRC错误时，交换机在转发该帧时，会把EOF置为bad(EOFni)；所以后续接收该帧的交换机的端口上，只会有crc_err增长，而crc_g_eof的值保持不变，这样就能很直观的找到产生CRC错误的源头。
too_long: 通常FC数据帧最大为 2148 字节。若EOF损坏或数据帧生成不正确，则该值随之增长。
too_short: 如果在SOF (start of frame) 和EOF间的长度小于28(24 Header+ 4 CRC)个字节，则该值随之增长。数据发送方故障和链路的不稳定均可能造成该计数器的增长。
bad_eof: 数据帧 EOF 报错。
enc_out: 8bit/10bit 数据帧帧外编码错误造成的错误值累积，通常反映了线缆质量问题，或末端设备异常。此外，由于末端设备的重启带来的端口上下线也可能会引起enc_out的增长。
disc c3: Class 3数据帧被交换机丢弃。若目标地址不可达或者源端口还没有登录到交换机，以及由于拥塞产生超时丢帧(timeout discards)后，该值均会增长。这个参数仅仅代表有丢包发生，但不能说是这个端口本身存在故障。
在Brocade Fabric OS微码版本v6.3.1之前，c3 timeout discards值是不分方向的，v6.3.1之后被分为er_rx_c3_timeout和er_tx_c3_timeout两项，rx表示接收数据，tx表示发送数据。当端口发送或者接收帧之后，会消耗掉相应的方向上的缓存，Buffer-to-Buffer credit值减少。如果超过500毫秒（默认情况下，依配置不同可能会有改变）credit值始终为0，则认为后续分发动作无法完成，丢弃尚在缓存中的帧，计数器值增加。有大量er_tx_c3_timeout数值累积的F_Port通常为性能问题的故障点，也就是我们常说的瓶颈设备。关于瓶颈设备的检查，请参照之前的Blog“如何在博科交换机的SAN环境中排查瓶颈设备（Slow Drain Device）？”：https://community.emc.com/community/support/chinese/storagehw/blog
link fail: 当交换机端口在 LR (Link Reset)接收状态的时间超过 R_A_TOV值时，该错误计数器增长。Link Reset的超时通常会导致Link Failure，且该状态通常说明端口loss of signal 或loss of sync的时长大于R_A_TOV。
loss sync: bit 或者 transmission-word无法被准确区分确认时会引起信号同步失败。末端设备的重启，光纤线的拔插，或交换机端口的上下线均可能带来该问题。
loss sig: 接收方没有成功收到信号。与loss sync类似，末端设备的重启，光纤线的拔插，或交换机端口的上下线都有可能信号的丢失。
link fail, loss sync, loss sig这三个报错在链路初始化的过程中都会产生。而当链路不稳定时，这些错误计数值通常也会随之增长。
frjt: class 2数据帧无法处理时会返回F_RJT报错。
fbsy: class 2数据帧无法在E_D_TOV时间内处理时会被丢弃并返回F_BSY报错。
frjt和fbsy用于 class 2。通常说来，FC SAN多用class 3数据帧，因此这两类错误较少见，一般多出现在FICON环境中。
porterrshow的输出结果能够使我们对当前网络中的所有端口报错有一个全局性的了解，当遇到具体问题时，还需查看日志中的其它输出以定位故障点。
#############
# 扩展：er_bad_os #
#############
在Brocade交换机中，另外一种常见的问题是不正确的填充字(fillword)配置。当该值设置有悖于最佳实践时，我们用portstatsshow命令可以在端口上观察到大量的er_bad_os。
对于8G及以上速率的FC链路，为了减少电磁干扰，T11协议组织在FC-PI-4和FC-FS-3 标准里规定了应用arb(ff)信号作为填充字。当末端设备以F_Port/8G速率连入Brocade 8G平台(Condor 2或GoldenEye2 ASIC)时，在交换机上需对fillword模式做修改。
Brocade交换机的fillword配置方式为以下4种(8G平台，Fabric OS 6.3及后续版本)：
0 | -idle-idle （默认）
使用idle信号作为端口初始化信号，使用idle作为端口填充字
1 | -arbff-arbff
使用arb(ff)信号作为端口初始化信号，使用arb(ff)作为端口填充字
2 | -idle-arbff
使用idle信号作为端口初始化信号，使用arb(ff)作为端口填充字
3 | -aa-then-ia
先尝试模式1再尝试模式2
EMC的最佳实践是将fillword模式设置为3，此模式下交换机首先会尝试先用arb(ff)信号作为端口初始化信号，并使用arb(ff)作为端口填充字；若此法不通，则尝试用idle信号作为端口初始化信号，并使用arb(ff)作为端口填充字。
这里面提到了SAN交换机端口的一个参数fillword。大体了解一下这个参数，也不知道理解的是否正确。
Fill-Word是一种primitive signal，用于在两个端口间传输状态消息，在端口没有用户数据传输的时候，端口就会发送fillword，用来保持端口间的位和字同步。
Fillwords主要有三种，分别为IDLE、ARB（F0）和ARB（FF）。
在1G/2G/4G标准中，链接初始化和发送fillword，Brocade SAN交换机都用IDLE primitive signal。随着端口速率升级到8Gbps，时钟速度的增加，这种IDLE的模式会造成高消耗，影响了端口的链接问题。为了解决这个问题，在FC-PI-4和FC-FS-3标准中使用了ARB（FF）这种模式作为8G FC的fillword。
但是可惜的是，有些8Gbps的设备在ARB/ARB或IDLE/ARB模式下不能与8G FC交换机建立起正常的链接，因此存储厂商和交换机厂商都有针对性的建议。
IBM针对这种情况给了类似的一些tips
http://www-947.ibm.com/support/entry/portal/docdisplay?brand=5000028&lndocid=MIGR-5083089
http://www-01.ibm.com/support/docview.wss?rs=591&uid=ssg1S1003699
HP也有这方面的说明：
Brocade公司也有类似的文档，例如 FOS 8G Link Init Fillword Behavior v1.pdf
总结这些内容如下：
1. 在Brocade SAN交换机FOS版本为6.2.x的时候，使用IDLE也就是mode 0。
查看当前端口的工作模式，假设查看端口14，portCfgShow <PortNumber>
>portcfgshow 14
Area Number: 14
Speed Level: AUTO(HW)
Fill Word: 1(Arbff-Arbff)
修改为mode 0，portCfgFillWord <PortNumber> <Mode>
>portcfgfillword 14 0
portcfgshow 14
Area Number: 14
Speed Level: AUTO(HW)
Fill Word: 0(Idle-Idle)
2. 在FOS版本6.3.1或以上时，Brocade提供了4种fillword模式，如下：
|
MODE |
MEANING |
|
Mode 0 |
Use IDLE in link init and IDLE as fill word |
|
Mode 1 |
Use ARB in link init and ARB as fill word |
|
Mode 2 |
Use IDLE in link init and ARB as fill word |
|
Mode 3 |
Try mode 1 first; if it fails then try mode 2 |
在8Gbps接口的时候，选择使用Mode 3是合理的一个参数，至少Brocade是这么建议的，这种模式更灵活能够适应大部分环境，与大量设备相兼容，如果还是有问题，那就需要联系存储厂商了。
> portcfgshow 14
Area Number: 14
Speed Level: AUTO(HW)
Fill Word: 3(A-A then SW I-A)
需要注意的是，该参数的修改都会引起端口通讯中断，所以要注意安全哦。
参考：
http://www.aixchina.net/home/space.php?uid=39199&do=blog&id=32107
http://bbs.watchstor.com/thread-235731-1-2.html