常见问题 本节主要讨论常见的在存储和IP /二层网络的问题。
帧和数据包丢失 帧和数据包丢失是最常见的影响性能的因素，接口层次是最常见的发现问题症状的地方。从Nexus 5000系列或UCS的Nexus操作系统（NX-OS）的CLI，输入show interface | sec "is up" | egrep ^(Eth|fc)|discard|drop|CRC命令。如果接口是打开的，它会列出名字，丢弃计数器和丢包。同样，当你输入show interface counters error命令，它会显示所有接口的错误统计。
以太网领域
我们要知道计数器非0可能不是一个问题。在某些情况下，这些计数器可能在初始安装时或者在之前的操作中被改变。我们应该监控计数器的增加。 我们也能从ASIC层次收集计数器信息，并且可能获得更多的参考。具体而言，对于接口上的循环冗余校验（CRC）错误，TAC工程师经常使用show hardware internal carmel crc命令，其中Carmel是该负责端口级转发的ASIC的名称。我们也可以从6100系列FIs或Nexus 5600交换机上的每个端口看到类似的输出。对于FI 6100，Gatos ASIC，输入以下命令：
show hardware internal gatos port ethernet X/Y | grep
"OVERSIZE|TOOLONG|DISCARD|UNDERSIZE|FRAGMENT|T_CRC|ERR|JABBER|PAUSE"
对于Nexus 5600，bigsur ASIC，输入以下命令：
show hardware internal bigsur port eth x/y | egrep
"OVERSIZE|TOOLONG|DISCARD|UNDERSIZE|FRAGMENT|T_CRC|ERR|JABBER|PAUSE"
对于Carmel ASIC的命令显示了CRC数据包已经被接受，被转发到哪里，和是否被stomp处理过。
由于Nexus 5000系列和UCS NX-OS操作系统都是直通式的，带有不正确的帧校验序列（FCS）的交换模式帧只在转发之前被stomp处理。我们主要需要找到被损坏的帧来哪里。
bdsol-6248-06-A(nxos)# show hardware internal carmel crc
+----------+------------+------------+------------+------------+------------+------------+------------+
| Port | MM rx CRC | MM Rx Stomp| FI rx CRC | FI Rx Stomp| FI tx CRC | FI tx Stomp| MM tx CRC |
+----------+------------+------------+------------+------------+------------+------------+------------+
(....)
| Eth 1/17 | --- | --- | --- | 908100 | --- | --- | --- |
| Eth 1/18 | --- | --- | --- | 298658 | --- | --- | --- |
(....)
| Eth 1/34 | --- | --- | --- | --- | --- | 1206758 | 1206758 |bdsol-6248-06-A(nxos)# show hardware internal carmel crc
这个例子显示了stomp过的数据包来自的Eth 1/17和Eth 1/18，它们是到Nexus 5000的上行链路。可以假设那些发送到Eth 1/34的帧延迟到达，例如Eth 1/17 + Eth 1/18 rx Stomp = Eth 1/34 tx Stomp。
类似在Nexus 5000系列上可见：
bdsol-n5548-05# show hardware internal carmel crc
+----------+------------+------------+------------+------------+------------+------------+------------+
| Port | MM rx CRC | MM Rx Stomp| FI rx CRC | FI Rx Stomp| FI tx CRC | FI tx Stomp| MM tx CRC |
+----------+------------+------------+------------+------------+------------+------------+------------+
(....)
| Eth 1/14 | 13 | --- | --- | 13 | --- | --- | --- |
(.....)
| Eth 1/19 | 7578 | --- | --- | 7463 | --- | --- | --- |

