Resolución de Problemas de CPU Alto Causados por el Proceso de Router o Escáner BGP

Nota: El uso elevado de la CPU en el dispositivo también podría deberse a la inestabilidad de la tabla BGP. Esto sucede si el router recibe dos copias de la tabla de ruteo, una del peering EBGP con el ISP y la otra del peering IBGP en la red. La causa raíz de esto es la cantidad de memoria en el dispositivo. Cisco recomienda un mínimo de 1 Gig de RAM para una sola copia de la tabla de ruteo de Internet. Para eludir esta inestabilidad, aumente la RAM en el dispositivo o filtre los prefijos para que la tabla BGP y la memoria ocupada por ella se alivien.

Mejoras de rendimiento

A medida que crece el número de rutas en la tabla de ruteo de Internet, también aumenta el tiempo que tarda BGP en converger. En general, la convergencia se define como el proceso cuando todas las tablas de ruta llegan a un estado de consistencia. BGP se considera convergente cuando estas condiciones son verdaderas:

• Todos los routers han sido aceptados.

• Todas las rutas han sido instaladas en la tabla de ruteo.

• La versión de tabla para todos los peers es igual a la versión de tabla de la tabla BGP.

• El InQ y OutQ para todos los peers es cero.

Esta sección describe algunas mejoras en el rendimiento de Cisco IOS para reducir el tiempo de convergencia de BGP, lo que resulta en una reducción de una condición de CPU alta debido a un proceso BGP.

Cola a conexiones de par TCP

El BGP ahora coloca los datos de forma agresiva desde el BGP OutQ al socket TCP para cada peer hasta que las OutQs se hayan drenado completamente. Dado que BGP ahora transmite a mayor velocidad, BGP converge más rápidamente.

Grupos de Pares BGP

Aunque ayudan a simplificar la configuración de BGP, los grupos de peers BGP también pueden mejorar la escalabilidad. Todos los miembros de grupos de pares deben compartir una política de salida común. Por lo tanto, se pueden enviar los mismos paquetes de actualización a cada miembro del grupo y esto reduce el número de ciclos de CPU que BGP requiere para anunciar rutas a los pares. En otras palabras, con grupos de pares, BGP recorre la tabla de BGP sólo en el líder del grupo de pares, filtra los prefijos a través de las políticas de salida y genera actualizaciones, que envía al líder del grupo de pares. A su vez, el líder replica las actualizaciones en los miembros del grupo con los que está sincronizado. Sin grupos de peers, BGP debe recorrer la tabla para cada peer, filtrar los prefijos a través de las políticas salientes y generar actualizaciones que se envían solamente al peer único.

MTU de trayecto y el comando ip tcp path-mtu-discovery

Todas las sesiones TCP están limitadas por un límite en el número de bytes que se pueden transportar en un solo paquete. El tamaño predeterminado de de este límite, conocido como Tamaño de segmento máximo (MSS), es 536 bytes. En otras palabras, el TCP divide los paquetes en una cola de transmisión en fragmentos de 536 bytes antes de pasar los paquetes a la capa IP. Utilice el comando show ip bgp neighbors | incluye el comando max data para mostrar el MSS de peers BGP:

Router#show ip bgp neighbors | include max data 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 

La ventaja de una MSS de 536 bytes es que no es probable que los paquetes sean fragmentados en un dispositivo IP a lo largo del trayecto al destino, dado que la mayoría de los links utiliza una MTU de 1500 bytes como mínimo. La desventaja es que los paquetes más pequeños aumentan la cantidad de ancho de banda utilizado para transportar la sobrecarga. Dado que BGP construye una conexión TCP con todos los peers, un MSS de 536 bytes afecta los tiempos de convergencia de BGP.

La solución es habilitar la función Path MTU (PMTU) con el comando ip tcp path-mtu-discovery. Puede utilizar esta función para determinar dinámicamente el tamaño del valor MSS y, mientras tanto, no crear paquetes que deban fragmentarse. PMTU permite a TCP determinar el tamaño de MTU más pequeño entre todos los links en una sesión TCP. Luego, TCP utiliza este valor MTU, menos espacio para los encabezados IP y TCP, como MSS para la sesión. Si una sesión TCP sólo atraviesa segmentos Ethernet, el MSS es de 1460 bytes. Si sólo atraviesa los segmentos de paquete sobre SONET (POS), el MSS es de 4430 bytes. El aumento de MSS de 536 a 1460 o 4430 bytes reduce la sobrecarga TCP/IP, lo que ayuda a que el BGP converja más rápido.

