Introducción
Este documento describe cómo determinar la causa de las inestabilidad de vecinos internos o externos del Protocolo de gateway fronterizo (BGP) causadas por MTU.
Prerequisites
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
- configuración de BGP
- Unidad de transmisión máxima (MTU)
Asegúrese de completar estas tareas en ambos routers BGP antes de completar los procedimientos de este documento:
- Verifique la configuración de BGP.
- Verifique que el vecino BGP sea accesible a través del Protocolo de mensajes de control de Internet (ICMP) y que no se observen caídas.
- Verifique que la interfaz conectada utilizada para el par BGP no esté sobresuscrita y no tenga caídas o errores de entrada/salida.
- Compruebe el uso de la CPU y la memoria.
Componentes Utilizados
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Problema
formulario de vecinos BGP; sin embargo, en el momento del intercambio de prefijos, el estado de BGP cae y los registros generan señales de mantenimiento hello de BGP que faltan o el otro peer termina la sesión.
Complete estos pasos para determinar si la MTU hace que los vecinos BGP se inestable:
- Utilice los siguientes comandos para verificar qué vecino está afectado y la interfaz conectada en ambos routers BGP. Si la dirección de peering es una dirección de loopback, verifique la interfaz conectada a través de la cual se puede alcanzar el loopback. Además, verifique la cola de salida BGP en ambos routers de peering. El OutQ consistente distinto de cero es una fuerte indicación de que las actualizaciones no llegan al peer debido a un problema de MTU en la trayectoria.
Router#show ip bgp summ | in InQ|10.10.10.2
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.10.10.2 4 3 64 62 3 0 0 00:00:3 2
Router#show ip route 10.10.10.2
Routing entry for 10.10.10.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via GigabitEthernet1/0
Route metric is 0, traffic share count is 1
- Verifique la MTU de la interfaz en ambos lados:
Router#show ip int g1/0 | i MTU
MTU is 1500 bytes
Router#
- Confirme el segmento de datos máximo acordado por TCP para ambos altavoces BGP:
Router#show ip bgp neigh 10.20.20.2 | inc segment
Datagrams (max data segment is 1460 bytes):
Router#
En el ejemplo anterior, 1460 es correcto ya que 20 bytes se asignan al encabezado TCP y otros 20 al encabezado IP.
- Confirme si BGP used path-mtu está habilitado:
Router#show ip bgp neigh 10.10.10.2 | in tcp
Transport(tcp) path-mtu-discovery is enabled
Router#
- Haga ping al par BGP con la MTU de interfaz máxima y el bit DF (No fragmentar) configurado:
Router#ping 10.10.10.2 size 1500 df
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
Packet sent with the DF bit set
.....
Success rate is 0 percent (0/5)
- Disminuya el valor del tamaño de ICMP para determinar el tamaño máximo de MTU que se puede utilizar:
ping 10.10.10.2 size 1300 df
Solución
Estas son algunas de las posibles causas:
- La MTU de la interfaz en ambos routers no coincide.
- La MTU de la interfaz en ambos routers coincide, pero el dominio de Capa 2 sobre el cual se forma la sesión BGP no coincide.
- La detección de MTU de trayectoria determinó el tamaño de datos máximo incorrecto para la sesión BGP TCP.
- La detección de la unidad de transmisión máxima (PMTUD) de la ruta BGP podría estar fallando debido a que se han bloqueado los paquetes ICMP de PMTUD (firewall o ACL)
A continuación se indican las formas posibles de resolver los problemas de MTU:
- La MTU de la interfaz en ambos routers debe ser la misma; ejecute el comando show ip int | en el comando MTU para verificar la configuración de MTU actual.
- Si la MTU de la interfaz en ambos routers es correcta (por ejemplo, 1500) pero las pruebas de ping con bit DF configurado no exceden 1300, entonces el dominio de Capa 2 en el que se forma la sesión BGP afectada puede incluir configuraciones de MTU inconsistentes. Verifique cada MTU de interfaz de Capa 2. Corrija la MTU de la interfaz de Capa 2 para resolver el problema.
- Si no puede verificar/cambiar el dominio de Capa 2, puede establecer el comando global ip tcp mss en un valor menor como 1000, lo que puede forzar todas las sesiones de segmento de datos TCP max originadas localmente (que incluye BGP) a 1000. Para obtener más información sobre este comando, refiérase a la sección ip tcp mss de la Referencia de Comandos de IP Application Services de Cisco IOS®.
Además, puede utilizar el comando ip tcp adjust-mss para resolver problemas adicionales; este comando se configura en el nivel de interfaz y afecta a todas las sesiones TCP. Para obtener más información sobre este comando, consulte la sección ip tcp adjust-mss de la Referencia de Comandos de IP Application Services de Cisco IOS.
- (Opcional) La detección de la unidad de transmisión máxima de la ruta BGP (PMTUD) no puede generar el tamaño de datos máximo correcto. Puede inhabilitarlo globalmente o por vecino para confirmar si esta es la causa. Cuando BGP PMTUD está inhabilitado, el tamaño máximo de segmento de BGP (MSS) predeterminado es 536, como se define en RFC 879.
Para obtener información sobre cómo inhabilitar PMTUD, refiérase a la sección Configuración del Soporte BGP para TCP Path MTU Discovery per Session de la Guía de Configuración BGP de Cisco IOS.
Para obtener más información sobre PMTUD, consulte Resolución de problemas de fragmentación de IPv4, MTU, MSS y PMTUD con GRE e IPsec.
Información Relacionada
Comentarios