此输出显示了从两个链路上接收到的CRC在转发前被标记为stomp。欲了解更多信息，请参阅Nexus 5000 Troubleshooting Guide。
光纤信道领域 可以通过show interface counters fc命令来寻找丢包（丢弃，错误，CRCs，B2B信任耗尽）。
此命令可以在Nexus 5000和FI上使用，为光纤信道领域提供了一个很好的参考。
例如：
bdsol-n5548-05# show interface counters fc | i fc|disc|error|B2B|rate|put
fc2/16
1 minute input rate 72648 bits/sec, 9081 bytes/sec, 6 frames/sec
1 minute output rate 74624 bits/sec, 9328 bytes/sec, 5 frames/sec
96879643 frames input, 155712103332 bytes
0 discards, 0 errors, 0 CRC
113265534 frames output, 201553309480 bytes
0 discards, 0 errors
0 input OLS, 1 LRR, 0 NOS, 0 loop inits
1 output OLS, 2 LRR, 0 NOS, 0 loop inits
0 transmit B2B credit transitions from zero
0 receive B2B credit transitions from zero
16 receive B2B credit remaining
32 transmit B2B credit remaining
0 low priority transmit B2B credit remaining
(...)此接口不繁忙时，输出显示无丢弃、无错误。
此外，B2B信任从0的转变是显著的；由于缺陷CSCue80063，这些计数器不能被信任。它们在思科MDS上工作的很好，但是在Nexus5k平台的UCS上不能工作。您也可以通过Cisco Bug ID CSCsz95889验证。 同样，Carmel在以太网领域对于光纤通道（FC）FC-MAC设备都可以使用。作为一个例子，对于端口FC2 / 1，输入show hardware internal fc-mac 2 port 1 statistics命令。计数器被表示为十六进制。
bdsol-6248-06-A(nxos)# show interface fc1/32 | i disc
15 discards, 0 errors
0 discards, 0 errors
bdsol-6248-06-A(nxos)# show hardware internal fc-mac 1 port 32 statistics
ADDRESS STAT COUNT
__________ ________ __________________
0x0000003d FCP_CNTR_MAC_RX_BAD_WORDS_FROM_DECODER 0x70
0x00000042 FCP_CNTR_MAC_CREDIT_IG_XG_MUX_SEND_RRDY_REQ 0x1e4f1026
0x00000043 FCP_CNTR_MAC_CREDIT_EG_DEC_RRDY 0x66cafd1
0x00000061 FCP_CNTR_MAC_DATA_RX_CLASS3_FRAMES 0x1e4f1026
0x00000069 FCP_CNTR_MAC_DATA_RX_CLASS3_WORDS 0xe80946c708
0x000d834c FCP_CNTR_PIF_RX_DROP 0xf
0x00000065 FCP_CNTR_MAC_DATA_TX_CLASS3_FRAMES 0x66cafd1
0x0000006d FCP_CNTR_MAC_DATA_TX_CLASS3_WORDS 0x2b0fae9588
0xffffffff FCP_CNTR_OLS_IN 0x1
0xffffffff FCP_CNTR_LRR_IN 0x1
0xffffffff FCP_CNTR_OLS_OUT 0x1 该输出显示了在输入时有15个包被丢弃。这可以匹配到FCP_CNTR_PIF_RX_DROP的count值为0xF（十进制为15）。该信息可再次关联到FWM（转发管理器）的信息。
bdsol-6248-06-A(nxos)# show platform fwm info pif fc 1/32 verbose | i drop|discard|asic
fc1/32 pd: slot 0 logical port num 31 slot_asic_num 3 global_asic_num 3 fwm_inst 7
fc 0
fc1/32 pd: tx stats: bytes 191196731188 frames 107908990 discard 0 drop 0
fc1/32 pd: rx stats: bytes 998251154572 frames 509332733 discard 0 drop 15
fc1/32 pd fcoe: tx stats: bytes 191196731188 frames 107908990 discard 0 drop 0
fc1/32 pd fcoe: rx stats: bytes 998251154572 frames 509332733 discard 0 drop 15bdsol-6248-06-A(nxos)# show platform fwm info pif fc 1/32 verbose | i drop|discard|asic
然而，这些告诉了管理员丢包数量和它相应的ASIC号。这就找到了需要查询的ASIC丢包的原因。
bdsol-6248-06-A(nxos)# show platform fwm info asic-errors 3
Printing non zero Carmel error registers:
DROP_SHOULD_HAVE_INT_MULTICAST: res0 = 25 res1 = 0 [36]
DROP_INGRESS_ACL: res0 = 15 res1 = 0 [46] 在这种情况下，流量通过入口访问控制列表（ACL）而被丢弃，典型地在FC领域-分区。
MTU不匹配 在FlexPod环境中，一些应用和协议经常需要设置能够容纳端到端的最大传输单元（MTU），在大多数环境下，是基于以太网的光纤通道（FCoE）和巨型帧。 此外，存储碎片也会导致性能下降。例如对于网络文件系统（NFS）协议和互联网小型计算机系统接口（iSCSI）协议，测试端到端的IP最大传输单元（MTU）和TCP最大分段大小（MSS）是非常重要的。
无论你是疑难排查巨型帧还是FCoE，务必要记住这两个都需要统一的配置和服务等级（CoS），以确保在整个环境下正确操作。 在UCS和Nexus上，show queuing interface | i queuing|qos-group|MTU命令能够有效的验证每个接口和每个服务质量组的MTU设置。Nexus 5000和UCS 平台的MTU显示 UCS和Nexus在接口上的MTU值是可测的。下面的输出展示了一个配置巨型帧和FCoE队列的接口：
bdsol-6248-06-A(nxos)# show queuing interface e1/1 | i MTU
q-size: 360640, HW MTU: 9126 (9126 configured)
q-size: 79360, HW MTU: 2158 (2158 configured)
与此同时，show interface命令显示了1500字节：
bdsol-6248-06-A(nxos)# show int e1/1 | i MTU
MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec 如果比较Carmel ASIC信息，ASIC显示给定端口的MTU容量。
show hardware internal carmel port ethernet 1/1 | egrep -i MTU
mtu : 9260
此MTU不匹配的显示将出现在上述平台上，并有可能误导新手。
端到端的配置
端到端的一致配置是保证特有性能的唯一途径。思科这边巨型帧，以及VMware ESXi的配置和步骤，可参考UCS with VMware ESXi End-to-End Jumbo MTU Configuration Example。
UCS FCoE Uplink Configuration Example显示了UCS和Nexus 5000的配置。请参阅参考文献附录A中，对于一个基本的Nexus 5000配置概述。
Set up FCoE Connectivity for a Cisco UCS Blade着重介绍了对FCoE的UCS配置。 Nexus 5000 NPIV FCoE with FCoE NPV Attached UCS Configuration Example重点介绍了Nexus配置。
测试端到端的巨型帧 大多数现代的操作系统都可以通过简单的Internet控制消息协议（ICMP）测试巨型帧配置。
计算9000字节 - 不带选项字段（20字节）的IP报头 - ICMP报头（8字节）= 8972字节的数据
在流行的操作系统下的命令Linuxping a.b.c.d -M do -s 8972
微软的Windowsping -f -l 8972 a.b.c.d
ESXivmkping -d -s 8972 a.b.c.d
缓冲区相关问题 缓冲和其他延迟相关的问题都属于在FlexPod的环境下常见性能下降的原因。不是所有报出的延迟问题都源于实际的缓冲延迟问题。相当多的测量可能指示是端到端的延迟。例如，在NFS情况下，所报告的时间周期可能需要成功地读出/写入到存储和非实际的网络延迟。
拥塞是缓冲最常见的原因。在第2层的领域，堵塞可能会导致缓冲，甚至是帧尾丢弃。为了避免在拥塞时丢包，IEEE 802.3X对暂停帧和优先级流量控制（PFC）进行了介绍。两者都依赖于要求终点在短周期内持续拥塞持有变速器。这可以归因于网络拥塞（接受极大量的数据），或者因为需要传递一个优先帧，如在对FCoE的情况。
流控制 - 802.3X 为了验证该接口是否启用了流控制，输入show interface flowcontrol命令。必须遵循存储供应商关于流控制启用的建议。 802.3x流控制的工作方式如下图所示。
PFC - 802.1Qbb
PFC不需要所有的设置，但建议大多数。为了验证该接口启用了PFC，可以通过在UCS的NX-OS和Nexus 5000上运行show interface priority-flow-control | i On命令。 FIs和Nexus 5000之间的接口应该在列表中可见。如果不能，则需要验证QoS配置。为了使用PFC，QoS配置要求端到端一致。为了检查为什么PFC在一个特定的接口上不来，可以输入show system internal dcbx log interface ethernet x/y命令来获得数据中心桥接能力交换协议（DCBX）日志。 带PFC的暂停帧工作原理如下所示。
show interface priority-flow-control命令，可以让管理员观察每个QoS类的优先暂停帧的行为。
下面是一个例子：
bdsol-6120-05-A(nxos)# show queuing interface ethernet 1/1 | i prio
Per-priority-pause status : Rx (Inactive), Tx (Inactive)
Per-priority-pause status : Rx (Inactive), Tx (Active) 此输出显示了在第二类中，该设备只发送了（TX）PPP帧。 在这种情况下，Ethernet 1/1是面向IOM的端口和而不是全部端口启用PFC，它可能会处理用于FEX端口的PPP帧。
bdsol-6120-05-A(nxos)# show interface e1/1 priority-flow-control
============================================================
Port Mode Oper(VL bmap) RxPPP TxPPP
============================================================
Ethernet1/1 Auto Off 4885 3709920 在这种情况下，FEX接口都参与。
bdsol-6120-05-A(nxos)# show interface priority-flow-control | egrep .*\/.*\/
Ethernet1/1/1 Auto Off 0 0
Ethernet1/1/2 Auto Off 0 0
Ethernet1/1/3 Auto Off 0 0
Ethernet1/1/4 Auto Off 0 0
Ethernet1/1/5 Auto On (8) 8202210 15038419
Ethernet1/1/6 Auto On (8) 0 1073455
Ethernet1/1/7 Auto Off 0 0
Ethernet1/1/8 Auto On (8) 0 3956077
Ethernet1/1/9 Auto Off 0 0 所涉及的FEX端口可以通过show fex X detail检查，其中X是机箱号码。
bdsol-6120-05-A(nxos)# show fex 1 detail | section "Fex Port"
Fex Port State Fabric Port
Eth1/1/1 Down Eth1/1
Eth1/1/2 Down Eth1/2
Eth1/1/3 Down None
Eth1/1/4 Down None
Eth1/1/5 Up Eth1/1
Eth1/1/6 Up Eth1/2
Eth1/1/7 Down None
Eth1/1/8 Up Eth1/2
Eth1/1/9 Up Eth1/2 这些文档是关于暂停机制的更多信息。
队列丢弃
Nexus 5000系列和UCS的NX-OS由于在每个基础QOS组的排队，而进行入口丢弃持续跟踪。例如：
bdsol-6120-05-A(nxos)# show queuing interface
Ethernet1/1 queuing information:
TX Queuing
qos-group sched-type oper-bandwidth
0 WRR 50
1 WRR 50
RX Queuing
qos-group 0
q-size: 243200, HW MTU: 9280 (9216 configured)
drop-type: drop, xon: 0, xoff: 243200
Statistics:
Pkts received over the port : 31051574
Ucast pkts sent to the cross-bar : 30272680
Mcast pkts sent to the cross-bar : 778894
Ucast pkts received from the cross-bar : 27988565
Pkts sent to the port : 34600961
Pkts discarded on ingress : 0
Per-priority-pause status : Rx (Inactive), Tx (Active) 入口丢弃应只发生在其被配置为允许丢弃的队列。
入口排队丢弃可能由以下原因导致：
● 交换端口分析器（SPAN）/监测会议能够在一些接口启用（参见Cisco Bug ID CSCur25521）
● 从另一个接口背压，暂停帧通常被启用
● 流量踢到CPU
驱动问题
思科为UCS，ENIC和FNIC提供了两个操作系统驱动程序。 ENIC负责以太网连接，FNIC负责光纤通道和FCoE连接。ENIC和FNIC驱动在UCS interoperability matrix上有着详细说明。由错误的驱动程序导致的问题范围从数据包丢失和增加延迟到一个较长的启动过程或完全缺乏连通性。
适配器信息
思科提供的适配器可以提供一个良好的流量传递和丢包测量。这个例子说明了如何连接机箱X，服务器Y和适配器Z。
bdsol-6248-06-A# connect adapter X/Y/Z
adapter X/Y/Z # connect
No entry for terminal type "dumb";
using dumb terminal settings. 从这里，管理员可以登陆性能监控中心（MCP）设施。
adapter 1/2/1 (top):1# attach-mcp
No entry for terminal type "dumb";
using dumb terminal settings 该MCP工具允许您监视每个逻辑接口（LIF）的流量使用情况。
adapter 1/2/1 (mcp):1# vnic
(...)
---------------------------------------- --------- --------------------------
v n i c l i f v i f
id name type bb:dd.f state lif state uif ucsm idx vlan state
--- -------------- ------- ------- ----- --- ----- --- ----- ----- ---- -----
13 vnic_1 enet 06:00.0 UP 2 UP =>0 834 20 3709 UP
14 vnic_2 fc 07:00.0 UP 3 UP =>0 836 17 970 UP
机箱1，服务器1，和适配器1具有两个虚拟网络接口卡（VNICs），关联虚拟接口（虚拟以太网或虚拟光纤通道）834和836。LIF 2和LIF 3的检测统计如下所示：adapter 1/2/1 (mcp):3# lifstats 2
DELTA TOTAL DESCRIPTION
4 4 Tx unicast frames without error
53999 53999 Tx multicast frames without error
69489 69489 Tx broadcast frames without error
500 500 Tx unicast bytes without error
8361780 8361780 Tx multicast bytes without error
22309578 22309578 Tx broadcast bytes without error
2 2 Rx unicast frames without error
2791371 2791371 Rx multicast frames without error
4595548 4595548 Rx broadcast frames without error
188 188 Rx unicast bytes without error
260068999 260068999 Rx multicast bytes without error
514082967 514082967 Rx broadcast bytes without error
3668331 3668331 Rx frames len == 64
2485417 2485417 Rx frames 64 < len <= 127
655185 655185 Rx frames 128 <= len <= 255
434424 434424 Rx frames 256 <= len <= 511
143564 143564 Rx frames 512 <= len <= 1023
94.599bps Tx rate
2.631kbps Rx rate 需要注意的是UCS的管理员提供了total和delta栏目（两个lifstats后续执行之间）和当前每个LIF的负载流量，以及一些可能发生的错误信息。 前面的例子显示的接口没有任何错误，并且负载很小，下面的例子显示了一个不同的服务器。
adapter 4/4/1 (mcp):2# lifstats 2
DELTA TOTAL DESCRIPTION
127927993 127927993 Tx unicast frames without error
273955 273955 Tx multicast frames without error
122540 122540 Tx broadcast frames without error
50648286058 50648286058 Tx unicast bytes without error
40207322 40207322 Tx multicast bytes without error
13984837 13984837 Tx broadcast bytes without error
28008032 28008032 Tx TSO frames
262357491 262357491 Rx unicast frames without error
55256866 55256866 Rx multicast frames without error
51088959 51088959 Rx broadcast frames without error
286578757623 286578757623 Rx unicast bytes without error
4998435976 4998435976 Rx multicast bytes without error
7657961343 7657961343 Rx broadcast bytes without error
96 96 Rx rq drop pkts (no bufs or rq disabled)
136256 136256 Rx rq drop bytes (no bufs or rq disabled)
5245223 5245223 Rx frames len == 64
136998234 136998234 Rx frames 64 < len <= 127
9787080 9787080 Rx frames 128 <= len <= 255
14176908 14176908 Rx frames 256 <= len <= 511
11318174 11318174 Rx frames 512 <= len <= 1023
61181991 61181991 Rx frames 1024 <= len <= 1518
129995706 129995706 Rx frames len > 1518
136.241kbps Tx rate
784.185kbps Rx rate 以上信息显示，由于缺少缓存，或者缓存不可用，96个帧被适配器丢弃，此外，TCP分段卸载（TSO）片段正被处理。
逻辑报文流
下图显示了在FlexPod环境下的逻辑报文流的概述。
此图是一个帧通过FlexPod环境的分解图。图中没有任何复杂的模块，而且是通过一个简单的方式来存储需要被配置和验证的特定特征。
输入/输出模块
如逻辑报文流图中所示，输入/输出模块（IOM）是在所有经过UCS通信的中间部分。为了连接到机箱X的IOM，输入connect iom x命令。
以下有一些其他有用的命令：
● 拓扑信息 - show platform software [woodside|redwood] sts命令显示了从IOM获得的拓扑信息。
它显示了通向FIs的网络接口（NIS），在这种情况下，有八个NIS，其中四个是开启的。此外，它显示了通向机箱内特殊刀片的主机接口（HIS）。
● 通信量速率 - show platform software [woodside|redwood] rate命令是用于在拓扑和HI接口到刀片映射已知的情况下，检查通过HI接口的通信量速率。
● 流量损失 – 输入show platform software [woodside|redwood] loss命令。该命令可以归零损失计数器。它可以让你看到暂停帧和每个基础接口上的丢包。
由于底层的工作方式，所显示的计数器示只针对那两个命令执行后丢包了的接口。在这个例子中，你可以看到NI2接口收到82个暂停帧，其中有28个暂停帧被传输到连接到刀片3的HI23接口。
设计注意事项
FlexPod允许灵活的配置，以及存储和数据网络的设置。伴随着灵活性相应的也带来了更多的挑战。至关重要的是需要遵循最佳实践文档和思科验证设计（CVD）：
端口速率选择和链路聚合注意事项
TAC工程师经常遇见的一个问题就是链路的不恰当利用，工程师经常通过引用最佳实践文档而选择使用1Gbit以太网而不是10 Gbit以太网。然而单个流使用1个10Gbit链路比使用10个1Gbit链路做链路聚合的性能要好。因为单个流的流量可能超过1个1Gbit链路的最大流量。
为了找到用于Nexus或者FI的NX-OS负载均衡方法，输入show port-channel load-balance命令。管理员还可以找出是哪个接口被选为链路聚合报文或帧的出接口。一个简单的例子如下所示，一个帧在两台主机之间的VLAN49：
show port-channel load-balance forwarding-path interface port-channel 928 vlan 49
src-mac 70ca.9bce.ee24 dst-mac 8478.ac55.2fc2
Missing params will be substituted by 0's.
Load-balance Algorithm on switch: source-dest-ip
crc8_hash: 2 Outgoing port id: Ethernet1/27
Param(s) used to calculate load-balance:
dst-mac: 8478.ac55.2fc2
src-mac: 70ca.9bce.ee24存储布局
另一个考虑因素是存储的位置。FlexPod的设计决定了存储将被附加在Nexus交换机上。直接附加存储不符合CVD规定。但是如果最佳实践文档允许，直接附加存储的设计是支持的。同时，这些设计是不严格的FlexPod。
存储特定问题
前面讨论的问题常见于数据和存储网络。为完整起见，下面是特定到存储区域网络（SAN）的性能问题。弹性和多路径存储协议仍在增加。随着如非对称逻辑单元分配（ALUA）和多路径IO（MPIO）等技术的出现，管理员将有更多的灵活性和选择。
最优路径选择
这从技术上来说不是一个思科问题，而是因为这些选择被用到思科设备上。选择最佳路径是一个常见问题。一个现代化设备的特定模块（DSM）可呈现多个路径，并且需要选择一个最佳路径（S），根据某些标准实现灵活性和负载均衡。该截图显示了微软Windows上到达NetAPP DSM的四条可用路径和负载均衡选项。
推荐的设置应通过与存储供应商的讨论获得。这些设置可能会有一些性能问题。TAC可能会让你只通过矩阵A和矩阵B做一个典型的读写测试，这个测试会缩小性能问题排查范围。
VM和Hypervisor流量共享
这里只是针对计算部件，而不管是什么供应商。从一个虚拟机算点建立一个Hypervisor存储网络的简单方法就是创建两个主机总线适配器（HBA），并在这些两个接口上同时跑LUN流量和虚拟机（VM）存储流量。我们推荐分离启动LUN流量和虚拟机存储流量。这允许获得更好的性能，还允许这两种流量之间的逻辑分离。请参见“已知问题”一节的例子。
故障排除技巧
缩小问题
想要快速排除故障，必须缩小问题范围并提出正确的问题。 ● 哪些设备/应用/ VM（不）受到影响？ ● 哪个存储控制器（不）受到影响？ ● 哪些路径（不）受到影响？ ● 问题多久（不）出现一次？