Después de habilitar PMTU, utilice nuevamente el comando show ip bgp neighbors | incluye el comando max data para ver el valor de MSS por peer:

Router#show ip bgp neighbors | include max data 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 

Aumentar las colas de entrada de interfaz

Si el BGP anuncia miles de rutas a muchos peers, el TCP debe transmitir miles de paquetes en una corta duración. Los peers BGP reciben estos paquetes y envían reconocimientos TCP al altavoz BGP que anuncia, lo que hace que el altavoz BGP reciba una inundación de ACK TCP en un corto período de tiempo. Si los ACK (Acuse de recibo) llegan a una velocidad demasiado alta para el procesador de ruta, los paquetes se almacenan en colas de interfaz entrantes. De forma predeterminada, las interfaces de ruta utilizan un tamaño de cola de entrada de 75 paquetes. Además, los paquetes de control especiales como BGP UPDATES utilizan una cola especial con descarte selectivo de paquetes (SPD). Esta cola especial contiene 100 paquetes. Cuando se produce la convergencia de BGP, los ACK de TCP pueden llenar rápidamente los 175 puntos de almacenamiento en búfer de entrada y los nuevos paquetes que llegan deben descartarse. En los routers con 15 o más peers BGP e intercambio de la tabla de ruteo de Internet completa, se pueden ver más de 10.000 caídas por interfaz por minuto. A continuación se proporciona un ejemplo de salida desde un router 15 minutos posteriores al reinicio:

Router#show interface pos 8/0 | include input queue 
Output queue 0/40, 0 drops; input queue 0/75, 278637 drops 
Router#

Si aumenta la profundidad de la cola de entrada de la interfaz (con el comando hold-queue in), ayuda a reducir el número de ACK TCP descartados, lo que reduce la cantidad de trabajo que el BGP debe hacer para converger. Normalmente, un valor de 1000 resuelve los problemas causados por las caídas de la cola de entrada.

Nota: Utilice esto conscientemente, ya que el incremento de la cola de entrada puede añadir algún retraso.

Mejoras adicionales en Cisco IOS

Cisco IOS incluye varias optimizaciones al código de grupo de peers BGP para mejorar el empaquetado y la replicación de actualizaciones. Antes de revisar estas mejoras, revise con más detalle el paquete de actualización y la replicación.

Una actualización de BGP consta de una combinación de atributos (como MED = 50 y LOCAL_PREF = 120) y una lista de prefijos de Información de disponibilidad de capa de red (NLRI) que comparten esa combinación de atributos. Cuanto más prefijos NLRI puedan enumerarse los BGP en una sola actualización, más rápido puede converger el BGP, ya que se reduce la sobrecarga (como encabezados IP, TCP y BGP). El paquete de actualización se refiere al empaquetado de NLRI en las actualizaciones de BGP. Por ejemplo, si una tabla de BGP contiene 100.000 rutas con 15.000 combinaciones de atributos únicas, BGP necesita enviar sólo 15.000 actualizaciones si el NLRI está empaquetado con una eficiencia del 100%.

Nota: El cero por ciento de eficiencia de empaquetado significa que BGP necesitaría enviar 100.000 actualizaciones en este entorno.

Use el comando show ip bgp peer-group para ver la eficiencia de las actualizaciones de BGP.

Si un miembro del grupo de peers está sincronizado, un router BGP toma un mensaje de actualización formateado para el líder del grupo de peers y lo replica para el miembro. Resulta más eficaz replicar una actualización para un miembro de grupo de pares que darle un nuevo formato a la actualización. Por ejemplo, supongamos que un grupo de pares tiene 20 miembros y todos los miembros necesitan recibir 100 mensajes BGP. Una replicación de cien por ciento significa que un router BGP formatea los 100 mensajes para el líder del grupo de pares y duplica esos mensajes a los otros 19 miembros del grupo de pares. Para confirmar las mejoras en la replicación, compare el número de mensajes replicados con el número de mensajes formateados, como se muestra en el comando show ip bgp peer-group. Las mejoras marcan una diferencia importante en los tiempos de convergencia y permiten que BGP sea compatible con más pares.

