Multi Hierarchical CEF / Load Share
环境
--------+--------------------+--------- | 22.22.22.22/32 | | | +----+----+ +----+----+ | 2.2.2.2 | | 3.3.3.3 | | RouterA | | RouterB | +-\----\--+ +-/---/---+ \ \ / / \\ \ / / \ \ / // \ \F2/0 / / \\ \ / / F1/0 \ \ F3/0 / F4/0 *--\-/--* |1.1.1.1| | CoreA | +-------+
不限设备,所有运行IOS的设备,包括GSR,7609等。
在早期版本,不支持Multi hierarchical CEF,仅仅支持一层递归后的转发。这样产生了很多限制,例如今天提到的双PE结构。在特定版本后(包括IOS和IOX),CEF的行为有了改变,并且支持多层CEF。不过CEF的行为也要看平台,因为GSR上任何版本都不支持这种多层CEF。
问题
当用环回口来建立多跳eBGP邻居时,对于BGP的负载均衡来说,他是基于下一跳的。他有两个负载均衡,分别是2.2.2.2和3.3.3.3,但是对于这两个下一跳,又递归到了IGP(静态路由制定的)的负载均衡上,总共是4跳,但是由于不支持多层CEF,对于BGP来说,他只能从四条链路中选出两条来达成负载均衡(F1/0|F2/0; F3/0|F4/0),这样就会导致流量不会非常均衡。
2012-4-13 更新:
今天同事碰到一个类似的BGP负载问题,经讨论后,发现对于GSR上BGP的负载均衡有了一些新的理解,之前理解的还是有些模糊。确实BGP的负载均衡是针对下一跳的,而且GSR也确实仅仅支持1层CEF查找,从两个BGP负载中选一个很好理解,但是对于每个下一跳路由,还有两条IGP的路由呢(F1/0|F2/0),这两条应该选哪条呢?其实这取决于BGP第一次学习到的路由,学习到后他就记录下来,另外一条就会忽略掉。由于数据包是根据CEF转发的,所以GSR会把针对每条路由,最开始学到的邻接信息记录下来,所以形成CEF表最终能看到来自每个下一跳路由中的1条路由。根据这个,可以到做个测试,例如如果现在选F1/0,down掉F1/0后,然后再开启f1/0看看结果。
另外需要注意的是,GSR的RP与LC之间是同步CEF信息的,但由于不支持多层CEF,所以第二次查找的结果可能不准确,也就是当第二次查询结果改变后,RP不会更新给LC(在试验中没有看到这种现象,在现网上有类似的现象),它只保持第一次查找正确即可。不过对于递归的路由,无非就是BGP和静态路由会有这种问题,其他IGP是不存在这种问题的,因为他们都会学到邻居的地址。
另在基于CEF的负载均衡,类似Netflow,由不同的条件去Match每一个包,符合同样条件的数据包就组成了一个Session,思科设备会对这个session进行负载均衡。在大部分硬件转发平台,默认支持per-destination的负载均衡,所以如果流量类型比较少,根据目的地址得出的session就会少,经过HASH所得到不同结果也少,那么就会发成负载不均衡的现象。另外注意其实基于CEF的负载均衡与其说是“load-balance”,不如说是“load-share”,因为对于路由交换设备而言,无法支持应用层的负载均衡,所以无法达到非常均衡。下面是CoreA的相关信息:
CoreA#sh ip route 22.22.22.22 Routing entry for 22.22.22.22/32 Known via "bgp 11", distance 20, metric 0 Tag 23, type external Last update from 2.2.2.2 00:21:24 ago Routing Descriptor Blocks: * 3.3.3.3, from 3.3.3.3, 00:21:24 ago Route metric is 0, traffic share count is 1 AS Hops 1 Route tag 23 2.2.2.2, from 2.2.2.2, 00:21:24 ago Route metric is 0, traffic share count is 1 AS Hops 1 Route tag 23 CoreA#sh ip bgp 22.22.22.22 BGP routing table entry for 22.22.22.22/32, version 2 Paths: (2 available, best #2, table Default-IP-Routing-Table) Multipath: eBGP Advertised to update-groups: 1 23 3.3.3.3 from 3.3.3.3 (3.3.3.3) Origin IGP, metric 0, localpref 100, valid, external, multipath 23 2.2.2.2 from 2.2.2.2 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, external, multipath, best CoreA#sh ip cef 22.22.22.22 inter 22.22.22.22/32, version 32, epoch 0, per-destination sharing 0 packets, 0 bytes via 3.3.3.3, 0 dependencies, recursive traffic share 1 next hop 33.1.1.2, FastEthernet3/0 via 3.3.3.3/32 valid adjacency via 2.2.2.2, 0 dependencies, recursive traffic share 1 next hop 11.1.1.2, FastEthernet1/0 via 2.2.2.2/32 valid adjacency 0 packets, 0 bytes switched through the prefix tmstats: external 0 packets, 0 bytes internal 0 packets, 0 bytes 30 second output rate 0 Kbits/sec High water mark 0, low water mark 0, current trigger set on no NHRP interface Load distribution: 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 (refcount 1) Hash OK Interface Address Packets 1 Y FastEthernet3/0 33.1.1.2 0 2 Y FastEthernet1/0 11.1.1.2 0 3 Y FastEthernet3/0 33.1.1.2 0 4 Y FastEthernet1/0 11.1.1.2 0 5 Y FastEthernet3/0 33.1.1.2 0 6 Y FastEthernet1/0 11.1.1.2 0 7 Y FastEthernet3/0 33.1.1.2 0 8 Y FastEthernet1/0 11.1.1.2 0 9 Y FastEthernet3/0 33.1.1.2 0 10 Y FastEthernet1/0 11.1.1.2 0 11 Y FastEthernet3/0 33.1.1.2 0 12 Y FastEthernet1/0 11.1.1.2 0 13 Y FastEthernet3/0 33.1.1.2 0 14 Y FastEthernet1/0 11.1.1.2 0 15 Y FastEthernet3/0 33.1.1.2 0 16 Y FastEthernet1/0 11.1.1.2 0 refcount 6
根据上面的信息,对于每个session而言,出去的道路只能能从f1/0和f3/0中选择一条。更多关于CEF负载均衡的思科官方文档,请看我以前文章《7609 Load Balance Issue and Polarization》中的相关链接。以上是我在12.4(25d)下测试的结果,换成12.4(22)T后,发现已经支持Multi Hierarchical CEF,如下所示:
CoreA#sh ip cef 22.22.22.22 inter 22.22.22.22/32, epoch 0, RIB[B], refcount 5, per-destination sharing sources: RIB 1000 packets, 100000 bytes switched to the prefix feature space: IPRM: 0x00018010 subblocks: gsb PPC(2): 0x66B652C8 ifnums: FastEthernet1/0(5): 11.1.1.2 FastEthernet2/0(6): 22.1.1.2 FastEthernet3/0(7): 33.1.1.2 FastEthernet4/0(8): 44.1.1.2 path 67E6AD98, path list 67E69B70, share 1/1, type recursive nexthop, for IPv4, flags resolved recursive via 2.2.2.2[IPv4:Default], fib 66B60EF8, 1 terminal fib path 67E6B1AC, path list 67E69E68, share 1/1, type attached nexthop, for IPv4 nexthop 11.1.1.2 FastEthernet1/0, adjacency IP adj out of FastEthernet1/0, addr 11.1.1.2 66B6E600 path 67E6B220, path list 67E69E68, share 1/1, type attached nexthop, for IPv4 nexthop 22.1.1.2 FastEthernet2/0, adjacency IP adj out of FastEthernet2/0, addr 22.1.1.2 66B6E4C0 path 67E6AC3C, path list 67E69B70, share 1/1, type recursive nexthop, for IPv4, flags resolved recursive via 3.3.3.3[IPv4:Default], fib 66B60E78, 1 terminal fib path 67E6B0C4, path list 67E69E1C, share 1/1, type attached nexthop, for IPv4 nexthop 33.1.1.2 FastEthernet3/0, adjacency IP adj out of FastEthernet3/0, addr 33.1.1.2 67E6B760 path 67E6B138, path list 67E69E1C, share 1/1, type attached nexthop, for IPv4 nexthop 44.1.1.2 FastEthernet4/0, adjacency IP adj out of FastEthernet4/0, addr 44.1.1.2 67E6B620 output chain: PushCounter(PPC) loadinfo 67A4CC68, per-session, 4 choices, flags 0003, 6 locks flags: Per-session, for-rx-IPv4 16 hash buckets < 0 > PushCounter(NRC:2.2.2.2/32) IP adj out of FastEthernet1/0, addr 11.1.1.2 66B6E600 < 1 > PushCounter(NRC:2.2.2.2/32) IP adj out of FastEthernet2/0, addr 22.1.1.2 66B6E4C0 < 2 > PushCounter(NRC:3.3.3.3/32) IP adj out of FastEthernet3/0, addr 33.1.1.2 67E6B760 < 3 > PushCounter(NRC:3.3.3.3/32) IP adj out of FastEthernet4/0, addr 44.1.1.2 67E6B620 < 4 > PushCounter(NRC:2.2.2.2/32) IP adj out of FastEthernet1/0, addr 11.1.1.2 66B6E600 < 5 > PushCounter(NRC:2.2.2.2/32) IP adj out of FastEthernet2/0, addr 22.1.1.2 66B6E4C0 < 6 > PushCounter(NRC:3.3.3.3/32) IP adj out of FastEthernet3/0, addr 33.1.1.2 67E6B760 < 7 > PushCounter(NRC:3.3.3.3/32) IP adj out of FastEthernet4/0, addr 44.1.1.2 67E6B620 < 8 > PushCounter(NRC:2.2.2.2/32) IP adj out of FastEthernet1/0, addr 11.1.1.2 66B6E600 < 9 > PushCounter(NRC:2.2.2.2/32) IP adj out of FastEthernet2/0, addr 22.1.1.2 66B6E4C0 <10 > PushCounter(NRC:3.3.3.3/32) IP adj out of FastEthernet3/0, addr 33.1.1.2 67E6B760 <11 > PushCounter(NRC:3.3.3.3/32) IP adj out of FastEthernet4/0, addr 44.1.1.2 67E6B620 <12 > PushCounter(NRC:2.2.2.2/32) IP adj out of FastEthernet1/0, addr 11.1.1.2 66B6E600 <13 > PushCounter(NRC:2.2.2.2/32) IP adj out of FastEthernet2/0, addr 22.1.1.2 66B6E4C0 <14 > PushCounter(NRC:3.3.3.3/32) IP adj out of FastEthernet3/0, addr 33.1.1.2 67E6B760 <15 > PushCounter(NRC:3.3.3.3/32) IP adj out of FastEthernet4/0, addr 44.1.1.2 67E6B620 Subblocks: Hash Bucket Usage: Bucket/Choice Packets Bytes Usage Histogram < 0/0 > 0 0 0.0% < 1/1 > 1000 100000 50.0% ========== < 2/2 > 0 0 0.0% < 3/3 > 1000 100000 50.0% ========== < 4/0 > 0 0 0.0% < 5/1 > 0 0 0.0% < 6/2 > 0 0 0.0% < 7/3 > 0 0 0.0% < 8/0 > 0 0 0.0% < 9/1 > 0 0 0.0% <10/2 > 0 0 0.0% <11/3 > 0 0 0.0% <12/0 > 0 0 0.0% <13/1 > 0 0 0.0% <14/2 > 0 0 0.0% <15/3 > 0 0 0.0% ----------------------------------------------- Totals 2000 200000 100.0% (ideal:6.2%) Choice usage: Choice/Share Packets Bytes Usage Histogram < 0/1 > 0 0 0.0% < 1/1 > 1000 100000 50.0% ========== < 2/1 > 0 0 0.0% < 3/1 > 1000 100000 50.0% ========== ----------------------------------------------- Totals 2000 200000 100.0%
解决
很显然,解决方法有两种:
1. 换软件版本或换平台
2. 只让CEF递归一层,如上例子,把BGP多跳改成直连,这样就可以实现四条链路负载分担了。
版权声明:
本文链接:Multi Hierarchical CEF / Load Share
版权声明:本文为原创文章,仅代表个人观点,版权归 Frank Zhao 所有,转载时请注明本文出处及文章链接