Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Convenciones

Antecedentes

Comprensión de los Procesos BGP

Alto uso de CPU debido al escáner BGP

CPU elevado debido a proceso de router BGP

Mejoras de rendimiento

Cola a conexiones de par TCP

Grupos de Pares BGP

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

Aumentar las colas de entrada de interfaz

Mejoras adicionales en Cisco IOS

Procedimientos de Troubleshooting

Información Relacionada

Introducción

Este documento describe cómo resolver la causa de las lecturas de CPU altas cuando se utiliza el Escáner BGP o el Router.

Prerequisites

Requirements

Este documento requiere un conocimiento de cómo interpretar el comando show process cpu.

Componentes Utilizados

La información que contiene este documento se basa en la versión 12.0 de software del IOS® de Cisco.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Antecedentes

Este documento describe situaciones en las que un router Cisco IOS puede experimentar una alta utilización de la CPU debido al proceso del router BGP o al proceso del escáner BGP, como se muestra en la salida del comando show process cpu. La duración del funcionamiento elevado de la CPU varía según varias condiciones, en particular el tamaño de la tabla de ruteo de Internet y el número de rutas que mantiene un router determinado en sus tablas de ruteo y BGP. El comando show process cpu muestra la tasa de utilización de la CPU en los últimos cinco segundos, un minuto y cinco minutos. Los números de uso de la CPU no proveen una verdadera indicación lineal de la utilización con respecto a la carga ofrecida.

Estas son algunas de las principales razones:

- En una red del mundo real, la CPU debe operar con diversas funciones de mantenimiento de sistema, por ejemplo la administración de la red.

- La CPU debe procesar las actualizaciones de ruteo periódicas y las generadas por un evento.

- Hay otras operaciones de sobrecarga interna del sistema, como sondeo para la disponibilidad de recursos, que no son proporcionales a la carga de tráfico.

También puede utilizar el comando show processes cpu para obtener alguna indicación de la actividad de la CPU.

Nota: Para obtener más información sobre los comandos show, vea la Referencia de Comandos de los Aspectos Fundamentales de la Configuración de Cisco IOS

Comprensión de los Procesos BGP

Un proceso de Cisco IOS, en general, consta de subprocesos individuales y datos asociados que realizan tareas, como el mantenimiento del sistema, el switching de paquetes y la implementación de protocolos de ruteo. Varios procesos de Cisco IOS ejecutados en el router permiten que se ejecute BGP. Utilice la CPU show process | incluyen el comando BGP para ver la cantidad de uso de la CPU debido a los procesos BGP.

Esta tabla enumera la función de los procesos BGP y muestra que cada proceso se ejecuta en momentos diferentes, y que esas veces dependen de las tareas que se manejan. Debido a que los procesos del escáner BGP y del router BGP son responsables de una gran cantidad de cálculos, puede ver una CPU alta debido a cualquiera de estos procesos. En las secciones siguientes se analizan estos procesos con mayor detalle.

Nombre del proceso

Descripción

Intervalo

Abierto BGP

Establece los pares BGP.

En la inicialización, cuando se establece una conexión TCP con un peer BGP.

BGP I/O

Maneja los paquetes BGP que están en la cola y se procesan, como ACTUALIZACIONES y KEEPALIVES.

A medida que se reciben los paquetes de control de BGP.

Escáner BGP

Recorre la tabla BGP y confirma el alcance del próximo salto. El escáner BGP también verifica el anuncio condicional para determinar si BGP anuncia los prefijos de condición y realiza la reducción de ruta. En un entorno de VPN MPLS, el escáner BGP importa y exporta rutas a una instancia de routing y reenvío de VPN (VRF) determinada.

Una vez por minuto.

Router BGP

Calcula la mejor trayectoria BGP y procesa cualquier pérdida de ruta. También envía y recibe rutas, establece pares e interactúa con la base de información de ruteo (RIB).

Una vez por segundo y cuando se agrega, elimina o configura mediante software un par BGP.

Alto uso de CPU debido al escáner BGP

Se puede esperar una CPU alta debido al proceso del escáner BGP para duraciones cortas en un router que transporta una tabla de ruteo de Internet grande. Una vez por minuto, el escáner BGP camina por la tabla RIB BGP y desarrolla importantes tareas de mantenimiento. Estas tareas incluyen el examen del siguiente salto al que se hace referencia en la tabla BGP del router y verifica que se puedan alcanzar los dispositivos del siguiente salto. Por lo tanto, una tabla de BGP grande tarda una cantidad equivalente de tiempo en ser analizada y validada.

Debido a que el proceso de Escáner BGP se ejecuta a través de toda la tabla BGP, la duración de la condición de CPU alta varía con el número de vecinos y el número de rutas aprendidas por vecino. Para capturar esta información, use los comandos show ip bgp summary y show ip route summary. El proceso del escáner BGP recorre la tabla BGP para actualizar cualquier estructura de datos y recorre la tabla de ruteo con fines de redistribución de rutas. (En este contexto, la tabla de routing también se conoce como base de información de routing (RIB), que el router emite cuando ejecuta el comando ;show ip route). Ambas tablas se almacenan por separado en la memoria del router y pueden ser grandes y consumir ciclos de CPU.

