Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Convenzioni

Premesse

Comprendere i processi BGP

CPU elevata a causa dello scanner BGP

CPU elevata a causa del processo del router BGP

Miglioramenti delle prestazioni

Connessioni peer da coda a TCP

Gruppi di peer BGP

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

Aumento delle code di input dell'interfaccia

Ulteriori miglioramenti in Cisco IOS

Procedure di risoluzione dei problemi

Informazioni correlate

Introduzione

In questo documento viene descritto come risolvere i problemi relativi alle letture elevate della CPU quando si usano lo scanner BGP o il router.

Prerequisiti

Requisiti

Questo documento richiede la conoscenza di come interpretare il comando show process cpu.

Componenti usati

Il riferimento delle informazioni contenute in questo documento è il software Cisco IOS® versione 12.0.

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.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Premesse

Questo documento descrive le situazioni in cui un router Cisco IOS può sperimentare un elevato utilizzo della CPU a causa del processo Border Gateway Protocol (BGP) o dello scanner BGP, come mostrato nell'output del comando show process cpu. La durata della condizione di CPU alta varia in base a un numero di condizioni, in particolare le dimensioni della tabella di routing Internet e il numero di route che un determinato router mantiene nelle tabelle di routing e BGP. Il comando show process cpu mostra l'utilizzo medio della CPU negli ultimi cinque secondi, un minuto e cinque minuti. I numeri di utilizzo della CPU non forniscono una vera indicazione lineare dell'utilizzo rispetto al carico offerto.

Queste sono alcune delle ragioni principali:

- In una rete reale, la CPU deve gestire varie funzioni di manutenzione del sistema, ad esempio la gestione della rete.

- La CPU deve elaborare aggiornamenti periodici del routing attivati da eventi.

- Esistono altre operazioni di sovraccarico del sistema interno, ad esempio il polling per la disponibilità delle risorse, che non sono proporzionali al carico del traffico.

È inoltre possibile utilizzare il comando show processes cpu per ottenere alcune indicazioni sull'attività della CPU.

Nota: Per ulteriori informazioni sui comandi show, consultare la guida di riferimento dei comandi di Cisco IOS Configuration Fundamentals

Comprendere i processi BGP

Un processo Cisco IOS, in generale, è costituito da singoli thread e dai dati associati che eseguono attività, quali la manutenzione del sistema, lo switching di pacchetti e l'implementazione di protocolli di routing. Diversi processi Cisco IOS eseguiti sul router consentono l'esecuzione di BGP. Utilizzare il comando show process cpu | includere il comando BGP per verificare la quantità di utilizzo della CPU dovuto ai processi BGP.

In questa tabella viene elencata la funzione dei processi BGP e viene mostrato che ogni processo viene eseguito in momenti diversi. Tali orari dipendono dalle attività gestite. Poiché i processi dello scanner BGP e del router BGP sono responsabili di una grande quantità di calcoli, è possibile che la CPU risulti elevata a causa di uno di questi processi. Nelle sezioni seguenti vengono illustrati in dettaglio tali processi.

Nome processo

Descrizione

Intervallo

BGP Open

Esegue la determinazione dei peer BGP.

All'inizializzazione, quando viene stabilita una connessione TCP con un peer BGP.

I/O BGP

Gestisce i pacchetti BGP presenti nella coda e che vengono elaborati, ad esempio UPDATE e KEEPALIVE.

Ricevuti pacchetti di controllo BGP.

Scanner BGP

Visualizza la tabella BGP e conferma la raggiungibilità degli hop successivi. Lo scanner BGP controlla inoltre l'annuncio condizionale per determinare se BGP annuncia i prefissi di condizione ed esegue la riduzione della route. In un ambiente VPN MPLS, lo scanner BGP importa ed esporta le route in una particolare istanza di routing e inoltro VPN (VRF).

Una volta al minuto.

Router BGP

Calcola il miglior percorso BGP ed elabora qualsiasi variazione di route. Invia e riceve route, stabilisce peer e interagisce con la base RIB (Routing Information Base).

Una volta al secondo e quando un peer BGP viene aggiunto, rimosso o configurato in modo soft.

CPU elevata a causa dello scanner BGP

È possibile prevedere un'elevata CPU dovuta al processo dello scanner BGP per brevi durate su un router dotato di una tabella di routing Internet di grandi dimensioni. Una volta al minuto, lo scanner BGP sposta la tabella RIB BGP ed esegue importanti attività di manutenzione. Queste attività includono l'esame dell'hop successivo a cui si fa riferimento nella tabella BGP del router e la verifica della possibilità di raggiungere i dispositivi dell'hop successivo. Pertanto, una tabella BGP di grandi dimensioni richiede un tempo equivalente per essere spostata e convalidata.

Poiché il processo dello scanner BGP viene eseguito sull'intera tabella BGP, la durata della condizione di CPU alta varia in base al numero di router adiacenti e al numero di route apprese per router adiacente. Per acquisire queste informazioni, usare i comandi show ip bgp summary e show ip route summary. Il processo dello scanner BGP esamina la tabella BGP per aggiornare le strutture di dati e la tabella di routing per la ridistribuzione delle route. In questo contesto, la tabella di routing è nota anche come tabella RIB (Routing Information Base), generata dal router quando si esegue il comando ;show ip route). Entrambe le tabelle vengono memorizzate separatamente nella memoria del router e possono essere di grandi dimensioni e utilizzare cicli della CPU.

