Multi Hierarchical CEF / Load Share
25 3 月, 2012,由 frank撰写
环境
--------+--------------------+---------
| 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 所有，转载时请注明本文出处及文章链接