El siguiente ejemplo de salida del comando debug ip bgp updates captura una ejecución del escáner BGP:

router#

2d17h: BGP: scanning routing tables

2d17h: BGP: 10.0.0.0 computing updates, neighbor version 8,

table version 9, starting at 0.0.0.0

2d17h: BGP: 10.0.0.0 update run completed, ran for 0ms, neighbor

version 8, start version 9, throttled to 9, check point net 0.0.0.0

2d17h: BGP: 10.1.0.0 computing updates, neighbor version 8,

table version 9, starting at 0.0.0.0

2d17h: BGP: 10.1.0.0 update run completed, ran for 4ms, neighbor

version 8, start version 9, throttled to 9, check point net 0.0.0.0

router#

Mientras se ejecuta el escáner BGP, los procesos de baja prioridad deben esperar un período mayor de tiempo para acceder a la CPU. Un proceso de baja prioridad controla los paquetes del Protocolo de mensajes de control de Internet (ICMP) tales como pings. Los paquetes destinados o originados desde el router pueden experimentar una latencia mayor de la esperada, ya que el proceso ICMP debe esperar detrás del escáner BGP. El ciclo es que el escáner BGP se ejecuta durante algún tiempo y se suspende y luego se ejecuta ICMP. Por el contrario, los pings enviados a través de un router deben conmutarse a través de Cisco Express Forwarding (CEF) y no deben experimentar ninguna latencia adicional. Cuando resuelve problemas de picos periódicos de latencia, compare los tiempos de reenvío de los paquetes reenviados a través de un router con los paquetes procesados directamente por la CPU en el router.

Nota: Los comandos Ping que especifican las opciones IP, como la ruta de registro, también requieren que la CPU los procese directamente y esto puede causar retrasos de reenvío más prolongados.

Utilice el proceso show | incluye el comando bgp scan para ver la prioridad de la CPU. El valor de Lsi en el siguiente ejemplo de salida utiliza L para referirse a un proceso de baja prioridad.

6513#show processes | include BGP Scanner

172 Lsi 407A1BFC       29144     29130    1000 8384/9000  0 BGP Scanner

CPU elevado debido a proceso de router BGP

El proceso del router BGP se ejecuta aproximadamente una vez por segundo para verificar si hay trabajo. La convergencia BGP define la duración entre el momento en que se establece el primer peer BGP y el punto en el que se converge BGP. Para asegurar los tiempos de convergencia más cortos posibles, el router BGP consume todos los ciclos de CPU libres. Sin embargo, luego de comenzar, abandona (o suspende) la CPU de manera intermitente.

El tiempo de convergencia es una medición directa del tiempo que el router BGP pasa en la CPU, no del tiempo total. Este procedimiento muestra una condición de CPU alta durante la convergencia de BGP e intercambia prefijos BGP con dos peers BGP externos (eBGP).

1. Capture una línea de base para el uso normal de la CPU antes de iniciar la prueba.

router#show process cpu

CPU utilization for five seconds: 0%/0%; one minute: 4%; five minutes: 5%

2. Una vez que empieza la prueba, la CPU alcanza el 100% de utilización. El comando process cpucommand muestra que la condición de CPU alta es causada por el router BGP, indicado por 139 (el ID de proceso de Cisco IOS para el router BGP) en el siguiente resultado.

router#show process cpu

CPU utilization for five seconds: 100%/0%; one minute: 99%; five minutes: 81%

!--- Output omitted.

139     6795740   1020252       6660 88.34% 91.63% 74.01%   0 BGP Router

3. Puede monitorear y capturar múltiples salidas de los comandos show ip bgp summary y show process cpu en este momento. El comando show ip bgp summary captura el estado de los vecinos BGP.

router#show ip bgp summary

Neighbor    V    AS  MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down State/PfxRcd

10.0.0.0    4  64512  309453  157389    19981    0  253 22:06:44 111633

10.1.0.0  4  65101  188934    1047    40081   41    0 00:07:51 58430

4. Cuando el router completa el intercambio de prefijos con sus peers BGP, las tasas de utilización de CPU vuelven a los niveles normales. Los promedios calculados de un minuto y cinco minutos también pueden recuperarse y mostrar niveles más altos de lo normal durante un período más largo que la velocidad de cinco segundos.

router#show process cpu

CPU utilization for five seconds: 3%/0%; one minute: 82%; five minutes: 91%

5. Utilice el resultado capturado de los comandos show anteriores para calcular el tiempo de convergencia de BGP. En particular, utilice la columna Up/Down< /strong> del comando show ip bgp summary y compare las horas de inicio y parada de la condición de CPU alta. Normalmente, la convergencia de BGP puede tardar varios minutos cuando hay una tabla de ruteo de Internet grande. se intercambia

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