Cisco MDS 交换机：主机在区域激活时丢失了 VPLEX 前端 (FE) 端口的路径
Podsumowanie: 在区域激活时，所有分区到 VPLEX 前端端口的 HBA 都将注销并丢失路径。ESX 主机可能会挂起，并且需要重新启动才能恢复。[Scott — 这是否仅影响 ESX 主机？摘要内容为“分区到 VPLEX 的所有 HBA”，我们是要将此限制为仅适用于 ESX 主机，还是重述为“主机可能会挂起，并且需要重新启动才能恢复”？] ...
Objawy
主机丢失路径。
[注 — Scott 也请参阅摘要中的注释]
ESX 主机挂起，并且需要重新启动才能恢复。[Scott — 它只是可能会挂起的 ESX 主机吗？摘要指出“分区到 VPLEX 的所有 HBA”]
从 ESXi“vmkernel”日志：
2020-08-30T03:52:23.501Z cpu187:66638)WARNING: lpfc: lpfc_els_unsol_buffer:8330: 0:(0):0115 Unknown ELS command x7f26e705 received from NPORT x1f04c0
2020-08-30T03:52:28.325Z cpu187:66638)WARNING: lpfc: lpfc_els_unsol_buffer:8330: 0:(0):0115 Unknown ELS command x7effc405 received from NPORT x1f04c0
从 VPLEX 固件日志：
事件 fc/4： “此端口已发现构造中所指示的端口离开。”
128.221.253.37/cpu0/log:5988:W/"006016abc83a153324-2":36008:<6>2020/08/30 03:39:07.65: fc/4 A0-FC02.0: port 200000109b59a55d:100000109b59a55d:330fc0
(spn Emulex PPN-10:00:00:10:9b:59:a5:5d) (snn Emulex LPe16002B-M6 FV12.2.299.27 DV12.2.373.1 HN:localhost OS:VMware ESXi 6.5.0) (speed <unsupported by fabric>) departed
128.221.253.37/cpu0/log:5988:W/"006016abc83a153324-2":36009:<4>2020/08/30 03:39:07.65: stdf/18 FCP connection lost. IT: [Host1_vmhba1 (0x100000109b59a55d)
A0-FC02 (0xc00144879a780200)][Scott — 返回到“分区到 VPLEX 的所有 HBA”的问题，如果此 cisco 问题影响分区到 VPLEX 的所有 HBA，那么我们是否应该在固件日志中显示其他主机离开的报告？我们是否看到其他主机与上面所示的 esx 主机一样离开？]
事件 fc/3：“此端口已发现构造中所指示的端口到达。”
128.221.253.37/cpu0/log:5988:W/"006016abc83a153324-2":36020:<6>2020/08/30 03:40:37.66: fc/3 A0-FC02.0: port 200000109b59a55d:100000109b59a55d:330fc0
(spn Emulex PPN-10:00:00:10:9b:59:a5:5d) (snn Emulex LPe16002B-M6 FV12.2.299.27 DV12.2.373.1 HN:localhost OS:VMware ESXi 6.5.0) (speed <unsupported by fabric>) arrived
128.221.253.37/cpu0/log:5988:W/"006016abc83a153324-2":36027:<4>2020/08/30 04:03:28.34: stdf/17 FCP connection established. IT: [Host1_vmhba1 (0x100000109b59a55d)
A0-FC02 (0xc00144879a780200)]
[Scott：我们是否有其他 HBA 的数据也已到达？]
更改：
区域激活。
区域更改不涉及 HBA 端口和 VPLEX 前端端口。
[Scott — 最后一句话没有意义，据我所知，问题是当 Cisco 交换机上的区域集激活时，所有 HBA 和 VPLEX 前端端口“均”被涉及。另外，这还会影响哪些 Cisco 交换机代码级别？]
Przyczyna
VPLEX 每 90 秒钟在所有光纤通道端口（前端、后端和 FC-WANCOM）上执行一次构造发现，并使用“Get all next”(GA_NXT) 名称服务器命令来执行此操作。除了从交换机接收 RSCN 或从分区 HBA 接收 PLOGI 之外，它将执行此操作。
由于 Cisco 错误 CSCvw75655 的缘故，当区域集激活/提交正在进行时，如果 VPLEX 在前端 (FE) 端口上执行其构造发现，则 VPLEX 有很小的机率会仅收到其自身的光纤通道地址 (FCID)，接着将会假设登录到它的任何 HBA 不再连接到该构造，并向每个分区到它的 HBA 发送注销 (PLOGO)。[Scott — VPLEX 和/或交换机日志是否显示此操作正在发生，是否显示正在发送 PLOGO，如果这可以在两个产品上看到，那么我们是否可以包含此示例，从哪些日志中可看到这方面内容呢？]
从交换机名称服务器接收到正确信息时，VPLEX 将在接下来的 90 秒构造发现中记录它注销的每个 HBA 的 fc/4 事件和 fc/3 事件。
HBA 如何处理此注销将取决于其驱动程序/固件。此示例中的 ESX 主机挂起并需要重新启动。[Scott — 我们是否有受此事件影响的其他主机的日志数据？如果有，我们是否还可以列出一些，以便看起来不像只有 ESX 主机受到影响？]
注：
定期执行构造发现，以确保 VPLEX 已更新构造数据，因为有可能并非所有 RSCN 均能够从构造到达 VPLEX。
Rozwiązanie
解决办法：
在 Cisco 交换机上，禁用名称服务器/区域服务器共享数据库 (db) 功能，如下所示：
注：区域集共享数据库功能只是名称服务器和区域服务器共享信息的一种效能。禁用该功能不会对环境产生负面影响。
Cisco 已确认该更改是本地更改（而非全局更改）。此命令应在连接了 VPLEX 的每个交换机上运行。[Scott — 是否有 Cisco KB 讨论过我们可在此 KBA 中引用的这个问题？]
修复：
NX-OS 8.4(2c)。此版本尚未由 Dell EMC 正式发布。
[Scott — 我们无法列出 Dell EMC 尚未提供的修复，一旦该修复可用，我们会重新发布此 KBA 以供审核，并删除句子“此版本尚未由 Dell EMC 正式发布”]
Dodatkowe informacje
产品 (1)
Cisco MDS 9000 NX-OS 和 SAN-OS 软件
已知受影响的版本
8.3(2)
VPLEX 构造发现
示例：
分区到单个 VPLEX FE 端口的主机 1、主机 2 和主机 3。
VPLEX FE 端口：FCID 0x200b20
主机 1：FCID 0x340000
主机 2：FCID 0x340020
主机 3：FCID 0x340040
正在工作...[Scott — 这是什么？这是从信息中获取/复制的吗？如果是，我们可以删除“正在工作...”信息]
- VPLEX 将向名称服务器发送“Get all next”命令，并且此命令还附带“0xffffff”（最高）的光纤通道地址 (FCID)
- 名称服务器将用 VPLEX FE 端口（最低）的详细信息进行回复
- VPLEX 将向名称服务器发送“Get all next”命令，并且此命令还附带 VPLEX FE 端口的光纤通道地址 (FCID)
- 名称服务器将用主机 1 的详细信息进行回复
- VPLEX 将向名称服务器发送“Get all next”命令，并且此命令还附带主机 1 的光纤通道地址 (FCID)
- 名称服务器将用主机 2 的详细信息进行回复
- VPLEX 将向名称服务器发送“Get all next”命令，并且此命令还附带主机 2 的光纤通道地址 (FCID)
- 名称服务器将用主机 3 的详细信息进行回复
- VPLEX 将向名称服务器发送“Get all next”命令，并且此命令还附带主机 3 的光纤通道地址 (FCID)
- 名称服务器将用 VPLEX FE 端口的详细信息进行回复
- VPLEX 停在此处，因为它已收到其自身已被发现（再次盘问）的光纤通道地址 (FCID)
Cisco 错误 CSCvw75655 ...
- VPLEX 将向名称服务器发送“Get all next”命令，并且此命令还附带“0xffffff”（最高）的光纤通道地址 (FCID)
- 名称服务器将用 VPLEX FE 端口（最低）的详细信息进行回复
- VPLEX 将向名称服务器发送“Get all next”命令，并且此命令还附带 VPLEX FE 端口的光纤通道地址 (FCID)
- 名称服务器将用 VPLEX FE 端口的详细信息进行回复
- VPLEX 停在此处，因为它已收到其自身已被发现（再次盘问）的光纤通道地址 (FCID)
有关已添加到 NX-OS 8.4(2c) 的错误 CSCvw75655 的修复的其他详细信息。
此错误起因的提醒信息：
当目标设备发出 FCNS GA_NXT 命令且仅获取其自己的 FCID（表明它没有与任何其他设备分区）时，就会出现问题。某些目标设备会定期发出这些 GA_NXT；它们不受 RSCN 或其他模拟驱动，因此容易受到此问题的影响。
原因是：当区域集激活/提交正在进行时，存在有一个小的时间窗口，在其中 FCNS 只会在 GA_NXT 回复中返回发出方的 FCID，而不会返回与它分区在一起的其他设备的 FCID。这是 Cisco MDS NX-OS 7.3(0)D1(1) 中实施的区域集共享数据库功能的结果。
以下是来自 Cisco 的修复说明：
作为激活的一部分，停用会触发 SDB 清除。在清除 SDB 的同时，它会向所有订阅者发送通知。现在不这样做。此外，添加了新的序列，它将单独发送 SDB 提交通知。这将分区以构建 SDB 并发送一个最终通知
仅在版本 8.4(2c) 中有修复。
SDB = 区域集共享数据库。