Por ejemplo, utilice el comando show ip bgp peer-group para verificar la eficiencia del empaquetado de actualizaciones y la replicación de actualizaciones. El siguiente resultado es de una prueba de convergencia con 6 grupos de peers, 20 peers en cada uno de los primeros 5 grupos de peers (peers eBGP) y 100 peers en el sexto grupo de peers (peers BGP interno (iBGP)). Además, la tabla BGP que se utilizó tenía 36.250 combinaciones de atributos.

El siguiente ejemplo de salida de show ip bgp peer-group | incluyen el comando replicado en un router que ejecuta Cisco IOS 12.0(18)S muestra esta información:

Update messages formatted 836500, replicated 1668500 
Update messages formatted 1050000, replicated 1455000 
Update messages formatted 660500, replicated 1844500 
Update messages formatted 656000, replicated 1849000 
Update messages formatted 501250, replicated 2003750 

!-- The first five lines are for eBGP peer groups.
 
Update messages formatted 2476715, replicated 12114785 

!-- The last line is for an iBGP peer group.

Para calcular la tasa de replicación para cada grupo de peers, divida el número de actualizaciones replicadas por el número de actualizaciones formateadas:

1668500/836500 = 1,99 1455000/1050000 = 1,38 1844500/660500 = 2,79 184 9000/656000 = 2,81 2003750/501250 = 3,99 12114785/2476715 = 4,89

• Si BGP se replica perfectamente, entonces los grupos de peers eBGP tienen cada uno una tasa de replicación de 19 porque hay 20 peers en el grupo de peers. La actualización se formatea para el líder del grupo de peers y luego se replica a los otros 19 peers. Esto proporciona una tasa de replicación óptima de 19. La tasa de replicación ideal para el grupo de peers iBGP sería 99 ya que hay 100 peers.
• Si el BGP empaqueta las actualizaciones perfectamente, sólo hay 36.250 actualizaciones formateadas. Sólo necesita generar 36.250 actualizaciones para cada grupo de peers porque ese es el número de combinaciones de atributos en la tabla BGP. El grupo de pares iBGP formatea 2,500,000 actualizaciones aproximadamente mientras que cada grupo de pares eBGP genera de 500,000 a 1,000,000 de actualizaciones.

En un router que ejecuta Cisco IOS 12.0(19)S, show ip bgp peer-group | include replicatedcommand proporciona esta información:

Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 3588750

Nota: El empaquetado de actualización es óptimo. Se les da formato a exactamente 36.250 actualizaciones para cada grupo de interlocutores. 688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 3588750/36250 = 99

Nota: La duplicación de la actualización también es perfecta.

Procedimientos de Troubleshooting

Utilice estos procedimientos para resolver problemas de CPU alta debido al escáner BGP o al router BGP:

• Recopile información sobre su topología BGP. Determine el número de peers BGP y el número de rutas anunciadas por cada peer. ¿La duración de la condición razonable alta de la CPU se relaciona con su entorno?

• Determine cuándo ocurre la CPU alta. ¿Coincide con un recorrido regularmente programado de la tabla de BGP?

• ¿La alta CPU siguió la inestabilidad de interfaz? Puede utilizar el comando show ip bgp dampening flap-statistics si está habilitado el dampening.

• Realice un ping a través del router y luego otro desde el router. Los ecos de ICMP se administran como un proceso de prioridad baja. El documentoIntroducción a los comandos Ping y Traceroute explica esto con más detalle. Asegure que los reenvíos periódicos no sean afectados.

• Debe asegurarse de que los paquetes puedan seguir un trayecto de reenvío rápido cuando verifique si fast switching y/o CEF están habilitados en las interfaces de entrada y de salida. Asegúrese de no ver el comando no ip route-cache cef en la interfaz o el comando no ip cef en la configuración global. Para habilitar CEF en el modo de configuración global, utilice el comando ip cef.

• Verifique la escalabilidad de la plataforma porque, en la mayoría de los casos, se debe a un dispositivo sobrecargado que conduce a tales situaciones. Además, se garantiza que haya espacio adecuado de memoria direccionable de contenido ternario (TCAM) disponible en el router.

• Verifique que haya suficiente memoria en el router. Según la recomendación, tenga un mínimo de 1 GB de DRAM asignado al espacio del IOS de Cisco por peer BGP que envía la tabla de ruteo de Internet completa. El espacio DRAM mencionado aquí es sólo la memoria requerida para BGP. Otras funciones que se ejecutan en el router pueden requerir espacio adicional.

Información Relacionada

• Página de Soporte de IP Routing
• Soporte Técnico - Cisco Systems