Nuestra red experimentó una breve interrupción cuando ayer una de nuestras rutas BGP dejó de funcionar por poco tiempo. Afortunadamente, nuestras conexiones fallaron a nuestra ruta secundaria BGP después de unos minutos, y la ruta principal se volvió operativa después de un cierre / no cierre en el lado del ISP.
Estamos ejecutando 2 switches Cisco 3750e apilados (backplane) que ejecutan iOS 12.2 58.
En mi conversación con nuestro ISP, no pudieron dar ninguna respuesta definitiva a la causa. ¿Hay algo que podamos hacer para determinar la causa de nuestro lado para evitar este problema en el futuro?
Iniciar sesión en el momento del error
172258: May 6 14:43:06: %BGP-5-ADJCHANGE: neighbor xxx.xxx.12.34 Down BGP Notification sent
172259: May 6 14:43:06: %BGP-3-NOTIFICATION: sent to neighbor xxx.xxx.12.34 4/0 (hold time expired) 0 bytes
172260: May 6 14:43:06: %BGP_SESSION-5-ADJCHANGE: neighbor xxx.xxx.12.34 IPv4 Multicast topology base removed from session BGP Notification sent
172261: May 6 14:43:06: %BGP_SESSION-5-ADJCHANGE: neighbor xxx.xxx.12.34 IPv4 Unicast topology base removed from session BGP Notification sent
Registre cuando el ISP se cerró / no cerró para restablecer BGP de su lado
172542: May 6 15:04:15: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/49, changed state to down
172543: May 6 15:04:16: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/49, changed state to down
172544: May 6 15:04:16: %PIM-5-NBRCHG: neighbor xxx.xxx.12.34 DOWN on interface GigabitEthernet2/0/49 non DR
172545: May 6 15:04:16: %PIM-5-NBRCHG: neighbor xxx.xxx.12.34 UP on interface GigabitEthernet2/0/49
172546: May 6 15:04:16: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to xxx.xxx.12.35 on interface GigabitEthernet2/0/49
172547: May 6 15:04:18: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/49, changed state to up
172548: May 6 15:04:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/49, changed state to up
Inicie sesión cuando la conexión BGP finalmente pasó de inactiva a arriba
172828: May 6 15:27:33: %BGP-5-ADJCHANGE: neighbor xxx.xxx.12.34 Up
Interfaz BGP de nuestro lado (nota: sin CRC, caídas, colisiones reportadas ...)
GigabitEthernet2/0/49 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is xxxx.xxxx
Internet address is xxx.xxx.12.35/31
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 3/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseLX SFP
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:09, output 00:00:12, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/52/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 14536000 bits/sec, 1655 packets/sec
5 minute output rate 1010000 bits/sec, 640 packets/sec
413176726 packets input, 428902543141 bytes, 0 no buffer
Received 143495 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 139275 multicast, 0 pause input
0 input packets with dribble condition detected
125748632 packets output, 42915625632 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
fuente
Respuestas:
172259: 6 de mayo 14:43:06:% BGP-3-NOTIFICACIÓN: enviado al vecino xxx.xxx.12.34 4/0 (tiempo de espera expirado) 0 bytes
Eso generalmente significa que el otro lado de la conexión no respondió a ningún keepalives dentro del temporizador de retención (predeterminado 180 segundos). Hay una variedad de problemas que podrían haber causado esto. Por lo general, es un problema de accesibilidad de capa3. Si vuelve a suceder, debe descartar el problema de la capa 3 probando al igual a través de ping y telnet (telnet al puerto 179, vea si responde).
Si no se trata de un problema de alcance de la capa 3, entonces hubo un problema con un extremo de la vecindad (más probablemente el lado más alejado en este caso).
fuente
Si simplemente está buscando la "causa raíz" de este problema:
Es posible que desee preguntarle a su proveedor si se realizaron cambios de configuración inmediatamente antes de que esto ocurriera. Hay instancias en los enrutadores Cisco (no estoy 100% seguro de qué código rev en este momento) donde las sesiones BGP se agitarán cuando un lado elimine y vuelva a agregar un "mapa de ruta" con un "mpls-ip" y / o un "mtu "configuración en la interconexión BGP. Aunque ese tipo de mantenimiento no debería causar problemas con la sesión de emparejamiento, he escuchado historias de que esto está sucediendo.
Además, no estoy seguro de que hubieran tenido que ir tan lejos como para soltar la interfaz y volver a instalarla para 'solucionar' el problema. Creo que simplemente restablecer la sesión de emparejamiento habría sido suficiente, pero si no se pasaba el tráfico en el momento de la falla, se podría argumentar que no importa que hayan abandonado la interfaz para que las cosas vuelvan a funcionar.
fuente
Podría ser un problema de MTU. Tenía esto hace un tiempo. Comienza bien, pero cuando se recibe una ACTUALIZACIÓN con muchas rutas, se pierde debido a la falta de coincidencia de MTU. Además, si tiene dispositivos L2 (conmutador? Convertidor de medios?) Entre sus dos enrutadores, es posible que la conexión se interrumpa sin que la interfaz se caiga.
fuente
No por lo que estoy viendo. El enrutador de su ISP dejó de responder a los mensajes de saludo de su enrutador, razón por la cual perdió su conexión BGP. También es posible que su enrutador deje de escuchar los mensajes de saludo del ISP, pero no veo nada obvio en los mensajes que pueda ayudar a identificar el problema. ¿Quizás alguien más centrado en la pista del ISP pueda comentar y arrojar algo de luz?
fuente