所以这里是场景，我希望@ Chopper3可以在这里挂钟。 对于我们的SAN光纤networking，我们有一对Cisco MDS 9513 FC交换机，带有三个EMC框架和四个直接连接的Cisco UCS域。
我们看到的行为是由于结构互连传输FCoE暂停帧，结果刀片上的CNA正在发送FC中止。 思科TAC解释了这种行为是上行拥塞或延迟的结果。 在环境中，我们发现200个左右的ESXi服务器的数据中有相应的高峰，报告延迟峰值从100ms到2000ms。 有些框架和path看起来比其他框架和path难一些，这使我相信我们正在热点一个或多个链接。
刀片是B200M2，B200M3和B420M3服务器，使用。 M2系列使用M81KR的“Palo”适配器，M3系列使用VIC1240适配器。
由于我对FC的知识渊博程度不够，所以对于如何打倒这个问题我会很感激。
所以这里是这个故事：
我从错误的angular度看待它。 适配器中止正常的症状，指示某个组件没有跟上。 在这种情况下，适配器中止是SAN前端端口太忙而无法处理请求的一个症状。 这是由几个不同的条件复合。
1）错误的驱动程序 – 我们的UCS固件级别规定ESXi中的匹配驱动程序具有已知问题，从中止中恢复，并将其发送到只能通过重新启动清除的循环中。
2）variables太多 – 三个SAN，有三个不同的问题，都被适配器中止代表。
3）SAN错误 – 由于我们的EMC VNX代码中的错误导致问题，我们必须禁用VAAI。
2015年编辑：
我想更新这个主题，因为很多新的信息也被揭示出来，而且检测很好，很难。 我希望这篇文章能够引导一些人朝正确的方向发展。
1）以上所有内容实际上仍然是相关的，尽可能快地将所有这些平方排列在一个支持matrix中。
2）一些UCS 2.1版本意外closures（尽pipeNXOS仍然被configuration为这样做）优先级stream量控制，这会导致一些FCoEstream量像其余的一样被处理，因此有时会出现乱序的FC帧。
3）在UCS 2.1代码中间的某个地方，一个IO节stream设置从一个装饰字段变成了一个活动字段。 旧的“烧入”固件设置是一个256个IO控制器，尽pipeWindows驱动程序确实允许您调整所有主机， 在这段代码中间的某处，用于将“256”安装到硬件中的原始默认值“16”变成无效设置，并且UCSM代码开始将其解释为最大值“2048”。 结果是，一个单一的UCS VIC适配器被configuration为绝对MURDER我们的存储arrays。
所以，请阅读您的发行说明。 经验教训，我们终于得到了修正。
IO节stream孔错误： https ： //tools.cisco.com/quickview/bug/CSCum10869
PFC错误： https ： //tools.cisco.com/quickview/bug/CSCus61659