Perché la mia tabella BGP Cisco 6509 utilizza due voci nella mia TCAM?


10

Ho un problema sul mio Cisco 6509, ogni voce nella mia tabella BGP occupa due voci nel TCAM. Se visualizzo il forwarding di capacità, vedo le voci MPLS nelle risorse di forwarding L3. Ma non utilizzo MPLS sul mio telaio!

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

E il mio 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%

Qualche idea? Potrebbe essere che i percorsi siano in un VRF?


+1 domanda interessante. Puoi aggiungere la tua versione di IOS per il confronto con la risposta di Bigmstone?
jwbensley,

Oups, la mia versione IOS è s72033_rp-ADVENTERPRISEK9_WAN-M - Versione 12.2 (33) SXH3a
Johann M.

Risposte:


10

Sembra che il 6500 generi etichette MPLS per ogni percorso se BGP viene eseguito in VRF. Il fatto che l'utilizzo di TCAM IPv4 e MPLS sia quasi identico sembra indicare anche questo. Puoi provare questo comando:

show bgp vpnv4 uni all labels

Sembra che ci sia un comando nascosto che consente a IOS di allocare etichette per VRF anziché per prefisso.

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

Questo è un comando nascosto, quindi IOS non lo mostrerà. Inoltre prima di eseguire puoi provare a eseguire:

show ip vrf detail

1
Sì, ho un'etichetta per prefisso BGP! #mpls label mode all-vrfs protocol bgp-vpnv4 per-vrf Hum hum, ma un avvertimento. Vedo ora "IPv4 VRF Aggr: 16" per tutti i prefissi :) Aspetta un momento e ... IPv4 449979 44% MPLS 8 1% BUONO! Grazie :-)
Johann M.

7

Oh 6500. Gestisco una piccola rete di provider di servizi e eseguo 6500 come router PE. La peggiore decisione della mia vita. (Era un'affermazione abbellita, ma ottieni il mio punto.)

Ho eseguito percorsi BGP completi in un VRF e ho riscontrato molti problemi a riguardo.

Il tuo esempio non è molto sorprendente. Come ha detto Daniel nel suo post, esiste una voce LFIB per ciascun prefisso VRF e una voce VPNv4. Questo può essere modificato aggiungendo il comando mpls label mode vrf Internet protocol all-afs per-vrfcome indicato; tuttavia, questo non ti fa uscire dal bosco. Se si cambia in per prefissi VRF rimuove la voce LFIB (yay!) Ma aggiunge una voce per ogni singolo prefisso nella tabella adiacenza (aspetta, cosa ?!). Poiché l'hardware di inoltro 6500 è condiviso tra l'inoltro L2 e L3, ciò non modifica affatto l'utilizzo della memoria hardware. Semmai rende il problema più difficile da trovare.

Se osservi il tuo utilizzo una volta modificato in per utilizzo VRF (utilizzo show platform hardware cef resource-level), sembra che tu abbia risolto il problema. Tuttavia, se si utilizza il comando show platform hardware cef adjacencies resource-levelrivela che il problema si è appena spostato in una posizione diversa.

Di seguito sono riportati gli output di uno dei miei 6500 a livello di risorse e utilizzo di adiacenza. Delineare ciò di cui sto parlando.

Resource-Livello

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)

Utilizzo di adiacenza

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%

Il post di Ivan su questo era basato sulle mie scoperte qui. Attualmente sto lavorando con Cisco per tentare di risolvere questo problema, ma sfortunatamente in questo momento non c'è modo di risolverlo.

Il tuo chilometraggio può variare poiché non hai adiacenze MPLS. Sarei interessato a vedere l'utilizzo della tua adiacenza ora che hai apportato la modifica.


+1 Un'ottima aggiunta alla risposta di Daniels. Stavo pensando al post di Ivan mentre stavo leggendo la tua risposta, poi ho visto che ti eri collegato ad esso :) Hai detto che stai lavorando a una soluzione con Cisco, che presumo sia un caso TAC. Puoi aggiungere al tuo post la tua versione IOS?
jwbensley,

Ottimo commento! Ma stranamente show platform hardware cef [...]non esiste nel mio C6509. Ma se vedo show cef fib, fa paura: Totals : 96942392/97131416 ( 99%) [4296]e ADJ: adjacency : 132616/132792 ( 99%) [4]
Johann M.,

Sono SUP2T. Immagino che tu sia SUP720?
bigmstone,

@javno, credo 15.1 (1) SY. Troppo pigro per la VPN con questo schifoso wireless per aeroporto. Lo confermerò e lo modificherò se deve essere cambiato ... ma sono abbastanza sicuro che è quello che sto correndo. Sì, ho un caso TAC che è aperto da circa 6 mesi. Lavorare con un paio di ingegneri per vedere come affrontarlo al meglio. Sto cercando di convincerli a implementare le etichette per il prossimo hop ... vedremo.
bigmstone,

@bigmstone: Sì, sono SUP720 (3BXL)
Johann M.,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.