负载均衡：浅谈常用场景锐捷设备的优化方法 | 运维实战家

随着互联网业务的高速增长，为满足数据中心灵活扩展高带宽的需求，端口聚合或者是路由ECMP被普遍应用。

目前锐捷数据中心交换产品负载均衡模式基于流模式的负载均衡，实际负载均衡基于IP报文五元组或者增强模式。负载均衡模式因子包括：源/目的MAC、源/目的IP、源/目的L4端口号。增强模式还可以支持数据中心特性字段，例如支持协议类型如MPLS报文、FCOE报文类型等字段。

涉及到负载均衡的场景包括二层AP口、三层AP口、路由ECMP，默认三者共用同一个全局的负载均衡模板。AP可以基于单个端口调整负载均衡模板，路由ECMP只能共享全局定义的负载均衡模板。

普通型的负载均衡，其中二、三层AP口默认基于源/目的MAC；路由ECMP默认基于源/目的IP。以报文匹配负载均衡因子的方式来生效，比如一个报文是IPv4报文，默认负载均衡模式，二、三层AP口都是以源目的MAC进行负载均衡，而ECMP端口则以源/目的IP来进行负载均衡。如果修改了为IP/PORT的负载均衡，则二三层AP/路由ECMP都以IP/PORT的负载均衡为准。

增强型的均衡模式，以报文匹配负载均衡因子的方式来生效。比如一个报文是IP报文，增强型有默认定义IPV4的字段负载均衡以源目的IP为准，如果需要调整ipv4的均衡算法只能调整ipv4 field字段。无论二三层AP/路由ECMP都如此。

一般情况下，采用普通模式进行负载均衡，采用源目的IP/源目L4port，可以满足绝大部分的HASH负载均衡模式。

注：全局模式配置，对于二三层AP/路由ECMP公用模板，共同生效。

即：

如果存在负载均衡较差的情况，可以在HASH因子不变的情况下修改为增强型的模式进行使用。

show aggregatePort load-balance可查询当前选择的负载均衡因子，若涉及到增强模式，还需要show load-balance-profile XXXX查询增强模板，针对不同报文的负载均衡方式。

一般情况下通过上述两种方案就可达到均衡效果，但在一些特殊场景下又有哪些地方需要注意呢？请看下文讲解：

图1：CDN场景下出口部署PBR多个等价下一跳

如图所示，在CDN场景下在出口连接多个运营商时，往往需要匹配IP为某运营商如电信时选择下一跳为电信的多个互联端口，互联端口间要求流量负载均衡。

针对该场景默认情况下多条链路为主备模式，要达到负载均衡效果需在全局下配置：

图2：开启VSU本地转发，当主备机输入流量不一致

 图3：开启VSU本地转发，当主备机输出端口数不一致

如图所示，当使用VSU组网时，由于设备默认开启了本地转发，当主备机输入流量不一致，或输出端口数不一致时，如果要实现在所有ECMP出口之间负载均衡，可以考虑关闭默认的VSU本地转发，但此时出向流量会经过VSL链路，会给VSL链路带宽带来压力

VSU模式下配置

注意：如果该场景下存在ECMP下一跳出口为AP口，我们的AP/ECMP采用相同的算法，而且根据业务的流量特征选择相同的因子，就会导致LACP上面的流量会由于HASH极化而集中到其中的一条链路上，此时推荐在增强型负载下增加配置扰动因子来解决

数据中心LVS集群通常通过ECMP和TOR互联，如果通过动态路由协议在TOR和LVS集群之间生成ECMP路由，当ECMP某条链路因故障失效后，动态路由协议会重新收敛，从TOR到集群的流量会重新均衡，这就打乱了集群成员机上原来维护的会话状态，整个集群需要重建会话，导致部分会话中断。

该场景下推荐配置ECMP CLUSTER 特性，使用ECMP CLUSTER后，如果ECMP 路径数量减少，只会将失效链路上承载的流量均衡到活跃链路上，活跃链路上承载的流量不变，如果ECMP路径数量增多，会将原先活跃链路上的部分流量切到新增链路。

图4：TOR与LVS集群之间通过ECMP互联

图5：当TOR与LVS最右侧链路中断后流量转发规则

全局模式下

注意，开启该特性前提需要使用增强型负载均衡模式

图6：多台同厂商设备级联且采用聚合

或者ECMP等价负载的情况

在数据中心场景里，如果出现图中LEAF/SPINE交换机都是同型号设备（或者同芯片算法）。对于LEAF交换机来说，有四个不同的流，其中流1,2选择了左边的链路，到达了SPINE-1设备。由于SPINE-1和LEAF的HASH算法完全相同，所以在做HASH时，SPINE-1将流1,2归为了同一类，都选择了左边的链路进行转发，如此计算SPINE-2将流量3、4选择右边链路进行转发。

该场景下建议在配置增强型负载均衡模式后，不同层级设备调整均衡算法，避免极化现象

图7：对收到经过GRE封装后的报文要求基于内层报文进行HASH实现负载均衡拓扑

某数据中心客户反馈机房一组62H下挂的2个服务器和62H来建立OSPF，并同时发布一个用于建立GRE隧道的地址，比如是10.1.1.1，和远端的一个在其他节点的路由器上的地址来建立GRE隧道，GRE隧道的源地址是2个服务器发布上来的一个VIP地址，目的地址是远端路由器地址，源目地址已经通过路由打通了，我们62H相当于是GRE流量的过路设备，目前发现62H下挂的2个服务器只有其中一个有接收到远端路由器经过GRE封装发过来的流量。

该场景下，由于我司交换机默认情况下对经过的GRE流量只能基于外层报文进行HASH，无法获得均衡效果，可以通过以下命令修改对GRE报文支持过路的内层均衡

全局下

注意，开启该特性前提需要使用增强型负载均衡模式

• 走近科学：带你解密“映射报文”失踪之谜 | 运维实战家
  

• 锐捷AP缺省VLAN和用户VLAN那些事儿 | 运维实战家

• 你不得不知的锐捷设备报文捕获技巧 | 运维实战家

• 在网络中也要避免"被感染"，看黑域名的危害与应对措施 | 运维实战家

• iPhone提示："无线局域网似乎未接入互联网"，咋回事？| 运维实战家

• 无线信号旁的那把"小锁"，是怎么回事？| 运维实战家

• AP和AC上隧道状态不一致，上线异常怎么办？