共计 4520 个字符，预计需要花费 12 分钟才能阅读完成。
- 什么是负载分担
- 如何通过 Hash 算法实现负载分担
- 如何解决 Eth-Trunk 负载分担不均
- 成员数量是否为 2 的 N 次方
- 是否存在跨设施重叠
- 是否存在 Hash 极化问题
- 流量类型与负载分担模式是否匹配
什么是负载分担
在网络部署当中，当存在多条转发门路的时候，经常会部署负载分担性能。通过部署负载分担，设施能够基于报文内容等进行逐流转发，或者基于随机数、轮转形式进行逐包转发，以达到充分利用链路，进步转发效率的目标。
基于逐包负载分担形式的理论部署较少，因为该形式可能导致同一个用户的流量通过网络的不同门路传输后，达到目标设施呈现报文乱序或多份的状况。常见的负载分担形式个别抉择基于逐流进行负载分担。
逐流负载分担即依照肯定的规定，如依据五元组（源 IP 地址、目标 IP 地址、协定号、源端口号、目标端口号），将报文分成不同的流。同一条流的报文，通过 Hash 计算后，会在同一条链路上转发。
如图 1 - 1 所示，假如 DeviceA 上有 6 个报文要通过 DeviceA 和 DeviceB 之间的 LinkA 和 LinkB 进行负载分担，其发送程序为 P1、P2、P3、P4、P5、P6，其中 P2、P3 和 P5 去往 DeviceC，P1、P4、P6 去往 DeviceD。假如负载分担采纳逐流形式，则去往 DeviceC 的报文都通过 LinkA 发送，去往 DeviceD 的报文都通过 LinkB 发送；或者去往 DeviceC 的报文都通过 LinkB 发送，去往 DeviceD 的报文都通过 LinkA 发送。
图 1 -1 逐流负载分担示意图
如何通过 Hash 算法实现负载分担
常见的负载分担处理过程蕴含输出（流量、报文的有效字段）、解决（通过 Hash 算法进行计算）和输入（依据计算结果将流量通过相应的出接口转发）。其中，通过 Hash 计算的后果会间接影响负载分担的成果，因而如何利用好 Hash 算法进行计算，在负载分担部署当中就显得尤为重要。
图 1 -2 Hash 算法流程
如图 1 - 2 所示，Hash 计算的流程如下：
- 获取报文的信息，对于一般的 IP 报文，为源 MAC、目标 MAC、源 IP、目标 IP、VLAN、四层端口号等。依照配置的流量模型，将这些信息作为 Hash 因子的参考值。
- 依据 Hash 算法和 Seed 对 Hash 因子进行计算，失去 Hash Key。
其中，Hash 算法是芯片提供固定品种的算法，不同的算法对于不同的流量模型计算的成果不同，有多种算法以供选择，能够通过 hash-mode hash-mode-id 参数抉择 Hash 算法。
另外，Seed 是一个数值，用于参加计算。在雷同 Hash 因子的状况下，Seed 值会影响计算出的 Hash Key 的值，通过命令 seed seed-data 设置 Seed 值。
- 为了让同一个 Hash 因子衍生更多的变动，以更加灵便地适应不同的 Hash 场景，设施芯片能够对 Hash Key 的值进行 0~15 位的偏移，能够通过 universal-id universal-id 参数进行设置 Hash Key 的值。
- 将 Hash Key 转化为 Offset 值，Offset 值与进口个数进行取余运算，依据后果决定报文从设施的哪一个接口收回去。
如何解决 Eth-Trunk 负载分担不均
失常状况下，流量在 Eth-Trunk 负载分担后，会被调配到多条链路上传输。Eth-Trunk 负载分担不均是指流量通过负载分担后，仅被集中调配到一条或者某几条链路上传输，而其余链路无流量或者流量较少的状况。如果单条链路的流量较大，可能会影响业务的失常运行。
成员数量是否为 2 的 N 次方
Eth-Trunk 每个发送周期有 16 个发送报文的时隙，Eth-Trunk 成员口轮流应用这 16 个时隙发送报文。
当 Eth-Trunk 成员口数量是 2 的 N 次方时，能够使得负载分担更平均。例如，如果 Eth-Trunk 成员口数量是 2、4 或 8（能够整除 16），每个接口失去的发送报文的时隙是整数，负载分担就平均；如果成员口数量不是 2 的 N 次方（比方 3 个），在 16 个时隙里有 1 个接口失去了 6 次发送报文的机会，另外两个接口只失去 5 次发送报文的机会，负载分担就不平均。因而，Eth-Trunk 成员口数量最好是 2 的 N 次方，保障负载分担更平均。
是否存在跨设施重叠
CE 交换机在重叠场景下默认开启 Eth-Trunk 本地优先转发性能，即从本设施进入的流量，优先从本设施的出接口转发进来。本地优先转发能够升高转发延时，升高重叠链路的利用率。
如图 1 - 3 所示，SwitchA 与 SwitchB 组成重叠，上下行退出到 Eth-Trunk。如果没有本地优先转发，则从 SwitchA 进入的流量，会有一部分通过重叠线缆，从 SwitchB 的物理接口转发进来。设施启用本地优先转发之后，从 SwitchA 进入的流量，优先从 SwitchA 的接口转发。
图 1 -3 流量本地优先转发示意图
默认开启本地优先转发的状况下，同框的 Eth-Trunk 成员口负载分担平均，不同框的 Eth-Trunk 成员口负载分担不平均。要解决跨设施重叠场景中的不同设施的成员口负载分担不均问题，能够依照以下步骤解决。
- 在任意视图下，执行命令 display interface eth-trunk [trunk-id [ .subnumber] | main ]，查看 Eth-Trunk 成员口是否跨设施，如重叠场景下不同设施上的接口捆绑成 Eth-Trunk 端口。
-
如果 Eth-Trunk 成员口是跨设施的，去使能 Eth-Trunk 接口流量本地优先转发性能。即在 Eth-Trunk 接口视图下，执行命令 local-preference disable。
<HUAWEI> system-view [~HUAWEI] interface eth-trunk 10 [*HUAWEI-Eth-Trunk10] local-preference disable [*HUAWEI-Eth-Trunk10] commit敞开本地优先转发性能后，局部流量会跨设施之间的重叠链路，须要保障该链路带宽足够。
是否存在 Hash 极化问题
Hash 极化，也被称为 Hash 不均，是指流量通过 2 次或 2 次以上 Hash 后呈现的负载分担不平均的景象。常见于跨设施的屡次 Hash 场景，即第一级进行 Eth-Trunk Hash，第二级再进行 ECMP Hash 或者 Eth-Trunk Hash。在同一设施上，若存在 ECMP 的出接口为多个 Eth-Trunk 也可能会呈现 Hash 极化。
图 1 -4 Hash 极化示意图
如图 1 - 4 所示，Switch A 的入接口有 4 种流量，出接口为 2 条等价链路，经 Hash 计算，流量 1 和流量 2 走下面的链路到 Switch B；流量 3 和流量 4 走上面的链路到 Switch C。在 Switch B 出接口同样为 2 条等价链路，若采纳与 Switch A 雷同或者相似的 Hash 算法，其 Hash 的后果将为流量 1 和流量 2 走下面的链路，而上面的链路没有流量。Switch C 的状况相似。这种通过屡次 Hash 后，ECMP 或者 Eth-Trunk 各成员口之间流量极度不平均的景象称为 Hash 极化。
实际上，交换机 Hash 性能的实现很大水平上取决于芯片，所以当应用同类型芯片的交换机位于网络中相邻的层级时，就可能会呈现 Hash 极化问题。因而，在多级网络中部署 ECMP 或者 Eth-Trunk 负载分担，须要思考呈现 Hash 极化问题的危险。
解决两级负载分担场景下的哈希极化问题，就是要防止两级设施应用雷同的负载分担参数。
如果流量有多个特色有较大变动时，能够让两级设施采纳不同的哈希因子，比方第一级 Eth-Trunk 应用源 IP 进行哈希，第二级应用目标 IP 进行哈希。
第一级 Eth-Trunk 应用源 IP 进行哈希。
<HUAWEI> system-view
[~HUAWEI] load-balance profile default
[~HUAWEI-load-balance-profile-default] ip src-ip
[*HUAWEI-load-balance-profile-default] commit
第二级 Eth-Trunk 应用目标 IP 进行哈希。
<HUAWEI> system-view
[~HUAWEI] load-balance profile default
[~HUAWEI-load-balance-profile-default] ip dst-ip
[*HUAWEI-load-balance-profile-default] commit
- 如果调整哈希因子后成果不显著，通过执行命令 eth-trunk hash-mode hash-mode-id，调整两级的哈希算法为不同的算法。
- 如果调整哈希算法任然没有成果，通过执行命令 eth-trunk universal-id universal-id，调整 Eth-Trunk 的偏移量 universal-id。
流量类型与负载分担模式是否匹配
判断 Eth-Trunk 接口转发的报文特色和配置的负载分担形式是否匹配。如果不匹配，例如转发报文的 MAC 地址变动，而设置的负载分担形式为 src-ip，则无奈负载分担。
辨认报文类型
- 确定报文的类型。
确定报文为 IP 报文、MPLS 报文、TRILL 报文、FCoE 报文等。 - 不同报文的负载分担形式。
针对不同类型的报文，能够别离配置负载分担模式。以 CE6856HI 为例，负载分担形式如表 1 不同报文的负载分担形式所示。例如，对于 IPv4 报文，默认状况下依据源 IP、目标 IP、目标端口号、源端口号进行负载分担，也能够通过命令行配置负载分担模式。须要获取其余款型的负载分担形式，请参考配置负载分担形式进行配置。
表 1 -1 不同报文的负载分担形式
配置负载分担形式
- 配置已知单播的负载分担形式
- 执行命令 interface eth-trunk trunk-id，进入 Eth-Trunk 接口视图。
- 执行命令 load-balance {dst-ip | dst-mac | random | round-robin | src-ip | src-mac | src-dst-ip | src-dst-mac | enhanced [ resilient] profile profile-name }，配置 Eth-Trunk 负载分担形式。
用户能够依据流量模型设置不同的负载分担形式来抉择各种负载分担模式，流量中该参数变动越频繁，抉择此负载分担模式的流量就越平衡。例如，在网络中，如果报文的 IP 地址变动较频繁，那么抉择基于 dst-ip、src-ip 或 src-dst-ip 的负载分担模式更有利于流量在各物理链路间正当的负载分担；如果报文的 MAC 地址变动较频繁，IP 地址比拟固定，那么抉择基于 dst-mac、src-mac 或 src-dst-mac 的负载分担模式更有利于流量在各物理链路间正当的负载分担。
- 执行命令 commit，提交配置。
- 配置未知单播的负载分担形式
- 执行命令 load-balance unknown-unicast {mac | enhanced}，配置未知单播的负载分担形式。
在网络中，对于未知单播，如果 IP 报文的源 MAC 地址或者目标 MAC 变动较频繁，而 IP 地址比拟固定，那么抉择参数 mac 对未知单播进行负载分担；如果 IP 报文的源 IP 地址或者目标 IP 地址变动较频繁，而 MAC 地址比拟固定，那么抉择参数 enhanced 对未知单播进行负载分担。
- 执行命令 commit，提交配置。
