Risoluzione dei problemi di CPU elevata causati dal processo di scansione o router BGP

Nota: L'elevata CPU sul dispositivo potrebbe essere dovuta anche all'instabilità della tabella BGP. Questo si verifica se il router riceve due copie della tabella di routing, una dal peering EBGP con l'ISP e l'altra dal peering IBGP nella rete. La causa principale è la quantità di memoria disponibile nel dispositivo. Cisco consiglia un minimo di 1 Gig di RAM per una singola copia della tabella di routing Internet. Per evitare questa instabilità, aumentare la RAM sul dispositivo o filtrare i prefissi in modo da eliminare la tabella BGP e la memoria occupata.

Miglioramenti delle prestazioni

L'aumento del numero di route nella tabella di routing Internet determina un aumento del tempo necessario per la convergenza di BGP. In generale, la convergenza è definita come il processo in cui tutte le tabelle di instradamento vengono portate a uno stato di coerenza. Il protocollo BGP è considerato convergente quando si verificano le seguenti condizioni:

• Tutte le route sono state accettate.

• Tutte le route sono state installate nella tabella di routing.

• La versione della tabella per tutti i peer è uguale alla versione della tabella BGP.

• InQ e OutQ per tutti i peer sono pari a zero.

In questa sezione vengono descritti alcuni miglioramenti delle prestazioni di Cisco IOS per ridurre i tempi di convergenza BGP e ottenere una riduzione di un'elevata condizione della CPU dovuta a un processo BGP.

Connessioni peer da coda a TCP

BGP mette ora in coda i dati in modo aggressivo dal BGP OutQ al socket TCP per ciascun peer fino a quando gli OutQ non sono completamente esauriti. Dal momento che BGP invia ora a una velocità superiore, BGP converge più rapidamente.

Gruppi di peer BGP

Oltre a semplificare la configurazione BGP, i gruppi peer BGP possono anche migliorare la scalabilità. Tutti i membri del gruppo peer devono condividere un criterio comune in uscita. Di conseguenza, è possibile inviare gli stessi pacchetti di aggiornamento a ciascun membro del gruppo e ciò riduce il numero di cicli CPU necessari a BGP per annunciare le route ai peer. In altre parole, con i gruppi peer, BGP esamina la tabella BGP solo sulla coordinata del gruppo peer, filtra i prefissi tramite i criteri in uscita e genera aggiornamenti che invia alla coordinata del gruppo peer. A sua volta, il coordinatore replica gli aggiornamenti ai membri del gruppo con cui è sincronizzato. Senza gruppi peer, BGP deve eseguire la tabella per ogni peer, filtrare i prefissi tramite criteri in uscita e generare aggiornamenti che vengono inviati solo a un peer.

Path MTU e il comando ip tcp path-mtu-discovery

Tutte le sessioni TCP sono limitate da un limite al numero di byte che possono essere trasportati in un singolo pacchetto. Per impostazione predefinita, questo limite, noto come Dimensione massima del segmento (MSS), è di 536 byte. In altre parole, il protocollo TCP suddivide i pacchetti in una coda di trasmissione in blocchi da 536 byte prima di passare i pacchetti al livello IP. Usare i comandi show ip bgp neighbors | include max data command per visualizzare il valore MSS dei peer BGP:

Router#show ip bgp neighbors | include max data 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 

Il vantaggio di un valore MSS di 536 byte è che i pacchetti non verranno frammentati su un dispositivo IP sul percorso verso la destinazione, in quanto la maggior parte dei collegamenti utilizza una MTU di almeno 1500 byte. Lo svantaggio è che i pacchetti più piccoli aumentano la quantità di larghezza di banda utilizzata per il trasporto del sovraccarico. Poiché BGP crea una connessione TCP a tutti i peer, un valore MSS di 536 byte influisce sui tempi di convergenza BGP.

La soluzione è abilitare la funzione Path MTU (PMTU) con il comando ip tcp path-mtu-discovery. È possibile utilizzare questa funzione per determinare in modo dinamico le dimensioni del valore MSS e nel frattempo non creare pacchetti da frammentare. La PMTU consente al protocollo TCP di determinare le dimensioni MTU più piccole tra tutti i collegamenti in una sessione TCP. Il protocollo TCP usa quindi questo valore MTU, meno lo spazio per le intestazioni IP e TCP, come valore MSS per la sessione. Se una sessione TCP attraversa solo segmenti Ethernet, il valore MSS è 1460 byte. Se attraversa solo i segmenti Packet over SONET (POS), il valore MSS è 4430 byte. L'aumento del valore MSS da 536 a 1460 o 4430 byte riduce il sovraccarico TCP/IP, consentendo una più rapida convergenza del protocollo BGP.

