为什么我的Cisco 6509 BGP表在TCAM中使用两个条目?


10

我在Cisco 6509上有问题,我的BGP表中的每个条目都在TCAM中占据了两个条目。如果显示容量转发,则会在L3转发资源中看到MPLS条目。但是,我不在机箱上使用MPLS!

#show run | i mpls
mls cef maximum-routes mpls 508
no mpls ldp advertise-labels
no mpls ip

和我的L3 Forwading:

L3 Forwarding Resources
             FIB TCAM usage:                     Total        Used       %Used
                  72 bits (IPv4, MPLS, EoM)     1032192      899612         87%
                 144 bits (IP mcast, IPv6)        8192           7          1%

                     detail:      Protocol                    Used       %Used
                                  IPv4                      450051         44%
                                  MPLS                      449560         44%
                                  EoM                            1          1%

                                  IPv6                           1          1%
                                  IPv4 mcast                     3          1%
                                  IPv6 mcast                     3          1%

            Adjacency usage:                     Total        Used       %Used
                                               1048576      448758         43%

任何的想法?路由是否在VRF中?


+1有趣的问题。您可以添加您的IOS版本以与Bigmstone的答案进行比较吗?
jwbensley

糟糕,我的IOS版本是s72033_rp-ADVENTERPRISEK9_WAN-M-版本12.2(33)SXH3a
Johann M.

Answers:


10

如果BGP在VRF中运行,则6500似乎会为每个路由生成MPLS标签。您的IPv4和MPLS TCAM用法几乎相同的事实似乎也表明了这一点。您可以尝试以下命令:

show bgp vpnv4 uni all labels

似乎有一个隐藏的命令使IOS为每个VRF而不是每个前缀分配标签。

mpls label mode all-vrfs protocol bgp-vpnv4 per-vrf

这是一个隐藏命令,因此IOS将不会显示它。同样在运行之前,您可以尝试运行:

show ip vrf detail

1
是的,每个前缀BGP我都有一个标签! #mpls label mode all-vrfs protocol bgp-vpnv4 per-vrf 嗡嗡声很好,但警告。我现在看到所有前缀的都是“ IPv4 VRF Aggr:16” :)等一下,... IPv4 449979 44% MPLS 8 1% 好!谢谢您:-)
Johann M.

7

哦6500。我运行一个小型服务提供商网络,并将6500作为PE路由器运行。我一生中最糟糕的决定。(那是一个含蓄的说法,但是你明白我的意思。)

我在VRF中运行完整的BGP路由,并且遇到了很多与此相关的问题。

您的榜样并不令人惊讶。正如Daniel在他的帖子中所说,每个VRF前缀都有一个LFIB条目,以及VPNv4条目。可以通过添加命令来更改它mpls label mode vrf Internet protocol all-afs per-vrf;但是,这并不能使您摆脱困境。如果更改为每个VRF前缀,它的确会删除LFIB条目(是!),但会将每个单个前缀的条目添加到Adjacency表中(等待,什么?!)。由于6500转发硬件在L2和L3转发之间共享,因此这根本不会改变您的硬件内存使用情况。如果有的话,使问题更难发现。

如果您已更改为每个VRF使用情况(使用show platform hardware cef resource-level)来查看使用情况,则好像已解决了该问题。但是,如果使用该命令,show platform hardware cef adjacencies resource-level则表明问题刚刚移至其他位置。

以下是我6500的资源级别和邻接用法之一的输出。概述我在说什么。

资源级别

Global watermarks: apply to Fib shared area only.
Protocol watermarks: apply to protocols with non-default max-routes

Fib-size: 1024k (1048576), shared-size: 1016k (1040384), shared-usage: 458k(469769)

Global watermarks:
            Red_WM: 95%,   Greem_WM: 80%,   Current usage: 45%

Protocol watermarks:

 Protocol           Red_WM(%)      Green_WM(%)     Current(%)
 --------           ---------      ----------      ----------
 IPV4                --             --              42% (of shared)
 IPV4-MCAST          --             --              0 % (of shared)
 IPV6                --             --              2 % (of shared)
 IPV6-MCAST          --             --              0 % (of shared)
 MPLS                --             --              0 % (of shared)
 EoMPLS              --             --              0 % (of shared)
 VPLS-IPV4-MCAST     --             --              0 % (of shared)
 VPLS-IPV6-MCAST     --             --              0 % (of shared)

邻接用法

Watermarks apply to regions available for allocation and not pre-reserved
Stats region size for alloc:        444160
Non-stats region size for alloc:    376832

Adjacency Mgr watermarks:

 Type             Red_WM(%)      Green_WM(%)     Current usage(%)
 ----             ---------      ----------      ----------------
 Stats_WM         95%            80%             97%
 Non-Stats_WM     95%            80%             14%

伊万(Ivan)在此的帖子是基于我在这里的发现。我目前正在与Cisco合作,尝试解决此问题,但是很遗憾,目前尚无办法解决此问题。

由于没有MPLS邻接关系,因此您的里程可能会有所不同。进行更改后,有兴趣查看您的邻接使用情况。


+1丹尼尔斯答案的绝佳补充。在阅读您的答案时,我想到的是Ivan的帖子,然后看到您已经链接了它:)您说您打算与Cisco合作解决方案,我认为这是TAC案。您可以将您的IOS版本添加到帖子中吗?
jwbensley

很棒的评论!但是奇怪的show platform hardware cef [...]是我的C6509中不存在。但如果我看到show cef fib,它的可怕: Totals : 96942392/97131416 ( 99%) [4296]ADJ: adjacency : 132616/132792 ( 99%) [4]
约翰M.

我是SUP2T。我猜你是SUP720?
bigmstone

@javno,我相信15.1(1)SY。笨拙的机场无线设备对VPN太懒了。我会确认并编辑是否需要更改...但是我很确定这就是我正在运行的内容。是的,我有一个TAC案件已经开放了大约6个月。与几个工程师一起研究如何最好地解决它。我试图说服他们实现每个下一跳标签...我们将看到。
bigmstone

@bigmstone:是的,我SUP720(3BXL)
约翰M.
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.