ASR9k load balance issue under L2VPN(VPLS/Eompls/ATOM)

Intro

很多客户在部署VPLS时,当核心有负载链路或者Bundle时,常常会碰到负载不均的现象,为什么会发生这种问题?首先看下常规ASR9k在不同场景下是用什么元素去做Hash的:
9k-load-share-01

A: src-ip, dst-ip, src-port, dst-port, router_id
B: bottom_most_label, router_id
C: 4th_label, router_id

2020-6-24 更新:Multi-Label MPLS Load-Balancing Hash Algorithm Update

原有ASR9k ECMPHash 算法:在MPLS报文时,只有4label以下的数据报文才可以使用IP 5元组Hash,超过4层的只能用单个labelraw hash。此算法在之前问题不大,label数很少超过4个,但在SR 的环境下,可能会有更多的label,因此BU更新了此场景的Hash算法:

  1. 5-8个label,不再使用单个label做hash,而是采用IP 5元组来做hash
  2. 9个或更多label,使用新的hash 算法:multi-label MPLS hashing,label3-5中的label作为raw hash

Tomahawk从623开始使用新的算法;Lightspeed和Xrv9k从652开始使用新的算法

Ok,我们可以看到在L2VPN中,用的是bottom label来做的负载均衡,这是因为系统无法跳过L2VPN中的MAC头,去读L3的IP头。在这里拿Bundle端口举例,说说不同场景下bundle的HASH方法(在9k上,所有HASH动作都是在进口NP上做的,这个HASH结果会直接被出口NP调用):

1. 如果bundle配置了L2transport,默认根据src-mac,dat-mac,router_id做HASH,注意这种场景没有在上面图中列出来,可以通过如下配置更改:

RP/0/RSP0/CPU0:BNG(config-l2vpn)#load-balancing flow ?
src-dst-ip Use source and destination IP addresses for hashing
src-dst-mac Use source and destination MAC addresses for hashing

2. 如果bundle端口用于L3转发,排除L2VPN环境,和超过4层标签外,其他都用5元素HASH
3. 如果bundle需要承载PW,那么这些L2VPN的流量会根据底层label做HASH

下面是一个L2VPN报文的例子:
9k-load-share-02
根据上图,当S=1的label是底层label,所以用16000去做HASH

问题

1. 数据报文乱序

在使用L2VPN时,为了使用更少的指令集控制转发数据包,已达到更大的PPS,思科(或者业界)使用统一的指令集来处理MPLS以及L2VPN场景的负载分担,默认根据离MPLS Header最近的4byte,如果是4或者6,就会识别是IP Header,选择5元素去HASH;否则就是非IP Header,默认属于L2VPN,选择底层Lable去HASH。
9k-load-share-04
9k-load-share-03

这个指令集使用了很长时间,而且没有任何问题,因为默认MAC都是以00开头的,但现在来看,硬件的MAC已经有以4,6开头的,所以当遇到这些MAC的流量可能会有问题,系统会错误的把L2VPN的MAC地址识别成IP的header,并去检索相应的字段,这样会使同一条流被HASH到不同的link,导致乱序。想解决这种问题,最直接的就是优化指令集,这些指令集已烧到ASIC中,所以优化不现实,如果是在NP中,可以重写指令集,但这样会耗费很大精力,并降低硬件处理能力,那么没有别的办法了么?

在L2VPN的PW中,有一个Control Word就是做这个用的,Control Word字段由4byte的0组成,下面是摘自RFC4385

The design of these fields is chosen so that an MPLS Label Switching Router performing MPLS payload inspection will not confuse a PWE3 payload with an IP payload.

下面是CW在包中的位置:
9k-load-share-05

OK,解决了MAC地址为4,6的乱序问题后,负载会分担么?当然不会,因为每个PE只会发送一个PW Label,那么去往同一个PE的流量会分配同样的PW label,那么问题来了,负载后都会到一根link,如何解决这个问题?

2. L2VPN中负载分担

可以通过FAT label,我在之前的文章中介绍过:《PW load share issue on ASR9k》,我这里只是简单说几点需要注意的:
– FAT Label是公有标准RFC6391
9k-load-share-06
– FAT Label最好是通过协商来互通,如果对端不支持,就不会启动这个feature。但9k支持static配置,这样会强制实行FAT Label,如果对端不支持,那么中间的数据就会中断,“flow-label both [static]”
– 这个feature从4.2.1开始支持,并且4.3.1以前都是以0x11来标示flow label的,这是因为早期的ietf文档设置的是0x11,但是根据公布后的RFC,这个值变成了0x17,从4.3.2后,可以手动调整标识以兼容以前版本:“flow-label code 17”
– NP根据什么规则生成flow label?如最开始说的那个命令,“load-balancing flow xxx”。默认根据src-mac,dat-mac,router_id,可以改为基于src-ip, dst-ip, router_id
– 注意在PE上先根据Label HASH,然后再根据源目的MAC或源目的IP插入FAT Label,所以PE上是不会起作用的,在P上会根据这个FAT label去做Hash,如果一些特殊场景,如只有1个AC和1个BD的情况,一个PE只有一个PW label,如果核心方向有多条链路,那么只有一条link会承载流量,但事实很少用户会部署一个AC/BD

2015-2-16 更新:关于“load-balancing flow src-dst-map/ip”
这个问题在1月底就确认了,可一直没有更新。。。快过年了,比较懒。。。
这条命令不仅仅是分配flow label的方法,也是一个开关,上面讨论的用底层label做负载分担(PE->P)都是在没有开启这个开关的时候,如果配置了,那么会改变这种行为,PE->P这个方向的负载根据MAC、IP来做负载,这点一定要记住!

2017-10-10 更新:Whether support Fat Label for PBB-EVPN?
Yes, ASr9k support fat label for PBB-EVPN after 5.3.0.

2018-7-26更新:Entropy Label,RFC 6790
Entropy Label是个什么东东?之前一直没有在意,现在有人在讨论。Google了下,发现它要解决的问题跟FAT label是一致的,只是不像FAT label(只要在PE启动就可以了,中间P执行默认的hash),要想支持Entropy label,需要全网部署,包括P节点。所以带来的好处可想而知,可以给客户带来统一的hash方式,不好的就是要全网支持。另外可以通过LDP, BGP or RSVP来传递Entropy label(FAT Label通过LDP),那么Entropy label长啥样?应该在FAT label的位置插入两个label,一个是Entropy Label indicator,另一个是Entropy label,做hash的是 EL而不是ELI,以后有环境再抓包,并做更新吧~

参考文章:

ASR9000/XR: Loadbalancing architecture and characteristics

0
你可以留言,或者trackback 从你的网站

留言哦

blonde teen swallows load.xxx videos