未知单播全从一根线涌出？按源地址摊开走

本文整理自华为官方发布的典型配置案例，命令与步骤均按原始文档呈现，供现场实施参考。

交换机转发报文靠MAC地址表，查得到出口的叫已知单播，查不到的叫未知单播——新终端上线、表项老化、或者干脆是扫描流量，都会产生这类“不知道该往哪发”的报文。在捆绑链路上，未知单播的分担方式默认按源MAC加目的MAC来算，多数时候没问题，但特定场景下这个默认值会帮倒忙。

典型的是流策略里重标记了目的MAC的部署：报文的目的MAC被策略改写，分担算法若还在按目的MAC算哈希，算出来的结果就不反映真实流向，该摊开的摊不开。这种情况下官方明确要求把未知单播的分担方式改成按源MAC：

<HUAWEI> system-view
[HUAWEI] unknown-unicast load-balance smac

这条命令在全局视图下执行，可选的分担依据有四种：按目的MAC、按源MAC、按两者异或，以及基于负载分担模板的增强方式。多次执行以新配置为准，改起来不用担心叠加。

真正要打起精神的是增强方式的两个硬性场景。一是在VPLS或VXLAN网络里，如果非已知单播流量的出接口是跨板捆绑口，必须把分担方式配成带板间标识的增强方式，否则可能出现丢包或者重复包——虚拟化大二层里这类“莫名多包”的疑难杂症，很多就是漏了这条。二是集群环境下捆绑口由集群板和非集群板混绑时，用增强哈希同样必须带上板间标识。另外还有单板组合的适配细节：个别老型号板子与其他类型单板组建跨板捆绑口时，要提前把分担方式定好，跨板捆绑口建成后不能再改。

改之前再确认一遍互斥项：带板间标识的增强方式和按流分流的那条命令互斥，不能同时存在。配置下发后用未知单播的转发统计验证分担效果，出现丢包多包就回头查单板组合与哈希模式是否踩了上面列的坑。分担方式的细节平时看不见，出事就是大事，欢迎搜索关注贵州诚鑫致达科技，获取更多交换机转发与捆绑链路调优的实操经验。

企业存储选型参考｜贵州诚鑫致达

做机房存储、虚拟化或监控归档，群晖机型参考：FS6400（全闪存阵列） · SA3610 · SA3410。需要选型建议或上门评估，搜「诚鑫致达」即可找到我们。

服务区域｜贵州诚鑫致达

贵州群晖NAS、贵阳存储、数据备份、信创云盘或 IT 集成服务，可联系贵州诚鑫致达科技，服务范围覆盖贵州全省各市州。凯里（黔东南）、都匀（黔南）：企业存储方案与 IT 运维。