L'output di esempio successivo del comando debug ip bgp updates cattura un'esecuzione dello scanner BGP:

router#

2d17h: BGP: scanning routing tables

2d17h: BGP: 10.0.0.0 computing updates, neighbor version 8,

table version 9, starting at 0.0.0.0

2d17h: BGP: 10.0.0.0 update run completed, ran for 0ms, neighbor

version 8, start version 9, throttled to 9, check point net 0.0.0.0

2d17h: BGP: 10.1.0.0 computing updates, neighbor version 8,

table version 9, starting at 0.0.0.0

2d17h: BGP: 10.1.0.0 update run completed, ran for 4ms, neighbor

version 8, start version 9, throttled to 9, check point net 0.0.0.0

router#

Mentre lo scanner BGP è in esecuzione, i processi a bassa priorità devono attendere più tempo per accedere alla CPU. Un processo a bassa priorità controlla i pacchetti ICMP (Internet Control Message Protocol), ad esempio i ping. I pacchetti destinati al router o originati dal router possono sperimentare una latenza più alta del previsto perché il processo ICMP deve attendere dietro lo scanner BGP. Il ciclo è che lo scanner BGP viene eseguito per un certo periodo di tempo e si sospende, quindi viene eseguito ICMP. Al contrario, i ping inviati tramite un router devono essere commutati tramite Cisco Express Forwarding (CEF) e non devono sperimentare alcuna latenza aggiuntiva. Quando si risolvono i problemi relativi ai picchi periodici di latenza, confrontare i tempi di inoltro dei pacchetti inoltrati tramite un router con i pacchetti elaborati direttamente dalla CPU sul router.

Nota: I comandi ping che specificano le opzioni IP, ad esempio il percorso dei record, richiedono anche che la CPU le elabori direttamente e possono causare ritardi di inoltro più lunghi.

Utilizzare il processo show | includere il comando bgp scanner per verificare la priorità della CPU. Il valore di Lsi nell'output del campione successivo utilizza L per fare riferimento a un processo a bassa priorità.

6513#show processes | include BGP Scanner

172 Lsi 407A1BFC       29144     29130    1000 8384/9000  0 BGP Scanner

CPU elevata a causa del processo del router BGP

Il processo del router BGP viene eseguito circa una volta al secondo per verificare la presenza di eventuali errori. La convergenza BGP definisce la durata tra il momento in cui viene stabilito il primo peer BGP e il punto in cui BGP converge. Per garantire la massima convergenza possibile, il router BGP utilizza tutti i cicli liberi della CPU. Tuttavia, una volta avviato, cede (o sospende) la CPU in modo intermittente.

Il tempo di convergenza è una misurazione diretta del tempo impiegato dal router BGP sulla CPU, non del tempo totale. Questa procedura mostra un'elevata condizione della CPU durante la convergenza BGP e scambia i prefissi BGP con due peer BGP (eBGP) esterni.

1. Acquisire una baseline per il normale utilizzo della CPU prima di avviare il test.

router#show process cpu

CPU utilization for five seconds: 0%/0%; one minute: 4%; five minutes: 5%

2. Una volta avviato il test, la CPU raggiunge il 100% di utilizzo. Il comando show process cpu mostra che l'alta condizione della CPU è causata dal router BGP, identificato da 139 (l'ID processo Cisco IOS per il router BGP) nell'output successivo.

router#show process cpu

CPU utilization for five seconds: 100%/0%; one minute: 99%; five minutes: 81%

!--- Output omitted.

139     6795740   1020252       6660 88.34% 91.63% 74.01%   0 BGP Router

3. È possibile monitorare e acquisire più output del comando show ip bgp summary e show process cpu in questo momento. Il comando show ip bgp summary acquisisce lo stato dei router BGP adiacenti.

router#show ip bgp summary

Neighbor    V    AS  MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down State/PfxRcd

10.0.0.0    4  64512  309453  157389    19981    0  253 22:06:44 111633

10.1.0.0  4  65101  188934    1047    40081   41    0 00:07:51 58430

4. Quando il router completa lo scambio dei prefissi con i suoi peer BGP, le percentuali di utilizzo della CPU ritornano ai livelli normali. Anche le medie calcolate di un minuto e cinque minuti possono regredire e mostrare livelli superiori al normale per un periodo più lungo rispetto alla frequenza di cinque secondi.

router#show process cpu

CPU utilization for five seconds: 3%/0%; one minute: 82%; five minutes: 91%

5. Usare l'output acquisito dai comandi show precedenti per calcolare il tempo di convergenza BGP. In particolare, usare la colonna Su/Giù< /strong> del comando show ip bgp summary e confrontare i tempi di inizio e di fine della condizione di CPU alta. In genere, la convergenza BGP può richiedere alcuni minuti quando si utilizza una tabella di routing di Internet di grandi dimensioni. è scambiato

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