排除链路聚合模式故障

■

随着网络规模的不断扩大用户数量的不断攀升，随之而来的网络设备端口的流量也在增加，端口流量的增大势必会造成数据的拥塞，从而导致用户上网体验差，为了更好地解决这一问题，我们采用了链路聚合办法来解决OLT上行链路拥塞的问题，但是链路聚合也要正确使用，否则不但达不到增加网络带宽的目的，反而会产生网络故障。下面就结合一个故障案例来具体介绍一下链路聚合在配置中应该注意的问题。

故障现象

图1 网络拓扑结构

近日，我们陆续接到用户的报修，反映晚上上网速度比较慢。得知这一消息后，我们根据用户所使用的设备情况，初步断定是城区传输设备5566互联BRAS的端口流量拥塞引起的。获取这一信息很简单，只要登录到城区的5566上查看端口的利用率即可。知道这一故障原因后，我们决定使用链路聚合来增加两台设备间的链路带宽，可是就在我们对两端设备进行配置后发现，链路聚合组一直不能生效。

故障分析

为了更好地解决问题，清晰地找到故障的节点，我们首先了解一下网络的拓扑结构（如图1）。

从图1中我们可以看到，城域网由四个基站的5566组成，中心站5566使用1G通道上联BRAS，得知网络拓扑结构后我们开始排查链路聚合的故障。首先我们登录到5566上使用命令show interface trunk查看配置即：

从上面的配置可以看到，在链路聚合组Trunk1/3中已经有成员端口1/17和2/19，但是通过命令show interface看到trunk1/3处于Down的状态。查看完5566上配置后，紧接着再查看下BRAS上配置，我们在BRAS上定义链路聚合组smartgroup4作为和5566互联，同样使用命令show lacp internal查看聚合组的状态显示端口gei-0/0/0/5和gei-0/0/0/6处于Inactive状态，这样通过查看两端设备的链路聚合组状态后，我们发现两端的链路聚合组都处于Down状态。

知道了故障现象，我们就需要将问题解决。首先分析一下两端设备的配置命令是否存在不妥之处。既然是配置链路聚合，它的作用是增加物理带宽，实现链路的负载分担和备份的作用。我们将两侧端口的主要配置拷贝下来进行分析比较，其中5566上的链路聚合配置如下：

通过上面我们可以看到，两端设备链路聚合的配置似乎没有什么问题。但是，仔细比较这两个配置可以发现端倪，在5566上我们配置的trunk1/3是静态的，而在BRAS上配置的smartgroup模式是动态的。问题分析到这里我们找到了问题的根源，原来链路聚合的模式在BRAS上是这样定义的，模式Passive是接口的LACP处于被动协商模式；Active 是接口的LACP处于主动协商模式；而如果使用模式on 则是静态trunk，此时不运行LACP，聚合的两端都需要设置成静态的模式。而我们在BRAS上设置的是主动协商模式，是属于动态的链路聚合，和对端设备5566的链路聚合模式不相同，所以端口的链路聚合始终处于Down状态。

故障解决

知道了链路聚合的故障是因为两端设备设置的链路聚合模式不同引起的，所以我们决定修改BRAS上的配置：

通过上面的配置，我们将链路聚合的模式由动态模式修改成了静态模式，这样我们查看了一下两端设备的链路组的状态都已经处于Up状态，然后再查看两端设备，可以看到流量已经在两个端口上实现了分担，这就说明我们配置的链路聚合是正确的。

经验总结

通过后期对客户的回访，客户对网络体验度得到了明显的提升。其实在日常网络开通和维护的过程中，需要做好准备工作，把前期工作做扎实，在后期网络的维护中才不容易出错误，可以事先查看设备的配置手册或者请教厂家工程师，在充分论证和推敲的基础上，对网络进行平滑升级和改造，这样才能让升级工作顺利完成。

通过此次故障的排除，我们打算在后期汇聚设备连接BRAS的时候，都采用链路聚合的方式连接，虽然暂时在链路聚合组中可以只有一个端口，但是后期在链路扩容的时候，只需要把额外增加的端口加入到链路聚合组中就可以了，不至于中断业务来配置链路聚合。只有把眼光都要放远一些，只有把工作做到前面，才能在后期的网络运维中赢得主动，才能把网络工作做得更好，从而进一步将客户服务质量加以提升。