重新审视SDLMUX

SDLMUX 软件将两个网络适配器组合成一个 IP 接口，在活动适配器上的链路中断或适配器出现故障时提供故障切换功能。一旦设置完毕，它几乎不需要管理，但有一些事情您应该注意。

首先，SDLMUX不提供任何负载均衡；所有流量都从活动适配器上传输出去并接收。

其次，在ftServer VS系列硬件上，活动适配器的MAC地址形式为00:00:A8:4v:wx:yz。00:00:A8是由IEEE分配的Stratus 组织上的唯一标识符（OUI）。v"是基于SDLMUX设备初始化顺序的索引，从0开始。"wx:yz"值基于系统序列号。待机地址与活动地址的差别只在第四个字节的上半部分，而不是 4，而是 6，而且同一模块上两个活动（或待机）适配器的 MAC 地址的差别只在第四个字节的下半部分。最简单的方法是用analyze_system请求"dump_sdlmux"在"MAC"上匹配得到所有的MAC地址列表，见图1。

仅仅是MAC地址并不是很有用；通过匹配"MAC"或"#"，您可以获得MAC地址以及SDLMUX和网络适配器设备名称。请注意，此列表不包含任何不属于 SDLMUX 合作伙伴关系的网络适配器。

第三，SDLMUX网络适配器向其合作伙伴发送以太网802.2 LLC帧，以确保网络路径正常运行。这些测试帧以三秒的间隔发出五组，然后是33秒的间隔。跟踪1显示了这种模式的三个周期。跟踪1还显示了来自活动适配器（帧1）和备用适配器（帧2）的实际帧。我突出显示了33秒间隙后的帧，只是为了使周期更容易阅读。这些不是以太网II型帧或IP数据包，连接到网络适配器的交换机和两个适配器之间路径上的任何交换机必须有一个不阻止这些802.2 LLC帧的配置。

请注意，您不能使用 packet_monitor 来查看这些测试帧。这些帧是在packet_monitor接入堆栈的下方发送的，SDLMUX会在packet_monitor读取这些帧之前将其从堆栈中删除。

第四，如果每个适配器都连接到不同的交换机上，而这些交换机之间的链路发生了故障，或者由于其他原因，测试帧没有得到，你会在syserr_log中看到类似图3的东西。从 16.2.1ak 和 17.0.0ah 版开始，如果测试帧失败，SDLMUX 会触发一个 ARP 请求，向通过可疑接口成功 ARP 的最后一台主机发送。如果得到回答，它就知道活动适配器在工作，因此它会重置备用适配器，以尝试让它工作。如果有一个网络问题阻挡了测试帧，重置适配器没有帮助，适配器最终会进入MTBF，见图3中的时间戳08:08:10。dlmux_admin命令会将坏掉的适配器报告为DOWN，图4，跟踪会显示没有测试帧，因为此时没有任何东西可以测试。如果没有收到ARP回复，或者问题出在一个没有发送ARP请求的版本上，SDLMUX将在适配器上失效，并破坏新的备用适配器。如果在下一个周期中，测试帧再次失败，并且没有收到ARP回复，则将再次进行失败和中断。最终，一个适配器将进入MTBF。

要想让适配器重新投入使用，你需要使用 board_admin 命令将其添加回来。当然，如果你这样做而不纠正根本问题，适配器就会再次出现MTBF。

第五，由于活动适配器总是有相同的MAC地址，所以故障切换的效果是将MAC地址从一个交换机端口移动到另一个端口。交换机端口上的任何安全设置必须允许这种变化。此外，交换机端口可以配置为与其他交换机端口对话，协商各种设置。当交换机注意到拓扑结构的变化时，如新的MAC地址或链路被恢复时，可以触发这些设置。在协商这些设置之前，交换机可能无法传递常规帧。连接到 SDLMUX 适配器的交换机端口应配置为不执行这些协商。此外，应将连接到 SDLMUX 适配器的交换机端口配置为不运行生成树协议或跳过学习和监听步骤（Cisco 称之为 portfast）。在学习和监听步骤中，交换机不会传递常规数据帧。在极端情况下，这些设置造成的延迟可能会太长，以至于SDLMUX会触发另一次失败。

最后，需要监控适配器的链路状态，确保两条链路都是正常的。链路的故障不会导致系统打到家门口，由于其容错性强，不会造成系统连接的损失，我在之前的一篇博文中介绍过，请看监控网络适配器状态。