Risoluzione dei problemi relativi alle connessioni "Down BGP"

La nostra rete ha subito una breve interruzione quando una delle nostre rotte BGP si è interrotta per un breve periodo ieri. Per fortuna le nostre connessioni sono fallite sulla nostra rotta BGP secondaria dopo alcuni minuti e la rotta primaria è diventata operativa dopo una chiusura / nessuna chiusura sul lato ISP.

Stiamo eseguendo 2 switch Cisco 3750e sovrapposti (backplane) con iOS 12.2 58.

Nella mia conversazione con il nostro ISP, non sono stati in grado di fornire risposte definitive alla causa. C'è qualcosa che possiamo fare per individuare la causa da parte nostra per evitare questo problema in futuro?

Accedi al momento dell'errore

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

Accedere quando l'ISP ha fatto una chiusura / nessuna chiusura per ripristinare BGP dalla propria parte

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

Accedere quando la connessione BGP è passata infine da inattiva a Su

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

Interfaccia BGP da parte nostra (nota: nessun CRC, cadute, collisioni segnalate ...)

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

172259: 6 maggio 14:43:06:% BGP-3-NOTIFICATION: inviato al vicino xxx.xxx.12.34 4/0 (tempo di attesa scaduto) 0 byte

Ciò significa generalmente che l'altro lato della connessione non ha risposto a nessun keepalive all'interno del timer di attesa (impostazione predefinita 180 secondi). Ci sono una varietà di problemi che potrebbero aver causato questo. Di solito è un problema di raggiungibilità layer3. Se si verifica nuovamente, è necessario escludere il problema layer3 eseguendo il test al peer tramite ping e telnet (telnet alla porta 179, vedere se risponde).

Se non si tratta di un problema di raggiungibilità layer3, si è verificato un problema con un'estremità del vicinato (più probabilmente il lato lontano in questo caso).

Se stai semplicemente cercando di "causare alla radice" questo problema:

È possibile che si desideri chiedere al proprio provider se sono state apportate modifiche alla configurazione immediatamente prima che ciò si verificasse. Ci sono istanze sui router Cisco (non sicuri al 100% quale codice rev al momento) in cui le sessioni BGP sbatteranno quando una parte rimuoverà e aggiungerà nuovamente una "route map" con un "mpls-ip" e / o un "mtu "configurazione nel peering BGP. Sebbene questo tipo di manutenzione non dovrebbe causare problemi con la sessione di peering, ho sentito raccontare questo evento.

Inoltre, non sono sicuro che avrebbero dovuto spingersi fino al punto di eliminare l'interfaccia e ripristinarla per "risolvere" il problema. Penso che semplicemente reimpostare la sessione di peering sarebbe stato sufficiente, ma se non ci fosse traffico passato al momento dell'errore, si potrebbe obiettare che non importa che abbiano lasciato cadere l'interfaccia per far ripartire le cose.

Potrebbe essere un problema MTU. L'ho avuto un po 'di tempo fa. Inizia bene ma quando viene ricevuto un AGGIORNAMENTO con molti percorsi viene perso a causa della mancata corrispondenza MTU. Inoltre, se si dispone di dispositivi L2 (switch? Media converter?) Tra i due router, è possibile che la connessione venga interrotta senza che l'interfaccia si interrompa.

Non da quello che vedo. Il router del tuo ISP ha smesso di rispondere ai messaggi di saluto dal router, motivo per cui hai perso la connessione BGP. È anche possibile che il tuo router abbia smesso di ascoltare i messaggi di saluto dall'ISP, ma non vedo nulla di ovvio nei messaggi che possa aiutare a individuare il problema. Forse qualcuno più concentrato sulla pista dell'ISP può commentare e far luce?