¿Por qué mi tabla BGP Cisco 6509 usa dos entradas en mi TCAM?


10

Tengo un problema en mi Cisco 6509, cada entrada en mi tabla BGP ocupa dos entradas en la TCAM. Si muestro el reenvío de capacidad, veo entradas MPLS en los recursos de reenvío L3. ¡Pero no uso MPLS en mi chasis!

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

Y mi vadeo L3:

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%

¿Alguna idea? ¿Podría ser que las rutas están en un VRF?


+1 Pregunta interesante. ¿Puedes agregar tu versión de IOS para compararla con la respuesta de Bigmstone?
jwbensley

Oups, mi versión de IOS es s72033_rp-ADVENTERPRISEK9_WAN-M - Versión 12.2 (33) SXH3a
Johann M.

Respuestas:


10

Parece que el 6500 genera etiquetas MPLS para cada ruta si BGP se ejecuta en VRF. El hecho de que su uso de IPv4 y MPLS TCAM es casi idéntico parece indicar esto también. ¿Puedes probar este comando?

show bgp vpnv4 uni all labels

Parece que hay un comando oculto que hace que IOS asigne etiquetas por VRF en lugar de por prefijo.

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

Este es un comando oculto, por lo que IOS no lo mostrará. También antes de ejecutar eso, puede intentar ejecutar:

show ip vrf detail

1
Sí, ¡tengo una etiqueta por prefijo BGP! #mpls label mode all-vrfs protocol bgp-vpnv4 per-vrf Hum bueno, pero una advertencia. Ahora veo "IPv4 VRF Aggr: 16" para todos los prefijos :) Espere un momento y ... IPv4 449979 44% MPLS 8 1% ¡BUENO! Gracias :-)
Johann M.

7

Oh, el 6500. Ejecuto una pequeña red de proveedores de servicios y ejecuto el 6500 como un enrutador PE. La peor decisión de mi vida. (Esa fue una declaración embellecida, pero entiendes mi punto).

Corro rutas BGP completas en un VRF y he experimentado muchos problemas en torno a esto.

Tu ejemplo no es muy sorprendente. Como dijo Daniel en su publicación, hay una entrada LFIB para cada prefijo VRF, así como una entrada VPNv4. Esto se puede cambiar agregando el comando mpls label mode vrf Internet protocol all-afs per-vrfcomo se indicó; sin embargo, esto no te saca del bosque. Si cambia a prefijos por VRF, elimina la entrada LFIB (¡sí!) Pero agrega una entrada para cada prefijo individual en la tabla de adyacencia (¡espere, qué!!). Dado que el hardware de reenvío 6500 se comparte entre el reenvío L2 y L3, esto no cambia en absoluto el uso de la memoria del hardware. En todo caso, hace que el problema sea más difícil de encontrar.

Si observa su uso una vez que ha cambiado a uso por VRF (uso show platform hardware cef resource-level), parece que ha solucionado el problema. Sin embargo, si usa el comando show platform hardware cef adjacencies resource-level, revela que el problema se acaba de mover a una ubicación diferente.

A continuación se presentan los resultados de uno de los niveles de recursos y uso de adyacencia de mi 6500. Esbozando de lo que estoy hablando.

Nivel de recurso

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)

Uso de adyacencia

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%

La publicación de Ivan sobre esto se basó en mis hallazgos aquí. Actualmente estoy trabajando con Cisco para intentar solucionar este problema, pero desafortunadamente en este momento no hay forma de solucionarlo.

Su kilometraje puede variar ya que no tiene adyacencias MPLS. Estaría interesado en ver su uso de adyacencia ahora que ha realizado el cambio.


+1 Una gran adición a la respuesta de Daniels. Estaba pensando en la publicación de Ivan mientras leía tu respuesta, luego vi que te habías vinculado a ella :) Dijiste que estabas trabajando en una solución con Cisco, que supongo que es un caso de TAC. ¿Puedes agregar a tu publicación tu versión de IOS?
jwbensley

Gran comentario! Pero extrañamente show platform hardware cef [...]no existe en mi C6509. Pero si veo show cef fib, da miedo: Totals : 96942392/97131416 ( 99%) [4296]y ADJ: adjacency : 132616/132792 ( 99%) [4]
Johann M.

Soy SUP2T Supongo que eres SUP720?
Bigmstone

@javno, creo que 15.1 (1) SY. Demasiado perezoso para VPN con esta mala conexión inalámbrica del aeropuerto. Lo confirmaré y editaré si es necesario cambiarlo ... pero estoy bastante seguro de que eso es lo que estoy ejecutando. Sí, tengo un caso de TAC que ha estado abierto durante ~ 6 meses. Trabajando con un par de ingenieros para ver la mejor manera de solucionarlo. Estoy tratando de convencerlos de que implementen según las etiquetas del próximo salto ... ya veremos.
bigmstone

@bigmstone: Sí, soy SUP720 (3BXL)
Johann M.
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.