Solución de problemas cuando la sesión BGP de IX está caída

Si tu Internet Exchange (IX) está inactivo, probablemente haya un problema con tu sesión de Border Gateway Protocol (BGP). Sigue estos pasos de solución de problemas para confirmar si tu sesión BGP es la causa raíz de los problemas de IX.

Consejo

Megaport opera un MegaIX Looking Glass público y accesible por web para que pares y operadores de red investiguen el estado actual del enrutamiento. Puedes consultar tanto los route servers primario y redundante para obtener datos BGP en vivo aquí: MegaIX Looking Glass.

Acciones de solución de problemas

Acción	Pasos
Verificar errores de interfaz o de CRCVerificación de redundancia cíclica. Un tipo de código de detección de errores utilizado para detectar errores de transmisión en los datos. y descartes de paquetes en el dispositivo	Las estadísticas y registros de la interfaz pueden ayudar a identificar qué extremo del cross connect está causando la falla y la posible solución. Por ejemplo, un número creciente de errores de entrada en una interfaz de red generalmente descarta ese SFPUn Small Form-factor Pluggable (SFP) es un transceptor intercambiable en caliente utilizado en redes de comunicaciones de datos y de telecomunicaciones para permitir la transmisión de datos entre dos dispositivos. específico e indica un posible problema con otros componentes del IX. Importante tener en cuenta: Tipo de interfaz, tipo de SFP y tipo de cable 1 Gbps 1000BASE-LX [10km; duplex en SMOFUn cable de fibra óptica con un tamaño de núcleo pequeño que admite un único modo o trayectoria de la luz en todo momento. El cable de fibra tiene un único modo de propagación: una única longitud de onda de luz en el núcleo de la fibra. La fibra óptica multimodo (MMOF) es menos costosa pero solo puede cubrir distancias más cortas sin degradación de la señal. ] 10 Gbps 10GBASE-LR [10km; duplex en SMOF] 100 Gbps 100GBASE-LR4 [10km; duplex en SMOF] MTU (Tamaño máximo de trama Ethernet) 9100 bytes para VXCs entre Ports del cliente. MCR y MVE admiten la MTU estándar de 1500 bytes. IX y muchos puertos de CSP no admiten tramas jumbo, pero todos admiten la MTU estándar de 1500 bytes. LAGDescribe varios métodos para usar múltiples conexiones de red en paralelo para aumentar el rendimiento más allá del límite que puede alcanzar un único enlace (una conexión). En general para la agregación de enlaces, los Ports físicos deben residir en un único switch/router. Protocolo: LACP Interfaz: 10GBASE-LR (10 Gbps) o 100GBASE-LR4 (100 Gbps). No se admiten Ports de 1 Gbps. Número máximo de interfaces en un único LAG: 8 Multi-Chassis Link Aggregation (MC-LAG) entre varios dispositivos no está admitido. VLAN preferida del extremo A (VXC/IX) Untag (enabled) (Sin etiqueta (Habilitado)) – Esto limitará el A-End Port a un único servicio. Solo un VXC/IX por Port, equivalente a un puerto de acceso en el lado de tu dispositivo. Untag (disabled) (Sin etiqueta (Deshabilitado)) – Especifica el número de VLAN 802.1q en el A-End Port. Cada VXC se entrega como una VLAN separada en el Port. Debe ser un ID de VLAN único en el Port y puede variar de 2 a 4093. Si especificas un ID de VLAN ya en uso, el sistema muestra el siguiente número de VLAN disponible. El sistema asignará aleatoriamente un número de VLAN, equivalente a un puerto troncal con VLAN permitidas en el lado de tu dispositivo, si dejas en blanco el ID de VLAN. Túnel 802.1Q (Q-in-QLa tunelización 802.1Q (también conocida como Q-in-Q o 802.1ad) es una técnica utilizada por proveedores de Capa 2 del modelo OSI para clientes. 802.1ad admite tanto una etiqueta interna como una externa mediante la cual la externa (a veces llamada S-tag de proveedor de servicios) puede eliminarse para exponer las etiquetas internas (C-tag o de cliente) que segmentan los datos. ) IEEE 802.1ad (Azure VXC) Para acceder a Microsoft Azure ExpressRoute, se requiere Q-in-Q (IEEE 802.1ad). Dependiendo del método elegido, la configuración de tus dispositivos puede variar: Q-in-Q, Q-in-Q breakout, VXC sin etiqueta o MCR.
Verificar que la interfaz, el SFP, el cable y el cableado sean correctos	Verifica que se use auto-negociación (speed auto y duplex auto) en interfaces Gigabit. Verifica que el cable del cross connect esté conectado al puerto correcto en ambos extremos. Verifica que los niveles de potencia óptica del SFP (Tx y Rx) muestren buena luz en ambos extremos.
Verificar las configuraciones de Capa 2La capa 2 del modelo OSI es la capa de enlace de datos. Esta proporciona transferencia de datos de nodo a nodo (un enlace entre dos nodos conectados directamente). La mayoría de los Megaport Virtual Cross Connects (VXCs) operan en esta capa. La capa 2 se divide en la capa de Control de Acceso al Medio (MAC) (controla cómo los dispositivos en una red obtienen acceso al medio y el permiso para transmitir), y la capa de Control de Enlace Lógico (LLC) (responsable de identificar los protocolos de la capa de red y luego encapsularlos y controla la verificación de errores y la sincronización de tramas).	Verifica que el tamaño de la MTU sea correcto. Verifica que la configuración de LACP sea correcta si se usa LAG. MC-LAG no está admitido. Verifica que tus dispositivos estén configurados según la “VLAN preferida del extremo A” en el Megaport Portal. Si se utiliza una VLAN, confirma que esté configurado el número de VLAN correcto en tu dispositivo. Si se usa Azure VXC, verifica que tus dispositivos estén configurados utilizando alguno de los métodos Q-in-Q.
Verificar las configuraciones de Capa 3La Capa 3 del modelo OSI es la capa de red. Traduce la dirección lógica de la red en la dirección física de la máquina (direccionamiento IP). Los routers de Capa 3 analizan el tráfico en función de los detalles de las direcciones y reenvían según corresponda, lo que requiere conocer los detalles que generalmente se intercambian en las sesiones BGP para el intercambio de tablas de enrutamiento.	Verifica que la dirección IP de la interfaz y la dirección de subred estén configuradas correctamente. Verifica que las configuraciones de los protocolos de enrutamiento (EIGRP/OSPF/BGP) estén correctas. Ejecuta una prueba de ping entre dispositivos de red de Capa 3 (por ejemplo, routers perimetrales, pares BGP). Ejecuta una prueba de ping entre el host de origen y el host de destino (prueba de conectividad de extremo a extremo). Si la prueba de ping falla, revisa la tabla ARPLa tabla de enrutamiento del Protocolo de Resolución de Direcciones (ARP) contiene una lista de asociaciones de direcciones MAC (Capa 2) a direcciones IP (Capa 3). y la tabla de enrutamiento en ambos extremos. Si la prueba de ping falla y no hay problemas en la tabla de enrutamiento en ambos extremos, entonces toma registros de tracerouteUna herramienta de diagnóstico que examina cómo los datos se mueven a través de Internet para determinar si un destino es accesible. desde ambos extremos.
Verificar los niveles de potencia óptica en el dispositivo	Las lecturas de luz óptica desde el terminal ayudan a entender si las mediciones están dentro del rango umbral. Revisa las gráficas del dispositivo y del puerto para ver errores y consulta el Megaport optic graphs history. Las gráficas se actualizan cada cinco minutos, por lo que si el flapping es poco frecuente, es posible que no capturen una caída de la luz óptica. Asegúrate de que la lectura óptica esté dentro de las especificaciones.
Realizar una prueba de ping a los route servers dentro de la red IX y/o peers bilaterales	Una prueba de ping transmite paquetes de datos a una dirección IP específica y confirma o niega que exista conectividad entre dispositivos en red IP. Una confirmación incluye la latencia (tiempo de respuesta) de la conexión.
Verificar la conectividad de Capa 2 (ARP) hacia route servers y/o peers bilaterales	Capa 2 controla el flujo de datos entre nodos en segmentos WAN o LAN y también es responsable de detectar y posiblemente corregir errores de Capa 1. Los problemas de conectividad de Capa 2 pueden afectar la funcionalidad de tus VXCs, que conectan a tu MCR. Al conectarte a un Proveedor de servicios de nube (CSP), asegúrate de que los detalles de configuración de la VLAN sean correctos. Usa especial precaución al conectarte a Azure, ya que estarás usando Q-in-Q. Los problemas de conectividad de Capa 2 también pueden afectar tus servicios de IX. Las direcciones MAC se usan para autenticar tus dispositivos cuando utilizas servicios de IX con Megaport. Según el diseño de tu red, si estás haciendo Peering con Megaport u otras organizaciones, asegúrate de haber especificado la dirección MAC correcta en el Megaport Portal. Realiza estas comprobaciones antes de Enviar una solicitud de soporte: Verifica el estado de tu servicio de IX con la Looking Glass tool. Puedes acceder a información de ambos route servers (primario y redundante) para datos BGP en vivo. Los problemas de Capa 2 pueden ser más difíciles de diagnosticar que los problemas físicos de Capa 1. Proporcionar a Megaport detalles de conectividad de Capa 2 ayudará a aislar el problema. Si no estás haciendo Peering directamente con Megaport, confirma cualquier cambio de configuración con la compañía con la que estás haciendo Peering. Ejecuta una prueba de ping para verificar si estás conectado a Capa 2. Revisa las tablas ARP y confirma que la dirección MAC sea visible en el Megaport Portal. Confirma que la configuración coincida con las Especificaciones técnicas de Megaport. Para obtener orientación adicional, comunícate con tu Gerente de cuenta y solicita una reunión con un Arquitecto de Soluciones de Megaport.
Verificar la configuración de BGP	Configuración de interfaz, incluido el número de VLAN Dirección IP de BGP y máscara de subred Número de ASUn sistema autónomo (AS) es un conjunto de prefijos de enrutamiento del Protocolo de Internet (IP) conectados bajo el control de uno o más operadores de red en nombre de una única entidad administrativa o dominio. ASN se refiere al número de sistema autónomo y es un identificador numérico único asignado a cada AS para su uso en el enrutamiento BGP. de BGP Direcciones de red BGP que se anunciarán Dirección IP del vecino BGP y máscara de subred Número de AS del vecino BGP Direcciones de red del vecino BGP que se recibirán Autenticación BGP entre pares BGP Filtrado y manipulación de rutas BGP, si corresponde
Comprobar mensajes de error de BGP	El protocolo BGP envía un mensaje de notificación cuando detecta un error con la sesión BGP, como un hold timer próximo a expirar, un cambio en las capacidades del vecino o una solicitud para restablecer una sesión BGP. Cuando se detecta un error, la sesión BGP se cierra. Por ejemplo, ingresa show log %BGP-xxxxx. Para más información, consulta Descripción general de Internet Exchange.