• perfstat -一个非常有用的工具，典型地运行于NetApp技术支持人员。
  
• systat –提供一些关于文件编辑员有多繁忙和文件编辑员在干什么的信息。NetApp Support Library。
  

• CP ty栏目下大量的持续的：或者F
  
• HDD util栏目下持续大约20%
  

• VLAN标签
  
• VLAN中继
  
• 超大MTU
  
• IP散列
  
• 禁用流控制
  

• Cisco Bug ID CSCuj86736 –无缘线缆CRC错误可能增加。这个问题在Nexus5000不优化DFE时可能会发生。通过输入show hardware internal carmel eve命令来验证“Eye height”参数在100 mv以上。这在版本5.2(1)N1(7)和7.0(4)N1(1)上被修复。
  
• Cisco Bug ID CSCuo76425 – 和先前的bug类似，也存在于UCS-FI。在版本2.2（3a）上被修复。
  
• Cisco Bug ID CSCuo76425 –除了UCS-FI，和bugCSCuj86736的一样。
  
• Cisco Bug ID CSCup40056 –由和VM流量共享启动流量导致的时间问题，在Unified Computing System Virtual Machine Live Migration Fails with Virtual Fibre Channel Adapters上有描述。
  
• 减慢流失检测和避免-FC和FCoE经常受缓慢流失的影响。NX-OS 7.0(0)N1(1)版本引入了检测和避免方法。可以在 Cisco Nexus 5500 Series NX-OS Interfaces Configuration Guide和 Slow Drain Device Detection and Congestion Avoidance上获得更多特征。
  
