Pourquoi ma table Cisco 6509 BGP utilise-t-elle deux entrées dans mon TCAM?


10

J'ai un problème sur mon Cisco 6509, chaque entrée dans ma table BGP occupe deux entrées dans le TCAM. Si je montre le transfert de capacité, je vois des entrées MPLS dans les ressources de transfert L3. Mais, je n'utilise pas MPLS sur mon châssis!

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

Et mon 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%

Une idée? Serait-ce que les routes sont dans un VRF?


+1 Question intéressante. Pouvez-vous ajouter votre version d'IOS pour comparaison avec la réponse de Bigmstone?
jwbensley

Oups, ma version IOS est s72033_rp-ADVENTERPRISEK9_WAN-M - Version 12.2 (33) SXH3a
Johann M.

Réponses:


10

Il semble que le 6500 génère des étiquettes MPLS pour chaque route si BGP est exécuté en VRF. Le fait que votre utilisation d'IPv4 et de MPLS TCAM soit presque identique semble également l'indiquer. Pouvez-vous essayer cette commande:

show bgp vpnv4 uni all labels

Il semble y avoir une commande cachée qui oblige IOS à allouer des étiquettes par VRF au lieu de par préfixe.

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

Il s'agit d'une commande masquée, donc IOS ne l'affichera pas. Aussi avant de lancer cela, vous pouvez essayer de lancer:

show ip vrf detail

1
Oui, j'ai une étiquette par préfixe BGP! #mpls label mode all-vrfs protocol bgp-vpnv4 per-vrf Hum bien, mais un avertissement. Je vois maintenant "IPv4 VRF Aggr: 16" pour tous les préfixes :) Attendez un instant et ... IPv4 449979 44% MPLS 8 1% BON! Merci :-)
Johann M.

7

Oh le 6500. Je gère un petit réseau de fournisseurs de services et j'exécute le 6500 comme un routeur PE. La pire décision de ma vie. (C'était une déclaration embellie, mais vous comprenez mon point.)

J'exécute des itinéraires BGP complets dans un VRF et j'ai rencontré beaucoup de problèmes autour de cela.

Votre exemple n'est pas très surprenant. Comme Daniel l'a dit dans son article, il existe une entrée LFIB pour chaque préfixe VRF ainsi qu'une entrée VPNv4. Cela peut être modifié en ajoutant la commande mpls label mode vrf Internet protocol all-afs per-vrfcomme indiqué; cependant, cela ne vous sort pas des bois. Si vous passez à des préfixes VRF, cela supprime l'entrée LFIB (yay!) Mais ajoute une entrée pour chaque préfixe dans la table d'adjacence (attendez, quoi?!). Étant donné que le matériel de transfert 6500 est partagé entre les transferts L2 et L3, cela ne change pas du tout l'utilisation de la mémoire matérielle. Au contraire, cela rend le problème plus difficile à trouver.

Si vous regardez votre utilisation une fois que vous êtes passé à l'utilisation VRF (en utilisant show platform hardware cef resource-level), il semble que vous ayez résolu le problème. Cependant, si vous utilisez la commande, show platform hardware cef adjacencies resource-levelelle révèle que le problème vient de se déplacer vers un emplacement différent.

Vous trouverez ci-dessous les sorties de l'une des utilisations de niveau de ressources et d'adjacence de mon 6500. Décrivant de quoi je parle.

Niveau ressource

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)

Utilisation de l'adjacence

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%

Le message d'Ivan à ce sujet était basé sur mes conclusions ici. Je travaille actuellement avec Cisco pour tenter de résoudre ce problème, mais malheureusement, il n'y a actuellement aucun moyen de résoudre ce problème.

Votre kilométrage peut varier car vous n'avez aucune contiguïté MPLS. Serait intéressé de voir votre utilisation de la contiguïté maintenant que vous avez effectué la modification.


+1 Un excellent ajout à la réponse de Daniels. Je pensais au message d'Ivan en lisant votre réponse, puis j'ai vu que vous y étiez lié :) Vous avez dit que vous travailliez sur une solution avec Cisco, qui, je suppose, est un cas TAC. Pouvez-vous ajouter à votre publication votre version IOS?
jwbensley

Grand commentaire! Mais étrangement show platform hardware cef [...]n'existe pas dans mon C6509. Mais si je vois show cef fib, ça fait peur: Totals : 96942392/97131416 ( 99%) [4296]et ADJ: adjacency : 132616/132792 ( 99%) [4]
Johann M.

Je suis SUP2T. Je suppose que tu es SUP720?
bigmstone

@javno, je crois que 15.1 (1) SY. Trop paresseux pour VPN avec ce sans fil d'aéroport de merde. Je vais le confirmer et le modifier s'il doit être changé ... mais je suis presque sûr que c'est ce que je lance. Oui, j'ai un dossier TAC ouvert depuis environ 6 mois maintenant. Travailler avec quelques ingénieurs pour voir comment le résoudre au mieux. J'essaie de les convaincre d'implémenter des étiquettes par saut suivant ... nous verrons.
bigmstone

@bigmstone: Oui, je suis SUP720 (3BXL)
Johann M.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.