已索引
背景：现存4台大数据物理服务器（RHEL7），现计划对其扩容，新增4个节点。
在对新服务器配置网卡的链路聚合时，我们计划与旧服务器保持一致。
但发现旧服务器使用的 team 模式为 activebackup，交换机端的配置为 lacp。
这跟我们平常学习到的理论知识相违背，由于生产环境从2019年上线后一直平稳运行至今（2024年），我们打算新服务器仍参照配置。
即：新服务器端使用 activebackup，交换机端配置为 lacp。
上午在第一台新服务器上配置完成后，ping 正常，使用正常。所有配置完成后，对服务器进行了重启。
下午另外三台新服务器同样的方式配置完成后，网络不通。检查第一台服务器，网络也不通。
重新对配置进行审视，发现了问题。
交换机(2台虚拟成1台) 服务器
A B a b
假设服务器的 a, b 口分别与交换机的 A, B 口相连。
服务器的 a, b 口，因为使用的主备模式，所以只有一个口处于 active 状态。
而交换机端，通过查看交换机配置，可以看到 A, B 两个端口，一个状态是 S(selected)，一个状态是U(unselected)。
通的原因是：交换机的S口与服务器的 active 口正好在同一线路上，即 Aa 或 Bb。
不通的原因是：交换机的S口与服务器的 active 口不在同一线路上，即 Ab 或 Ba。
根据理论，将交换机的端口配置修改为不做任何配置后，A B 两个端口状态都变为 S(selected)，此时，服务器端 a b 两个网卡不论哪个处于 active 状态，网络都能通。
由此可知，目前生产环境中的4台服务器存在安全隐患，在交换机端不变的情况下，一旦服务器重启或者当前活动网卡故障切换了活动网卡，网络会不通；同理，在服务器端不变的情况下，如果交换机 S 状态的网口发生故障，网络也会不通。
经与网络同事讨论，我们决定服务器端与网络端均采用 lacp 的方式配置链路聚合。对现有生产环境进行整改时，交换机端保持不动，服务器端只需要将 activebackup 修改为 lacp 即可。
此外，借此机会，我们对 loadbalance 模式进行了测试。
按照理论，当服务器的 team 模式配置为 loadbalance 时，网络端需要配置链路聚合，思科交换机也叫做以太通过 (EthernetChannel)。
但实测下来，当我们配置为 loadbalance 后，交换机端不做任何配置，也能通。
但交换机上能看到两口对应到同一个MAC地址。
<DC01-YWOA-S68-IRF>
<DC01-YWOA-S68-IRF>display mac-address | include fe3b
e861-1f50-fe3b 801 Learned XGE1/0/17 Y
e861-1f50-fe3b 801 Learned XGE2/0/17 Y
<DC01-YWOA-S68-IRF>display mac-address | include fe3b
e861-1f50-fe3b 801 Learned XGE2/0/17 Y
<DC01-YWOA-S68-IRF>display mac-address | include fe3b
e861-1f50-fe3b 801 Learned XGE1/0/17 Y
e861-1f50-fe3b 801 Learned XGE2/0/17 Y
<DC01-YWOA-S68-IRF>但正常情况下，使用聚合的技术后，MAC 地址应该是从聚合口学到的，例如：
<DC01-YWOA-S68-IRF>display mac-address | include fe35
e861-1f50-fe35 801 Learned BAGG33 Y 因为没有加业务负载，我们的测试就是简单的 ping 和 ssh，那这样做到底有没有问题？又或是否交换机厂商做过优化处理？
暂未可知。但还是不建议这种违反标准的做法，就如前面的例子，生产跑了几年了，说不定哪天才发现问题。
注：本文交换机的型号为 H3C S6800-54QF。