• Cisco Bug IDCSCuj81245 –局限用于基于PALO、导致FC终止的卡(VIC1240和其他)。
  
• Cisco Bug ID CSCuh61202 –在更新到2.1(3)版本、 UCS固件FC中止后会有多个其他问题出现。
  
• Cisco Bug ID CSCtw91018 – 在单个、基于PALO的适配器上对VNICs的MTU设置組合能导致一些流量类的饿死。
  
• Cisco Bug ID CSCuq40256 –将导致PFC从FI下到服务器适配器的链接禁用，这将会导致多种问题，开始于光纤通道中断和无序帧在存储端被报告。存储断开连接和其他性能问题将会被报告。
  

• 拓扑图 – 包含端口号和线路速率，必须。
  
• UCSM技术支持 – Visual Guide to collect Tech Support files (B and C series)。
  
• UCS机箱技术支持，对于一个机箱的体验问题 – 参照前面的链接。
  
• Nexus 5000 技术支持和一些在UCS和NetApp之间的其他的网络设备 – Redirecting output of the show tech-support details command。
  
• 在两个FI上show queueing interface 命令的输出。
  

connect nxos A|B
show queuing interface | no-more
show interface priority-flow-control | no-more
show interface flowcontrol | no-more.

• 在ESXi平台上的主机驱动版本 – 输入这些命令：
  
  
  
  • vmkload_mod -s enic
    
  • vmkload_mod -s fnic
    
• Linux --
  

• Windows – 在设备管理器上检查驱动版本。一个Window 2012 R2 的例子显示了3个思科VIC以太网接口、4个VIC FCoE迷你接口（同样适用于光纤通道，不仅仅是FCoE）和fnic驱动2.4.0.8版本。