cisco-catalyst – Solución de problemas de conexiones "Down BGP"

Pregunta:

Nuestra red experimentó una breve interrupción cuando ayer una de nuestras rutas BGP se interrumpió durante un breve período de 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) con 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 identificar 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 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

Registre cuando la conexión BGP finalmente pasó de inactiva a Up

172828: May  6 15:27:33: %BGP-5-ADJCHANGE: neighbor xxx.xxx.12.34 Up

Interfaz BGP en nuestro extremo (nota: sin CRC, caídas, colisiones informadas …)

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

Respuesta:

172259: 6 de mayo 14:43:06:% BGP-3-NOTIFICATION: enviado al vecino xxx.xxx.12.34 4/0 (tiempo de espera vencido) 0 bytes

Eso generalmente significa que el otro lado de la conexión no respondió a ninguna actividad de mantenimiento dentro del temporizador de espera (por defecto, 180 segundos). Hay una variedad de problemas que podrían haber causado esto. Por lo general, es un problema de accesibilidad de layer3. Si vuelve a suceder, debe descartar el problema de la capa 3 probando con el par a través de ping y telnet (telnet al puerto 179, vea si responde).

Si no es un problema de accesibilidad de layer3, entonces hubo un problema con un extremo del vecindario (más probablemente el lado opuesto en este caso).

Leave a Comment

Your email address will not be published. Required fields are marked *

web tasarım