Risoluzione dei problemi di base del protocollo Border Gateway
Sommario
Introduzione
Questo documento descrive come risolvere i problemi più comuni con il Border Gateway Protocol (BGP) e fornisce soluzioni e linee guida di base.
Prerequisiti
Requisiti
Non sono previsti prerequisiti specifici per questo documento. Per ulteriori informazioni, è possibile fare riferimento alla Guida alla configurazione BGP.
Componenti usati
Il documento può essere consultato per tutte le versioni software o hardware, ma i comandi sono validi per Cisco IOS® e Cisco IOS® XE.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Premesse
Questo documento descrive una guida di base per la risoluzione dei problemi più comuni del Border Gateway Protocol (BGP), fornisce azioni correttive, comandi/debug utili per rilevare la root cause dei problemi e best practice per evitare potenziali problemi. Tenere presente che tutte le variabili e gli scenari possibili non possono essere presi in considerazione e Cisco TAC può richiedere un'analisi più approfondita.
Topologia
Utilizzare questo diagramma della topologia come riferimento per gli output forniti in questo documento.
Scenari e problemi
Adiacente verso il basso
Se una sessione BGP è offline, eseguire il comando show ip bgp all summary command.. In questo modo viene fornito lo stato corrente della sessione:
- Se la sessione non è nello stato attivo, può variare tra IDLE e ACTIVE (dipende dal processo di macchina a stati finiti).
- Se la sessione è in linea, è possibile visualizzare il numero di prefissi ricevuti.
R2#show ip bgp all summary For address family: IPv4 Unicast BGP router identifier 198.51.100.2, local AS number 65537 BGP table version is 19, main routing table version 19 18 network entries using 4464 bytes of memory 18 path entries using 2448 bytes of memory 1/1 BGP path/bestpath attribute entries using 296 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 7208 total bytes of memory BGP activity 18/0 prefixes, 18/0 paths, scan interval 60 secs 18 networks peaked at 11:21:00 Jun 30 2022 CST (00:01:35.450 ago) Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.0.23.3 4 65537 6 5 19 0 0 00:01:34 18 198.51.100.1 4 65536 0 0 1 0 0 never Idle
Nessuna connettività
Il primo requisito è la connettività tra entrambi i peer, quindi viene stabilita la sessione TCP sulla porta 179. siano collegati direttamente o meno) e si può usare un comando ping. Se il peer viene stabilito tra interfacce di loopback, è necessario completare un ping di loopback. Se si esegue un ping senza un loopback specifico come interfaccia di origine, l'indirizzo IP dell'interfaccia fisica in uscita viene usato come indirizzo IP di origine del pacchetto anziché come indirizzo IP di loopback del router.
Se il ping ha esito negativo, prendere in considerazione i seguenti motivi:
- nessuna route peer connessa o nessuna route; eseguire il comando show ip route peer_IP_address.
- Problema di livello 1: devono essere prese in considerazione l'interfaccia fisica, l'SFP (connettore), il cavo o un problema esterno (trasporto e fornitore se applicabile).
- Controllare eventuali firewall o elenchi degli accessi che possano bloccare la connessione.
Se il ping ha esito positivo:
Problemi di configurazione
- Indirizzo IP errato o AS configurato: Se l'indirizzo IP è errato, non viene visualizzato alcun messaggio di questo tipo; accertarsi tuttavia che sia stata completata la configurazione corretta. Per un AS errato, è necessario visualizzare un messaggio simile al comando show logging.
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/2 (peer in wrong AS) 2 bytes 1B39
Controllare la configurazione BGP su entrambe le estremità per correggere i numeri AS o l'indirizzo IP del peer.
- ID router duplicato:
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/3 (BGP identifier wrong) 4 bytes 0A0A0A0A
Controllare l'identificatore BGP su entrambe le estremità eseguendo il comando show ip bgp all summary e risolvere il problema di duplicazione. A tale scopo, è possibile usare manualmente il comando globale bgp router-id X.X.X con la configurazione del router bgp. È buona norma verificare che l'ID del router sia impostato manualmente su un numero univoco.
- Origine BGP e TTL:
La maggior parte delle sessioni iBGP è configurata su interfacce loopback, raggiungibili tramite IGP. L'interfaccia di loopback deve essere definita in modo esplicito come origine. Per completare l'operazione, eseguire il comando next-address-update-source-interface-id.
Per le interfacce peer eBGP connesse direttamente, la maggior parte viene utilizzata per il peering. È presente un controllo per verificare che Cisco IOS/Cisco IOS XE soddisfi questo scopo oppure non tenta di stabilire una sessione. Se si tenta di eseguire il loopback di eBGP su router connessi direttamente, è possibile disabilitare questo controllo per un router adiacente specifico su entrambe le estremità eseguendo il comando ip-address disable-connected-check del router adiacente.
Tuttavia, se tra i peer eBGP sono presenti più hop, è necessario un numero di hop corretto. Verificare che l'indirizzo IP-bgp-multihop del router adiacente [hop-count] sia configurato con il numero di hop corretto, in modo da poter stabilire ogni sessione. Se non si specifica il numero di hop, il valore TTL predefinito per le sessioni iBGP è 255, mentre il valore TTL predefinito per le sessioni eBGP è 1.
Problemi della sessione TCP
Un'azione utile per verificare la porta 179 è un telnet manuale da un peer all'altro:
R1#telnet 198.51.100.2 179 Trying 198.51.100.2, 179 ... Open [Connection to 198.51.100.2 closed by foreign host]
Apertura/connessione chiusa o connessione rifiutata dall'host remoto indica che i pacchetti hanno raggiunto l'estremità remota. Assicurarsi quindi che non vi siano problemi con il control plane all'estremità remota. In caso contrario, se viene visualizzato il messaggio Destination Unreachable (Destinazione non raggiungibile), controllare eventuali firewall o elenchi degli accessi in grado di bloccare la porta TCP 179, i pacchetti BGP o l'eventuale perdita di pacchetti sul percorso.
Se il problema è l'autenticazione, verranno visualizzati i seguenti messaggi:
%TCP-6-BADAUTH: Invalid MD5 digest from 198.51.100.1(179) to 198.51.100.2(20062) tableid - 0 %TCP-6-BADAUTH: No MD5 digest from 198.51.100.1(179) to 198.51.100.2(20062) tableid - 0
Controllare i metodi di autenticazione, la password e le configurazioni correlate e per ulteriori informazioni sulla risoluzione dei problemi, fare riferimento alla guida di esempio dell'autenticazione MD5 tra peer BGP.
Se la sessione TCP non è in linea, utilizzare i comandi successivi per l'isolamento:
show tcp brief all
show control-plane host open-ports
debug ip tcp transactions
Rimbalzi adiacenti
Se la sessione è intermittente, cercare il log di visualizzazione e individuare alcuni scenari.
Interfaccia Flap
%BGP-5-ADJCHANGE: neighbor 198.51.100.2 Down Interface flap
La causa di questo errore è stata "Down Interface Flap". Individuare eventuali problemi fisici relativi a porta/SFP, cavi o disconnessioni.
Timer di attesa scaduto
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.2 4/0 (hold time expired) 0 bytes
Questa condizione è comune e il router non ha ricevuto/elaborato un messaggio keepalive o aggiornato il messaggio prima della scadenza del timer di attesa. Il dispositivo invia un messaggio di notifica e chiude la sessione. I motivi più comuni di questo problema sono:
- Problemi dell'interfaccia: Cercare errori di input, interruzioni nella coda di input o problemi fisici su entrambe le interfacce peer connesse; a tale scopo, è possibile eseguire il comando show interface.
- Perdita di pacchetti in transito: A volte i pacchetti Hello possono essere scartati durante il transito, per essere certi che si tratti di un'acquisizione a livello di interfaccia:
- Usare Embedded Packet Capture su dispositivi Cisco IOS e Cisco IOS XE.
- Se i pacchetti vengono visti a livello di interfaccia, verificare che raggiungano il control plane, l'EPC sul control plane o eseguire il comando debug bgp [nome vrf] ipv4 unicast keepalives.
- CPU alta: una condizione di CPU alta può causare cadute sul control plane, il comando show PROCESSES cpu [ordinati|cronologia] può aiutare a identificare questi problemi. A seconda della piattaforma in uso, è possibile eseguire i passaggi successivi per la risoluzione dei problemi facendo riferimento alla guida di riferimento della CPU.
- Problemi relativi alla policy CoPP: La metodologia di risoluzione dei problemi varia a seconda della piattaforma e non è inclusa nell'ambito di questo documento.
- MTU non corrispondente: In caso di discrepanze MTU nel percorso e di messaggi ICMP bloccati nel percorso tra l'origine e la destinazione, il processo PMTUD non funziona correttamente e può causare un flap nella sessione. Gli aggiornamenti vengono inviati con il valore MSS negoziato e un bit DF impostato. Se un dispositivo nel percorso o la destinazione non può accettare i pacchetti con MTU superiore, invia un messaggio di errore ICMP all'altoparlante BGP. Il router di destinazione attende il pacchetto BGP keepalive o BGP aggiorna il pacchetto al proprio timer di attesa.
È possibile controllare il valore MSS negoziato eseguendo il comando show ip bgp neighbors ip_address.
Un test ping su un router adiacente specifico con df impostato può indicare se l'MTU è valida sul percorso:
ping 198.51.100.2 size max_seg_size df
Se vengono rilevati problemi di MTU, è necessario completare un'accurata revisione della configurazione per assicurare che i valori MTU siano coerenti in tutta la rete.
Problemi AFI/SAFI
%BGP-5-ADJCHANGE: neighbor 198.51.100.2 passive Down AFI/SAFI not supported
%BGP-3-NOTIFICATION: received from neighbor 198.51.100.2 active 2/8 (no supported AFI/SAFI) 3 bytes 000000
L'identificatore della famiglia di indirizzi (AFI) è un'estensione di funzionalità aggiunta da BGP (MP-BGP) multiprotocollo. Corrisponde a un protocollo di rete specifico, ad esempio IPv4, IPv6 e simili. Granularità aggiuntiva tramite un successivo identificatore della famiglia di indirizzi (SAFI, Address-Family Identifier), ad esempio unicast e multicast. MBGP raggiunge questa separazione con gli attributi di percorso BGP (PA) MP_REACH_NLRI e MP_UNREACH_NLRI. Questi attributi vengono inseriti nei messaggi di aggiornamento BGP e vengono utilizzati per trasferire le informazioni sulla raggiungibilità della rete per le diverse famiglie di indirizzi.
Il messaggio contiene i numeri di AFI/SAFI registrati da IANA:
- Controllare la configurazione BGP per individuare le famiglie di indirizzi da entrambi i lati e correggere eventuali famiglie di indirizzi indesiderate.
- Eseguire il comando neighbor ip-address dont-capabilities-negotiation su entrambe le estremità. Per ulteriori informazioni, fare riferimento alla guida sulle funzionalità non supportate che causano problemi di funzionamento del peer BGP.
Installazione e selezione dei percorsi
Per ulteriori informazioni su BGP e sulla selezione del percorso migliore, fare riferimento all'algoritmo di selezione del percorso migliore BGP.
Hop successivo
Affinché una route venga installata nella tabella di routing, è necessario che l'hop successivo sia raggiungibile. In caso contrario, anche se il prefisso si trova nella tabella BGP Loc-RIB, non verrà spostato nella tabella RIB. Come regola per evitare i loop, in Cisco IOS/Cisco IOS XE, iBGP non modifica l'attributo hop successivo in quanto lascia solo AS_PATH mentre eBGP riscrive l'hop successivo e lo precede in AS_PATH.
È possibile rivedere l'hop successivo eseguendo il comando show ip bgp [prefix] perché restituisce l'hop successivo e la parola inaccessibile. Nell'esempio, questo è un prefisso annunciato da R1 tramite eBGP a R2 e appreso da R3 tramite connessione iBGP da R2:
R3#show ip bgp 192.0.2.1
BGP routing table entry for 192.0.2.1/32, version 0
Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 1
65536
198.51.100.1 (inaccessible) from 10.0.23.2 (10.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Updated on Jul 1 2022 13:44:19 CST
Nell'output, l'hop successivo è l'interfaccia in uscita di R1, che non è nota a R3. Per risolvere il problema, è possibile annunciare l'hop successivo tramite IGP, la route statica o eseguire il comando next-hop-self dell'indirizzo IP adiacente sul peer iBGP per modificare l'IP dell'hop successivo (connesso direttamente). Nell'esempio di diagramma, questa configurazione deve essere in R2; il vicino verso R3 (vicino 10.0.23.3 next-hop-self).
Di conseguenza, l'hop successivo viene modificato (dopo la cancellazione di ip bgp 10.0.23.2 soft) nell'interfaccia connessa direttamente (raggiungibile) e viene installato il prefisso:
R3#show ip bgp 192.0.2.1
BGP routing table entry for 192.0.2.1/32, version 24
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
65536
10.0.23.2 from 10.0.23.2 (10.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Updated on Jul 1 2022 13:46:53 CST
Errore RIB
Ciò si verifica quando non è possibile installare una route nella NERVATURA GLOBALE, con conseguente errore della NERVATURA. I motivi più comuni sono quando lo stesso prefisso è già su RIB per un altro protocollo di routing con distanza amministrativa inferiore, ma la causa esatta di un errore RIB è illustrata con il comando show ip bgp rib-failure.
Condizione di gara
Il problema più comune è quando l'IGP viene preferito a eBGP in uno scenario di ridistribuzione reciproca. Quando una route IGP viene ridistribuita in BGP, viene considerata generata localmente da BGP e riceve un peso di 32.768 per impostazione predefinita. A tutti i prefissi ricevuti da un peer BGP viene assegnato per impostazione predefinita un peso locale pari a 0. Pertanto, se è necessario confrontare lo stesso prefisso, il prefisso con il peso più alto viene installato nella tabella di routing in base al processo di selezione del miglior percorso BGP, motivo per cui la route IGP viene installata su RIB.
La soluzione di questo problema è impostare un peso maggiore per tutte le route ricevute dal peer BGP nella configurazione bgp del router:
neighbor ip-address weight 40000
Altri problemi
BGP Slow Peer
È un peer che non riesce a tenere il passo con la frequenza con cui un mittente genera messaggi di aggiornamento. Ci sono molte ragioni per cui un peer espone questo problema; CPU elevata in uno dei peer, traffico eccessivo, perdita di traffico su un collegamento, risorse di larghezza di banda, tra gli altri.
Problemi di memoria
Per funzionare correttamente, BGP utilizza la memoria assegnata al processo Cisco IOS per mantenere i prefissi di rete, i percorsi migliori, le policy e tutte le configurazioni correlate. I processi complessivi vengono rilevati eseguendo il comando show processes memory sortedcommand:
R1#show processes memory sorted
Processor Pool Total: 2121414332 Used: 255911152 Free: 1865503180 reserve P Pool Total: 102404 Used: 88 Free: 102316 lsmpi_io Pool Total: 3149400 Used: 3148568 Free: 832 PID TTY Allocated Freed Holding Getbufs Retbufs Process 0 0 266231616 81418808 160053760 0 0 *Init* 662 0 34427640 51720 34751920 0 0 SBC main process 85 0 9463568 0 8982224 0 0 IOSD ipc task 0 0 34864888 25213216 8513400 8616279 0 *Dead* 504 0 696632 0 738576 0 0 QOS_MODULE_MAIN 518 0 940000 8616 613760 0 0 BGP Router 228 0 856064 345488 510080 0 0 mDNS 82 0 547096 118360 417520 0 0 SAMsgThread 0 0 0 0 395408 0 0 *MallocLite*
Il pool di processori è la memoria utilizzata; circa 2,1 GB nell'esempio. Successivamente, è necessario esaminare la colonna Contenimento per identificare il sottoprocesso che contiene la maggior parte di esso. Quindi, è necessario controllare le sessioni BGP in corso, il numero di route ricevute e la configurazione utilizzata.
Passaggi comuni per ridurre la capacità di memoria di BGP:
- Filtro BGP: se non è necessario ricevere una tabella BGP completa, utilizzare i criteri per filtrare le route e installare solo i prefissi necessari.
- Riconfigurazione soft: Cercare il soft-reconfiguration indirizzo_ip del router adiacente in entrata nella configurazione BGP; questo comando consente di visualizzare tutti i prefissi ricevuti prima di qualsiasi criterio in ingresso (Adj-RIB-in). Tuttavia, questa tabella richiede circa la metà della tabella RIB locale BGP corrente per memorizzare queste informazioni, in modo da evitare questa configurazione a meno che non sia obbligatoria o i prefissi attuali siano pochi.
Elevato consumo della CPU
I router utilizzano processi diversi per il funzionamento di BGP. Per verificare che il processo BGP sia la causa di un elevato utilizzo della CPU, eseguire il comando show process cpu sorted.
R3#show processes cpu sorted CPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 163 36 1463 24 0.07% 0.00% 0.00% 0 ADJ background 62 28 132 212 0.07% 0.00% 0.00% 0 Exec 2 39 294 132 0.00% 0.00% 0.00% 0 Load Meter 1 0 4 0 0.00% 0.00% 0.00% 0 Chunk Manager 3 27 1429 18 0.00% 0.00% 0.00% 0 BGP Scheduler 4 0 1 0 0.00% 0.00% 0.00% 0 RO Notify Timers 63 4 61 65 0.00% 0.00% 0.00% 0 BGP I/O 83 924 26 35538 0.00% 0.03% 0.04% 0 BGP Scanner 96 142 11651 12 0.00% 0.00% 0.00% 0 Tunnel BGP 7 0 1 0 0.00% 0.00% 0.00% 0 DiscardQ Backgro
Di seguito sono riportati i processi comuni, le cause e le fasi generali per superare l'elevato utilizzo della CPU dovuto a BGP:
- Router BGP: Viene eseguito una volta al secondo per garantire una convergenza più rapida (questo è un tema importante). Legge i messaggi di aggiornamento bgp, convalida i prefissi/reti e gli attributi, aggiorna la tabella di prefissi/rete/prefissi AFI/SAFI e la tabella di attributi, esegue il calcolo del miglior percorso, tra le altre attività.
L'enorme cambiamento del percorso è uno scenario molto comune che porta a questa situazione. - Scanner BGP: Processo a bassa priorità eseguito ogni 60 secondi per impostazione predefinita. Questo processo controlla l'intera tabella BGP per verificare la raggiungibilità dell'hop successivo e aggiorna la tabella BGP di conseguenza. Viene eseguito tramite la base di informazioni di routing (RIB, Routing Information Base) a scopo di ridistribuzione. Verificare la scalabilità della piattaforma, poiché sono stati installati più prefissi e route e viene utilizzato TCAM, sono necessarie più risorse.
- I/O BGP: Viene eseguito quando i pacchetti di controllo BGP vengono ricevuti e gestisce l'accodamento e l'elaborazione dei pacchetti BGP. Se i pacchetti ricevuti nella coda BGP sono eccessivi per un lungo periodo o se si verifica un problema con il TCP, il router mostra sintomi di CPU elevata dovuta al processo di I/O BGP. In questa situazione, il router BGP è in genere anche il più avanzato. Esaminare i conteggi dei messaggi per identificare il peer e acquisire i pacchetti per identificare l'origine di questi messaggi.
- BGP aperto: processo utilizzato per stabilire la sessione; non è un problema di CPU elevato a meno che una sessione non sia bloccata in uno stato aperto.
- Evento BGP: responsabile dell'elaborazione dell'hop successivo. Cercare i flap dell'hop successivo sui prefissi ricevuti.
Informazioni correlate
- Documentazione e supporto tecnico – Cisco Systems
- Guida alla configurazione BGP
- Esempio di configurazione dell'autenticazione MD5 tra peer BGP
- Embedded Packet Capture
- BGP Neighbor Flaps con MTU Troubleshooting
- Funzionalità non supportate che causano malfunzionamenti del peer BGP
- Algoritmo di selezione del miglior percorso BGP
- Comprendere il fallimento del BGP RIB e il comando bgp suppress-inactive
- Importanza dell'attributo Weight Path del protocollo BGP negli scenari di failover della rete
- Utilizzare la funzione BGP "Slow Peer" per risolvere i problemi dei peer lenti
- Configurazione dei router BGP per prestazioni ottimali e consumo di memoria ridotto
- Risoluzione dei problemi di CPU elevata causati dal processo dello scanner o del router BGP
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
5.0 |
02-Sep-2026
|
La nuova certificazione ha aggiornato l'ortografia/grammatica, ha inserito righe orizzontali per separare le sezioni per la leggibilità e ha corretto gli errori CCW. |
4.0 |
19-Feb-2025
|
Certificazione |
3.0 |
25-Sep-2023
|
IOS XE aggiornato (trattino rimosso) e aggiunta di marchio, SEO e formattazione. |
2.0 |
21-Feb-2023
|
Certificazione. |
1.0 |
04-Aug-2022
|
Versione iniziale |
Feedback