Pasos siguientes

Si las acciones de solución de problemas no resuelven tu problema, contacta al soporte. Antes de solicitar asistencia, recopila la siguiente información:

Resultados de la solución de problemas

Proporciona en detalle todos los pasos de solución de problemas que has realizado. Por ejemplo, si se colocaron loops, indica su ubicación y en qué dirección estaban orientados.

Extractos de configuraciones de dispositivos de red

Configuraciones de interfaz
Rutas estáticas y configuraciones de protocolos de enrutamiento (EIGRP/OSPF/BGP)
Reglas de firewall y configuraciones de ACL para el flujo de datos que presenta el problema

Salida de comandos BGP e información de captura de paquetes

Tabla de enrutamiento (show IP route <ip-address>) en ambos extremos.
Estado del protocolo de enrutamiento y las tablas en ambos extremos; por ejemplo, la tabla de vecinos BGP que muestra el estado de BGP (show ip bgp summary) y los detalles del vecino BGP (show ip bgp neighbors <neighbor-ip-address>).
Entradas de la tabla de enrutamiento BGP que presenten problemas de enrutamiento BGP (salida del comando show IP BGP).
Rutas BGP anunciadas (show IP BGP neighbors <neighbor-ip-address> advertised-routes).
Rutas BGP recibidas (salida del comando show IP BGP neighbors <neighbor-ip-address> routes - Tabla de enrutamiento (show IP route <ip-address>)).
Registros de Traceroute entre el host de origen y el host de destino.
Registros de Packet capture, si es posible (el tamaño del archivo puede ser de hasta 10 M).

Nota

Para obtener más información sobre cuándo se necesita un técnico de servicios de campo en sitio en el centro de datos, consulta Servicios de campo para clientes.