Dopo aver abilitato la PMTU, usare nuovamente i comandi show ip bgp neighbors | include max data command per visualizzare il valore MSS per peer:

Router#show ip bgp neighbors | include max data 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 

Aumento delle code di input dell'interfaccia

Se BGP annuncia migliaia di route a molti peer, il protocollo TCP deve trasmettere migliaia di pacchetti in una breve durata. I peer BGP ricevono questi pacchetti e inviano riconoscimenti TCP al diffusore BGP che li annuncia, causando la ricezione da parte del diffusore BGP di una marea di ACK TCP in un breve periodo di tempo. Se gli ACK arrivano a una velocità troppo alta per il processore di routing, i pacchetti vengono di nuovo inseriti nelle code dell'interfaccia in entrata. Per impostazione predefinita, le interfacce router utilizzano una coda di input di 75 pacchetti. Inoltre, i pacchetti di controllo speciali, ad esempio gli AGGIORNAMENTI BGP, utilizzano una coda speciale con SPD (Selective Packet Discard). Questa coda speciale contiene 100 pacchetti. Quando si verifica la convergenza BGP, gli ACK TCP possono riempire rapidamente i 175 punti del buffer di input e i nuovi pacchetti in arrivo devono essere scartati. Sui router con 15 o più peer BGP e con scambio della tabella di routing Internet completa, è possibile rilevare oltre 10.000 gocce per interfaccia al minuto. Di seguito è riportato l'output di esempio restituito da un router 15 minuti dopo il riavvio:

Router#show interface pos 8/0 | include input queue 
Output queue 0/40, 0 drops; input queue 0/75, 278637 drops 
Router#

Aumentando la profondità della coda di input dell'interfaccia (con il comando hold-queue), si riduce il numero di ACK TCP scartati, riducendo la quantità di lavoro che BGP deve eseguire per convergere. In genere, un valore pari a 1000 risolve i problemi causati da perdite nella coda di input.

Nota: Utilizzare questa opzione con attenzione, in quanto l'incremento della coda di input può causare un certo ritardo.

Ulteriori miglioramenti in Cisco IOS

Cisco IOS include diverse ottimizzazioni del codice BGP peer group per migliorare il packaging degli aggiornamenti e la replica. Prima di esaminare questi miglioramenti, esaminare più dettagliatamente l'imballaggio e la replica degli aggiornamenti.

Un aggiornamento BGP è costituito da una combinazione di attributi (ad esempio MED = 50 e LOCAL_PREF = 120) e da un elenco di prefissi NLRI (Network Layer Reachability Information) che condividono tale combinazione di attributi. Maggiore è il numero di prefissi NLRI che BGP può elencare in un singolo aggiornamento, maggiore è la velocità di convergenza del BGP grazie alla riduzione del sovraccarico (ad esempio, le intestazioni IP, TCP e BGP). L'imballaggio degli aggiornamenti si riferisce all'imballaggio di NLRI negli aggiornamenti BGP. Ad esempio, se una tabella BGP contiene 100.000 route con 15.000 combinazioni di attributi univoci, BGP deve inviare solo 15.000 aggiornamenti se NLRI è predisposto al 100% di efficienza.

Nota: L'efficienza di imballaggio pari a zero indica che BGP dovrebbe inviare 100.000 aggiornamenti in questo ambiente.

Usare il comando show ip bgp peer-group per visualizzare l'efficienza degli aggiornamenti BGP.

Se un membro del gruppo peer è sincronizzato, un router BGP accetta un messaggio di aggiornamento formattato per il leader del gruppo peer e lo replica per il membro. È molto più efficiente replicare un aggiornamento per un membro di un gruppo peer che riformattarlo. Si supponga, ad esempio, che un gruppo peer abbia 20 membri e che tutti i membri debbano ricevere 100 messaggi BGP. La replica al 100% indica che un router BGP formatta i 100 messaggi per il peer group leader e replica tali messaggi agli altri 19 membri del peer group. Per confermare i miglioramenti apportati alla replica, confrontare il numero di messaggi replicati con il numero di messaggi formattati, come mostrato dal comando show ip bgp peer-group. I miglioramenti apportati fanno una notevole differenza nei tempi di convergenza e consentono a BGP di supportare un numero maggiore di peer.

Ad esempio, usare il comando show ip bgp peer-group per verificare l'efficienza della compressione degli aggiornamenti e della replica degli aggiornamenti. L'output successivo viene generato da un test di convergenza con 6 gruppi peer, 20 peer in ciascuno dei primi 5 gruppi peer (peer eBGP) e 100 peer nel sesto gruppo peer (peer iBGP) interno. Inoltre, la tabella BGP utilizzata aveva 36.250 combinazioni di attributi.

