Cisco 6509 BGPテーブルがTCAMで2つのエントリを使用するのはなぜですか。

Cisco 6509に問題があります。BGPテーブルの各エントリがTCAMの2つのエントリを占めています。容量転送を表示すると、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にある可能性がありますか？

BRFが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

ああ、6500。私は小規模なサービスプロバイダーネットワークを実行し、6500をPEルーターとして実行しています。私の人生の最悪の決定。（それは装飾された声明でしたが、あなたは私の主張を理解します。）

私はVRFで完全なBGPルートを実行し、これを取り巻く多くの問題を経験しました。

あなたの例はそれほど驚くべきことではありません。ダニエルが彼の投稿で述べたように、各VRFプレフィックスのLFIBエントリとVPNv4エントリがあります。これは、前述のようにコマンドmpls label mode vrf Internet protocol all-afs per-vrfを追加することで変更できます。ただし、これで森から抜け出すことはできません。VRFごとのプレフィックスに変更すると、LFIBエントリは削除されますが（yay！）、隣接テーブルにすべてのプレフィックスのエントリが追加されます（待機、何ですか？）。6500転送ハードウェアはL2転送とL3転送で共有されるため、ハードウェアメモリの使用量はまったく変わりません。どちらかと言えば、問題を見つけるのが難しくなります。

VRFごとの使用に変更した後（を使用してshow platform hardware cef resource-level）使用状況を確認すると、問題を修正したように見えます。ただし、コマンドを使用するshow platform hardware cef adjacencies resource-levelと、問題が別の場所に移動したことがわかります。

以下は、私の6500のリソースレベルと隣接使用の1つからの出力です。私が話していることの概要。

リソースレベル

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の投稿は、ここでの私の発見に基づいていました。現在、シスコと協力してこの問題の修正を試みていますが、残念ながら現在のところ、これを修正する方法はありません。

MPLS隣接がないため、距離は異なる場合があります。変更を加えたので、隣接の使用状況を確認することに関心があります。