不可小觑负载分担模式

故障现象

近日，根据流量监控软件的监测分析结果，发现某联通出口在晚高峰期使用率已经达到80%，我们决定对该出口进行扩容。由于原有联通出口与我们互联是10G接口，而且该流控设备上已没有万兆端口，只能使用千兆口对接。但用千兆口对接，互联网出口厂家对这次扩容的端口也是用万兆端口，由于情况紧急，只得在出口厂家设备和我们流控设备之间增加一台有万兆光口的交换机，然后再使用链路聚合的模式和流控设备对接。因为互联网出口厂家给我们这次扩容提供了10G的通道，结合我们目前的网络状况，可以先在交换机上捆绑3G来满足当前业务的发展。

就在我们完成10G对接、3G链路聚合捆绑后，发现3G有两个端口是没有流量的，但是双方的端口都是Up的。

故障分析

首先排除了物理层光路和光模块的问题，两者之间设备互联除了光路和光模块外，那就是两个设备间运行的链路聚合协议。在流控设备上看到使用的端口负载分担模式是“会话均衡”，而对端交换机采用的端口负载分担模式是“srcdestip”，会不会是这个地方出现了问题?

故障解决

通过查询资料和请教厂家技术工程师，我们对流控设备上的负载分担模式进行了修改，修改成了“轮询”后，链路聚合组成员的另外两个端口开始有流量，这说明操作是正确的，故障得以解决。

经验总结

上面我们从对互联网出口的监测情况，根据现有设备情况采用链路聚合的模式来完成互联网出口的接入，在出现端口没有流量的故障后，首先排查了物理层，最后在数据链路层的链路聚合负载分担模式上发现了端倪，通过修改一侧设备的负载分担模式达到了解决故障的目的。

后期通过查找资料，得知链路聚合的负载分担模式有很多种，诸如基于源MAC、目的MAC、源和目的MAC、源IP、目的IP、源和目的IP这6种模式，它可以将数据流量均衡合理的分担到不同链路上，最后能到达同一的目的地，避免链路阻塞。在日常网络维护中，可以根据实际情况来选择负载分担模式，流量中该参数变化越频繁，选择此负载分担模式的流量就越均衡。负载分担只对出方向的流量有效，因此链路两端设备的接口负载分担模式可以不一样。但是不同设备间如果该负载分担的模式不相匹配，会引发流量的异常。即文章开头出现的两个端口没有流量的情况。