L'output di esempio successivo del peer-group show ip bgp | include replicated command su un router con Cisco IOS 12.0(18)S visualizza le seguenti informazioni:

Update messages formatted 836500, replicated 1668500 
Update messages formatted 1050000, replicated 1455000 
Update messages formatted 660500, replicated 1844500 
Update messages formatted 656000, replicated 1849000 
Update messages formatted 501250, replicated 2003750 

!-- The first five lines are for eBGP peer groups.
 
Update messages formatted 2476715, replicated 12114785 

!-- The last line is for an iBGP peer group.

Per calcolare la velocità di replica per ogni gruppo peer, dividere il numero di aggiornamenti replicati per il numero di aggiornamenti formattati:

1668500/836500 = 1,99 1455000/1050000 = 1,38 1844500/660500 = 2,79 1849000/656000 = 2,81 2003750/50125 0 = 3,99 12114785/2476715 = 4,89

• Se BGP è stato replicato perfettamente, i gruppi peer eBGP hanno ciascuno una velocità di replica di 19 perché nel gruppo peer ci sono 20 peer. L'aggiornamento viene formattato per il coordinatore del gruppo peer e quindi replicato negli altri 19 peer. In questo modo viene fornita una velocità di replica ottimale pari a 19. La velocità di replica ideale per il gruppo peer iBGP sarebbe pari a 99 poiché sono presenti 100 peer.
• Se gli aggiornamenti BGP sono stati compressi perfettamente, saranno disponibili solo 36.250 aggiornamenti formattati. È necessario generare solo 36.250 aggiornamenti per ogni gruppo peer perché è il numero di combinazioni di attributi nella tabella BGP. Il solo gruppo peer iBGP formatta quasi 2.500.000 aggiornamenti, mentre i gruppi peer eBGP generano ciascuno da 500.000 a 1.000.000 di aggiornamenti.

Su un router con Cisco IOS 12.0(19)S, usare il comando show ip bgp peer-group | include replicatedcommand fornisce le seguenti informazioni:

Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 3588750

Nota: L'imballaggio degli aggiornamenti è ottimale. Per ogni gruppo peer vengono formattati esattamente 36.250 aggiornamenti. 688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 688750/36250 = 19358 8750/36250 = 99

Nota: Anche la replica degli aggiornamenti è perfetta.

Procedure di risoluzione dei problemi

Utilizzare queste procedure per risolvere i problemi relativi alla CPU alta dovuta allo scanner BGP o al router BGP:

• Raccogliere informazioni sulla topologia BGP. Determinare il numero di peer BGP e il numero di route annunciate da ogni peer. La durata della condizione di CPU elevata è ragionevole in base all'ambiente?

• Determinare quando si verifica un'elevata CPU. Coincide con una passeggiata regolare del tavolo BGP?

• L'elevata CPU ha subito un flap nell'interfaccia? Se l'attenuazione è abilitata, è possibile usare il comando show ip bgp dampening flap-statistics.

• Eseguire il ping tra il router e quindi il ping tra il router. Gli echi ICMP vengono gestiti come processo a bassa priorità. Il documentoComprendere i comandi Ping e Traceroute spiega in dettaglio questa condizione. Assicurarsi che l'inoltro regolare non sia influenzato.

• Quando si controlla se l'opzione di commutazione veloce e/o il CEF sono abilitati sulle interfacce in entrata e in uscita, è necessario verificare che i pacchetti possano seguire un percorso di inoltro rapido. verificare che il comando no ip route-cache cef non sia visualizzato sull'interfaccia o il comando no ip cef sulla configurazione globale. Per abilitare il CEF in modalità di configurazione globale, usare il comando ip cef.

• Controllare la scalabilità della piattaforma perché, nella maggior parte dei casi, è dovuto a un dispositivo sovraccarico che conduce a tali situazioni. Inoltre, viene garantito che sul router sia disponibile uno spazio TCAM (Content Indirissable Memory) adeguato.

• Verificare che la memoria sul router sia sufficiente. Come indicato nella raccomandazione, assegnare almeno 1 GB di DRAM allo spazio Cisco IOS per peer BGP che invia la tabella di routing Internet completa. Lo spazio DRAM qui menzionato è solo la memoria richiesta per BGP. Altre funzionalità eseguibili sul router possono richiedere spazio aggiuntivo.

Informazioni correlate

• Pagina di supporto per il routing IP
• Supporto tecnico – Cisco Systems