Considerazioni sulla scala BGP RR e monitoraggio KPI

Introduzione

Questo documento descrive i principali fattori che contribuiscono alla massima scalabilità che un Border Gateway Protocol (BGP) Route-Reflector (RR) può raggiungere e le linee guida per il monitoraggio delle prestazioni del BGP RR.

Selezione piattaforme hardware/software

Un record di risorse BGP su larga scala non è in genere presente nel percorso di inoltro dei pacchetti che trasportano i servizi forniti da un provider di servizi Internet. Pertanto, i requisiti hardware per un router BGP RR e per i router che inoltrano principalmente i pacchetti nel percorso dati sono diversi. I router standard sono costruiti con un potente elemento di inoltro del percorso dati e un elemento del percorso di controllo relativamente moderato. Un record di risorse BGP esegue tutte le attività in un piano di controllo.
All'interno della famiglia di prodotti Cisco IOS® XR, è possibile scegliere tra 3 tipi di piattaforme HW/SW per un ruolo BGP RR:

Router Cisco IOS XR fisico	Appliance Cisco IOS XRv 9000	Cisco IOS XRv 9000 Router (alias XRv9k)
Capacità moderata del control plane (generalmente tra 2 e 6 core CPU allocati alla VM RP XR) Capacità del percorso dati non utilizzata	Elevata capacità del control plane (sull'appliance Cisco UCS M5 i 36 core CPU sono dedicati a VM RP XR) Divisione equa tra capacità del percorso dati e del percorso di controllo. L'immagine XRv9k viene eseguita su barebone per ottenere le massime prestazioni	Capacità personalizzabile del control plane Divisione uniforme tra l'alimentazione del percorso dati e del percorso di controllo quando si utilizza l'immagine BGP RR. Un ulteriore livello di virtualizzazione influisce sulle prestazioni.

Al momento della stesura di questo documento, l'appliance XRv9k è la scelta ottimale per la piattaforma BGP RR, in quanto fornisce la massima capacità del control plane e le massime prestazioni.

Considerazioni Su Scalabilità E Prestazioni

La scala supportata delle entità del piano dati è relativamente facile da esprimere perché le prestazioni dell'elemento del percorso dati dipendono raramente dalla scala. Ad esempio, una ricerca TCAM richiede lo stesso tempo indipendentemente dal numero di voci TCAM attive.
La scala supportata delle entità del piano di controllo è spesso molto più complessa perché la scala e le prestazioni sono interconnesse. Prendiamo in considerazione un record di risorse BGP con 1 milione di route. Il lavoro che un processo BGP deve eseguire per mantenere questa tabella BGP dipende da:

1. Quanti peer BGP sono attivi?
2. Quali famiglie di indirizzi sono attive?
3. In che modo sono distribuiti nei gruppi di aggiornamento?
4. La complessità delle RPL (Route Policies)
5. Frequenza degli aggiornamenti (aggiornamenti in ingresso e aggiornamenti in uscita - intervallo di annunci).
6. TCP MSS, MTU di interfaccia/percorso: la regolazione di questo valore consente di migliorare le prestazioni 
7. Se Dual-RP, NSR è abilitato
8. Tutti i peer lenti noti, che non si trovano in un gruppo di aggiornamento separato
9. Valore trigger-delay successivo

Numero di peer BGP

Il numero di peer BGP è solitamente il primo e, sfortunatamente, spesso l'unica cosa che viene in mente quando si considera la scala BGP. Anche se la scala BGP supportata non può essere rappresentata senza menzionare il numero di peer BGP, non è il fattore più importante. Molti altri aspetti sono ugualmente rilevanti.

Famiglie di indirizzi

Il tipo di famiglia di indirizzi (AF, Address Family) è un fattore importante nelle considerazioni sulle prestazioni BGP, in quanto nelle implementazioni tipiche influisce sulle dimensioni di una singola route. Il numero di route IPv4 che possono essere compresse in un singolo segmento TCP è notevolmente superiore al numero di route VPNv4. Pertanto, per le stesse modifiche alla tabella BGP, un record di risorse BGP IPv4 ha meno lavoro da fare rispetto a un record di risorse BGP VPNv4. Ovviamente, nelle implementazioni in cui un numero significativo di comunità viene aggiunto a ogni percorso, la differenza tra le AF diventa meno significativa, ma la dimensione di un singolo percorso è poi ancora più grande e richiede una considerazione. 

Numero di gruppi di aggiornamento

Il processo BGP prepara un singolo aggiornamento per tutti i membri dello stesso gruppo di aggiornamento. Il processo TCP suddivide i dati di aggiornamento in un numero richiesto di segmenti TCP (a seconda del valore TCP MSS) verso ciascun membro del gruppo di aggiornamento. Per visualizzare i gruppi di aggiornamento attivi e i relativi membri, utilizzare il show bgp update-group comando. È possibile determinare quali e quanti peer sono membri di un gruppo di aggiornamento creando un criterio in uscita comune per un gruppo di peer che si desidera includere nello stesso gruppo di aggiornamento. Un singolo aggiornamento inviato da BGP RR a un numero elevato di client BGP RR può attivare una frammentazione di ACK TCP che possono essere scartati nel componente Local Packet Transport Service (LPTS) dei router Cisco IOS XR.

Complessità delle RPL (Route Policies)

La complessità delle policy di routing utilizzate da BGP influisce sulle prestazioni del processo BGP. Ogni route ricevuta o inviata deve essere valutata in base ai criteri di route configurati. Un criterio molto lungo richiede molti cicli della CPU da utilizzare per questa azione. I criteri di route che includono un'espressione regolare sono particolarmente complessi da elaborare. Un'espressione regolare consente di esprimere il criterio di route in un numero di righe inferiore, ma richiede più cicli di CPU durante l'elaborazione rispetto al criterio di route equivalente che non utilizza l'espressione regolare. 

Frequenza Di Aggiornamento

La frequenza degli aggiornamenti ha un'incidenza importante sulla scala BGP. Il numero di aggiornamenti è spesso difficile da prevedere. È possibile influenzare la frequenza degli aggiornamenti utilizzando il comando "advertising-interval" per impostare l'intervallo minimo tra l'invio degli aggiornamenti di routing (BGP). Il valore predefinito per i peer iBGP è 0 secondi e 30 per i peer eBGP è 30 secondi.

TCP MSS e MTU interfaccia/percorso

La suddivisione di un aggiornamento in molti segmenti TCP può mettere a dura prova le risorse di processo TCP in un ambiente ad alta scala e ad alta frequenza di aggiornamento. Una MTU del percorso più grande e un TCP MSS più grande sono migliori per le prestazioni BGP e TCP.


NSR su router Dual-RP

L'NSR è una grande funzione per la ridondanza, ma ha un impatto sulle prestazioni BGP. Sui router Cisco IOS XR entrambi gli RP ricevono simultaneamente ogni aggiornamento BGP direttamente dalla NPU sulla scheda di linea in entrata, il che significa che l'RP attivo non deve impiegare tempo per replicare l'aggiornamento all'RP in standby. Tuttavia, ogni aggiornamento generato dall'RP attivo deve essere inviato all'RP in standby e da lì al peer BGP. In questo modo l'RP in standby è sempre aggiornato sui numeri di sequenza e riconoscimento, ma ha un impatto sulle prestazioni BGP complessive. Per questo motivo, si consiglia che un router BGP RR sia un router a RP singola.

Peer lenti

Un peer lento può rallentare gli aggiornamenti verso tutti i membri del gruppo di aggiornamento perché il processo BGP deve mantenere l'aggiornamento nella sua memoria fino a quando tutti i peer non lo riconoscono. Se si è a conoscenza del fatto che alcuni peer sono molto più lenti (ad esempio i router di una parte legacy della rete), separarli in un gruppo di aggiornamento. Per impostazione predefinita, Cisco IOS XR segnala un peer lento tramite un messaggio syslog. È possibile creare peer lenti statici (che non condividono mai il gruppo di aggiornamento con altri utenti) o ottimizzare il comportamento del peer lento dinamico utilizzando il comando di configurazione BGPslow-peer in modalità di configurazione globale o per router adiacenti. Per ulteriori informazioni, vedere il documento sulla risoluzione dei problemi di convergenza BGP lenta a causa di policy di route non ottimali su IOS-XR sul portale Cisco xrdocs.io. 

Ritardo trigger Nexthop

Se più hop BGP successivi cambiano in un breve intervallo di tempo e il valore critico di ritardo di attivazione del nexthop pari a zero è configurato in una famiglia di indirizzi (AF) con un numero elevato di route, è necessario eseguire una procedura completa dell'AF a ogni evento di modifica dell'hop successivo. Le ripetute passeggiate di tale AF aumentano il tempo di convergenza nelle famiglie di indirizzi con valori di ritardo di trigger nexthop critici inferiori. Per visualizzare i valori di ritardo del trigger dell'hop successivo, eseguire il comando "show bgp all nexthops".

Esempio di scala BGP RR multidimensionale convalidata

I risultati della scala multidimensionale, in particolare per le feature del piano di controllo, dipendono in modo significativo dall'ambiente di prova specifico. I risultati dei test possono variare in modo significativo se alcuni parametri vengono modificati.

Parametro	Valore	Valore
Piattaforma	Appliance XRv9k (basata su UCS M5)	ASR 9902
IOS XR release	7.5.2 + SMU ombrello per Cisco ID bug CSCwf09600 . (i componenti di questo SMU sono integrati in Cisco IOS XR versione 7.9.2 e successive)	7.11.2
Peer	VPN eBGP: 2500 VPNv4 iBGP: 1700	VPNv4 iBGP: 2000
Route BGP	Per sessione: 200 Totale: 400k Percorsi per route: 1	Per sessione: 750 VPNv4: 1,36 M VPNv6: 150.000 IPv4: 950 k IPv6: 200 k Totale: circa 2,6 M Percorsi per route: 1
Route IGP	10k (ISIS)	10k (ISIS)
Gruppi di aggiornamento BGP	1	1
Timer BGP	predefinito	predefinito
Frequenza policer noti BGP LPTS	50,000	25,000
configurazione num-thread tcp	16 16	16 16
Dimensione buffer di invio BGP	predefinito	predefinito
Riepilogo indicatori prestazioni chiave (KPI)	Test case con la massima velocità dei pacchetti di input e output: Ingresso: 49,4 kpps Uscita: 95 kpps ==> Cadute LPTS (policer a 50 kpps) ==> Nessun calo nei client NetIO ==> Dimensione massima coda XIPC (BGP): 1362 ==> Dimensione massima coda XIPC (TCP): 1248	Test case con la massima velocità dei pacchetti di input: Ingresso: 16030 pkts/s Uscita: 31 pkt/s ==> Nessun calo nei client LPTS o NetIO ==> Dimensione massima coda XIPC (BGP): 378 ==> Dimensione massima coda XIPC (TCP): 1021 Test case con la massima velocità del pacchetto di output: Ingresso: 12172 pkts/s Uscita: 23465 pkts/s ==> Nessun calo nei client LPTS o NetIO ==> Dimensione massima coda XIPC (BGP): 109 ==> Dimensione massima coda XIPC (TCP): 1518

Considerazioni sulla progettazione

Esistono due approcci al posizionamento di BGP RR nella rete:

1. Design BGP RR centralizzato/piatto.
2. Progetto BGP RR distribuito/gerarchico.

In un design centralizzato/piatto, tutti i client BGP RR nella rete stabiliscono il peering BGP con un set (di solito una coppia) di dispositivi BGP RR che contengono esattamente le stesse informazioni. Questo approccio è semplice da implementare e funziona bene nelle reti di piccole e medie dimensioni. Qualsiasi modifica nella tabella BGP viene propagata rapidamente a tutti i client BGP RR. Con l'aumento del numero di client BGP RR, la progettazione può raggiungere un limite di scala quando il numero di connessioni TCP sui dispositivi BGP RR aumenta in modo da influire sulle prestazioni.


In una struttura distribuita/gerarchica, la rete è suddivisa in più aree. Tutti i router di una regione stabiliscono il peering BGP con un set (di solito una coppia) di dispositivi BGP RR che contengono esattamente le stesse informazioni. Questi dispositivi BGP RR agiscono da client BGP RR per un altro set di dispositivi BGP RR, in genere una coppia. Questo approccio progettuale consente una facile espansione della rete, mantenendo al contempo il numero di connessioni TCP su ogni singola RR BGP sotto un certo limite.
Un'altra considerazione a livello di progettazione è la personalizzazione dell'ambito dei destinatari degli aggiornamenti BGP. A seconda della distribuzione VRF tra i client BGP RR, vale la pena considerare la distribuzione della route vincolata RT. Se tutti i client BGP RR dispongono di interfacce nello stesso VRF, la distribuzione delle route vincolate RT non comporta molti vantaggi. Tuttavia, se i VRF vengono distribuiti in modo sparso tra tutti i client BGP RR, l'uso di RT Constrained Route Distribution riduce in modo significativo il carico sul processo BGP RR.

Monitoraggio degli indicatori di prestazioni chiave (KPI) BGP

Il monitoraggio degli indicatori di prestazioni chiave (KPI) di BGP RR è importante per garantire il corretto funzionamento della rete. 


Un cambiamento significativo nella topologia di rete (ad esempio un link flap del DWDM principale) può attivare aggiornamenti del routing che generano un traffico eccessivo verso e/o dal router BGP RR. Il traffico significativo che colpisce il record di risorse BGP in genere comporta:

1. Aggiornamenti dai peer BGP.
2. ACK TCP generati dai peer BGP, in risposta agli aggiornamenti inviati da RR BGP e viceversa

In questa sezione del documento viene spiegato l'indicatore KPI che deve essere monitorato su un tipico record di risorse BGP e viene spiegato anche come stabilire quale dei due tipi di traffico BGP significativi sta causando un'alta velocità di controllo del traffico aereo.

Il percorso dei pacchetti BGP all'interno del router può essere rappresentato come segue:

Punt
Controller Ethernet -(packet)-> datapath forwarder -(packet)-> LPTS -(packet)-> SPP -(packet) -> NetIO -(packet)-> TCP -(message)-> BGP

Inserisci
BGP -(messaggio)-> TCP -(pacchetto)-> NetIO -(pacchetto)-> SPP -(pacchetto) -> datapath forwarder -(pacchetto)-> Ethernet controller

Gli indicatori KPI possono essere suddivisi in:


Caratteristiche principali:

1. Server d'inoltro datapath
2. LPTS (impostazioni dei criteri punt hardware, accetta contatori e contatori drop)
3. SPP
4. NetIO
5. Code IPC (NetIO <=> TCP <=> BGP)
6. Dimensioni InQ/OutQ BGP

Facoltativo:

1. Utilizzo CPU
2. Utilizzo della memoria
3. statistiche TCP
4. Prestazioni del processo BGP
5. Convergenza BGP

Monitor Datapath Forwarder

Su XRv9000 il server di inoltro dei percorsi dati è l'agente DPA (Data Plane Agent), mentre sulle piattaforme ASR9000 è l'np (Network Processor).

Monitorare l'agente DPA XRv9000

Il comando utile per visualizzare il carico e le statistiche di DPA è:

   show controllers dpa statistics global 

Questo comando mostra tutti i contatori diversi da zero, che forniscono informazioni sul tipo e sul numero di pacchetti inviati dalle interfacce di rete alla CPU RP, iniettati dalla CPU RP verso le interfacce di rete, e sul numero di pacchetti scartati:

RP/0/RP0/CPU0:xrv9k-01#show controllers dpa statistics global Index Debug Count ---------------------------------------------------------------------------- 350 TBPG L2 mailbox events 1 Index Punt Count ---------------------------------------------------------------------------- 1500 CDP 46790 1503 ARP 212 1611 IFIB 595305 1776 LLDP 94037 2001 IPv4 incomplete Tx adjacency 2 Index Inject Count ---------------------------------------------------------------------------- 744 CLNS multicast from fabric pre-route 321250 749 IPv4 from fabric 273993 765 Inject to fabric 595245 766 Inject to port 141033 Index Drop Count ---------------------------------------------------------------------------- 416 Egress UIDB in down state 1 474 IPv4 egress UIDB down 2 673 Pre-route PIT lookup missed 2

Monitor ASR9000 Network Processor (NP)

I comandi utili per visualizzare il carico e le statistiche di ogni NP nel sistema sono:

   show controllers np load all

   show controllers np counters all

NP su ASR9000 ha un ricco set di contatori che mostrano il numero, la frequenza e il tipo di pacchetti elaborati e scartati,.

RP/0/RSP0/CPU0:ASR9k-B#show controllers np load all Node: 0/0/CPU0: ---------------------------------------------------------------- Load Packet Rate NP0: 0% utilization 937 pps NP1: 0% utilization 538 pps RP/0/RSP0/CPU0:ASR9k-B#

RP/0/RSP0/CPU0:ASR9k-B#show controllers np counters all Node: 0/0/CPU0: ---------------------------------------------------------------- Show global stats counters for NP0, revision v4 Last clearing of counters for this NP: NEVER Read 92 non-zero NP counters: Offset Counter FrameValue Rate (pps) ------------------------------------------------------------------------------------- 16 MDF_TX_LC_CPU 25475368 10 17 MDF_TX_WIRE 681957877 267 21 MDF_TX_FABRIC 683500690 267 33 PARSE_FAB_RECEIVE_CNT 681767730 267 37 PARSE_INTR_RECEIVE_CNT 1323024637 517 41 PARSE_INJ_RECEIVE_CNT 13949634 5 45 PARSE_ENET_RECEIVE_CNT 677655725 265 49 PARSE_TM_LOOP_RECEIVE_CNT 49331192 19 53 PARSE_TOP_LOOP_RECEIVE_CNT 1520846 1 109 RSV_DROP_EGR_UIDB_NO_MATCH 10 0 146 RSV_DROP_IPV4_RXADJ_DROP 1 0 164 RSV_DROP_ING_LAG_NO_MATCH 3 0 241 RSV_DROP_MPLS_LEAF_NO_MATCH 1312 0 <. . .> 

Monitoraggio LPTS

Poiché un RR BGP standard non è nel percorso di inoltro, tutti i pacchetti ricevuti sull'interfaccia di rete vengono indirizzati al control-plane. L'elemento data-path su un RR BGP esegue un piccolo numero di semplici operazioni prima che i pacchetti vengano puntati al control-plane. Poiché è improbabile che l'elemento del percorso dati sia un punto di congestione, l'unico elemento della scheda di linea che deve essere monitorato è lo stato LPTS.

Nel caso di XRv9k, le statistiche dell'hardware vengono mappate sul vPP 

Comando:

  show lpts pifib hardware police location <location> | inc "Node|flow_type|BGP"

Esempio:

RP/0/RP0/CPU0:xrv9k-01#sh lpts pifib hardware police location 0/0/CPU0 | i "Node|flow_type|BGP" Node 0/0/CPU0: flow_type priority sw_police_id hw_policer_addr Cur. Rate burst static_avgrate avgrate_type AggrAccepts AggrDrops TOS Value BGP-known high 6 220 50000 1250 2500 Global 16401392 0 01234567 BGP-cfg-peer medium 7 221 4000 1000 2000 Global 355976 1563 01234567 BGP-default low 8 222 3000 750 1500 Global 5212380 0 01234567 RP/0/RP0/CPU0:xrv9k-01# 

Cosa cercare:
Se si osserva un salto significativo di AggDrops rispetto al tipo di flusso noto BGP, iniziare a cercare le modifiche della topologia di rete che hanno attivato tale cambiamento massiccio del control plane.

Percorso dati di telemetria:

  Cisco-IOS-XR-lpts-pre-ifib-oper:lpts-pifib

SPP monitor

L'SPP è la prima entità sulla CPU del processore di routing o della scheda di linea che riceve il pacchetto puntato dall'NP o da DPA tramite la struttura interna e l'ultimo punto nell'elaborazione del pacchetto software prima di essere consegnato al fabric per l'iniezione nell'NP o DPA.

Comandi relativi al monitoraggio SPP:

show spp node-counters

show spp client

Il show spp node-counters  comando mostra la frequenza dei pacchetti puntati/iniettati ed è di facile lettura e comprensione. Per le sessioni BGP, i contatori rilevanti si trovano sotto client/punt  e client/inject  sul RP attivo.

La funzione show spp client  è più ricca di output e offre una visione più dettagliata del numero di pacchetti accodati/scartati verso i client, nonché del limite massimo.

RP/0/RP0/CPU0:xrv9k-01#show spp node-counters 0/RP0/CPU0: socket/rx Punted packets: 595305 Punt bulk reads: 6 Punt non-bulk reads: 595293 Management packets: 74200158 Management bulk reads: 1775930 Management non-bulk reads: 70031734 ------------------------------- socket/tx Injected packets: 595245 Management packets: 139939168 ------------------------------- xrv9k/classify Forwarded to SPP clients: 74795463 ------------------------------- client/inject Injected from client: 140534413 Non-bulk injects: 140534413 ------------------------------- client/punt punted to client: 74795371 no client found - send to defa: 92 ------------------------------- 0/0/CPU0: <. . .>

RP/0/RP0/CPU0:xrv9k-01#show spp client Sat Apr 20 17:11:40.725 UTC 0/RP0/CPU0: Clients ======= <. . .> netio, JID 254 (pid 4591) ---------------------------------------------------------- Reconnect Pending: F, Exited: F, Keep Queues: F, Pakman Client: T Quota Current: 0, Limit: 16384, Drops 0 Queues: Key Cur Max Enqueues High Watermark (Timestamp) Drops 0xffffffff 0 10 0 0 (22:13:52.195 Feb 21 24 UTC) 0 0x03000006 0 2048 0 0 (22:13:52.196 Feb 21 24 UTC) 0 0x03000007 0 3072 414881 1 (23:03:30.721 Feb 21 24 UTC) 0 0x03000008 0 1024 5 1 (13:41:28.389 Mar 13 24 UTC) 0 0x03000009 0 2048 180411 1 (23:03:31.565 Feb 21 24 UTC) 0 

Monitorare NetIO

Mentre il policer LPTS mostra solo il conteggio dei pacchetti accettati o scartati da un policer corrispondente, a livello NetIO è possibile vedere la frequenza dei pacchetti puntati alla CPU RP. Poiché su un tipico RR BGP la grande maggioranza dei pacchetti ricevuti sono pacchetti BGP, la velocità complessiva di NetIO indica molto da vicino la velocità dei pacchetti BGP ricevuti.

Command:
show netio rates 

Esempio:

RP/0/RP0/CPU0:xrv9k-01#show netio rates Netio packet rate for node 0/RP0/CPU0 ----------------------------------- Current rate (updated 0 seconds ago): Input: 7845 pkts/s Output: 10570 pkts/s Driver Output: 10598 pkts/s 1 minute rate (updated 0 seconds ago): Input: 7825 pkts/s Output: 10542 pkts/s Driver Output: 10569 pkts/s 5 minute rate (updated 0 seconds ago): Input: 7997 pkts/s Output: 10677 pkts/s Driver Output: 10704 pkts/s RP/0/RP0/CPU0:xrv9k-01# 

Cosa cercare:

• Se si osserva un aumento significativo della frequenza NetIO, iniziare a cercare le modifiche della topologia di rete che hanno attivato tale cambiamento massiccio del control plane.


Percorso dati di telemetria:

• non applicabile in quanto la telemetria deve trasmettere i valori dei contatori, non le velocità. Il contatore di accettazione del policer LPTS noto di BGP può essere utilizzato sul collettore di telemetria per approssimare la velocità media dei pacchetti BGP ricevuti da peer noti.

Monitoraggio delle code XIPC

Sul percorso punt, i pacchetti ricevuti da NetIO da LPTS vengono passati a TCP e BGP. È importante monitorare queste code:
1. Coda TCP ad alta priorità attraverso la quale NetIO consegna i pacchetti al TCP
2. Coda di controllo BGP
3. Coda dati BGP

Sul percorso di inserimento, i pacchetti vengono creati dal protocollo TCP e passati a NetIO. È importante monitorare queste code:

1. Coda XIPC OutputL

Comandi:

show netio clients show processes bgp | i "Job Id" show xipcq jid <bgp_job_id> show xipcq jid <bgp_job_id> queue-id <n>

Esempi:

Da NetIO a TCP, vista dal punto di vista di NetIO:

RP/0/RP0/CPU0:xrv9k-01#show netio clients <. . .> Input Punt XIPC InputQ XIPC PuntQ ClientID Drop/Total Drop/Total Cur/High/Max Cur/High/Max <. . .> tcp L 0/340774 0/0 L 0/10/12800 0/0/0 H 0/44774091 H 0/784/12800

Da TCP a NetIO, vista dal punto di vista NetIO:

RP/0/RP0/CPU0:xrv9k-01#show netio clients <. . .> XIPC queues Dropped/Queued Cur/High/Max ------------------------------------------------------------ OutputL 124860/9355257 0/14000/14000 

Da NetIO a TCP, vista dal punto di vista del processo TCP:

RP/0/RP0/CPU0:xrv9k-01#show processes tcp | i "Job Id"
 Job Id: 430
RP/0/RP0/CPU0:xrv9k-01#show xipcq jid 430 Mon Apr 17 16:16:11.315 CEST Id Name Size Cur Size Produced Dropped HWM ------ ------------------------------- ------ --------- ----------- ----------- -------- 17 XIPC_xipcq_12_0_9854_6506_i... 60000 0 39010269 0 960 16 XIPC_xipcq_12_0_9854_6506_i... 24000 0 31518436 0 1364 15 XIPC_tcp_124 3200 0 0 0 0 14 XIPC_tcp_125 9600 0 0 0 0 13 XIPC_tcp_psb_0 25600 0 0 0 0 10 XIPC_tcp_iq_9 102400 0 9486010 0 312 12 XIPC_tcp_iq_8 102400 0 8892274 0 280 9 XIPC_tcp_iq_5 102400 0 8291392 0 289 11 XIPC_tcp_iq_7 102400 0 9700123 0 319 8 XIPC_tcp_iq_6 102400 0 9378703 0 332 7 XIPC_tcp_iq_3 102400 0 7221706 0 261 6 XIPC_tcp_iq_4 102400 0 9791070 0 308 4 XIPC_tcp_ctrl_iq_1 4266 0 0 0 0 5 XIPC_tcp_iq_2 102400 0 9699027 0 295 3 XIPC_tcp_ctrl_iq_0 4266 0 209909 0 9 2 XIPC_tcp_i1 12800 0 39460564 0 784 1 XIPC_tcp_i0 12800 0 212540 0 10 

Da TCP a BGP:

RP/0/RP0/CPU0:xrv9k-01#show processes bgp | i "Job Id" Job Id: 1078 RP/0/RP0/CPU0:xrv9k-01#show xipcq jid 1078 Mon Apr 17 16:09:33.046 CEST Id Name Size Cur Size Produced Dropped HWM ------ ------------------------------- ------ --------- ----------- ----------- -------- 2 XIPC_xipcq_12_0_9854_6506_i... 60000 2 35546667 0 15034 1 XIPC_xipcq_12_0_9854_6506_i... 24000 0 1369029 0 50 RP/0/RP0/CPU0:xrv9k-01# 

Coda dati BGP:

RP/0/RP0/CPU0:xrv9k-01#show xipcq jid 1078 queue-id 1 XIPC_xipcq_12_0_9854_6506_inst_1_data_toapp: Magic: 12344321 Version: 0 SHM Size: 192392 Owner PID: 9854 Owner JID: 1078 Queue ID: 1 Owner MQ handle: 483 User Context: 0x64 Interrupt Flag: 0 Sent-on-full Flag: 0 Max Queue Size: 24000 Queue Size: 0 Client Queue Size: 24000 High watermark: 50 Last Trigger Sent: Mon Apr 17 16:11:10.009 CEST MQ Send Errors: 0 Priority Queues: Prio Size Drops Total ---------- ---------- ---------- ---------- Unspec 24000 0 0 Normal 24000 0 1396159 Medium 24000 0 0 High 24000 0 0 Crucial 24000 0 0 RP/0/RP0/CPU0:xrv9k-01# 

Coda di controllo BGP:

RP/0/RP0/CPU0:xrv9k-01#show xipcq jid 1078 queue-id 2 XIPC_xipcq_12_0_9854_6506_inst_1_ctrl_toapp: Magic: 12344321 Version: 0 SHM Size: 480392 Owner PID: 9854 Owner JID: 1078 Queue ID: 2 Owner MQ handle: 485 User Context: 0x64 Interrupt Flag: 0 Sent-on-full Flag: 0 Max Queue Size: 60000 Queue Size: 0 Client Queue Size: 60000 High watermark: 15034 Last Trigger Sent: Mon Apr 17 16:12:49.483 CEST MQ Send Errors: 0 Priority Queues: Prio Size Drops Total ---------- ---------- ---------- ---------- Unspec 60000 0 0 Normal 60000 0 37313633 Medium 60000 0 0 High 60000 0 0 Crucial 60000 0 0 RP/0/RP0/CPU0:xrv9k-01# 

Cosa cercare:

• non devono esserci cali nelle code rilevanti
• negli stati della coda XIPC il limite massimo (High Watermark, HWM) non deve superare il 50% delle dimensioni della coda


Per tenere traccia in modo più accurato dell'evoluzione del valore di filigrana elevato, è necessario cancellare tale valore dopo ogni lettura. Si noti che questa operazione non cancella solo il contatore HWM, ma cancella anche tutte le statistiche della coda. Il formato del comando per cancellare le statistiche della coda XIPC è: clear xipcq statistics queue-name <queue_name>

Poiché il nome della coda spesso include l'ID processo (PID), il nome della coda cambia dopo il riavvio del processo.
Di seguito sono riportati alcuni esempi di comandi per cancellare le statistiche relative alle code:

  clear xipcq statistics queue-name XIPC_tcp_i0
  clear xipcq statistics queue-name XIPC_tcp_i1
  clear xipcq statistics queue-name XIPC_xipcq_12_0_9854_6506_inst_1_data_toapp
  clear xipcq statistics queue-name XIPC_xipcq_12_0_9854_6506_inst_1_ctrl_toapp

Percorso di telemetria:

• Nessun percorso dei sensori di telemetria per XIPC.

Monitoraggio delle code di input e output BGP

BGP mantiene una coda di input e output per ogni peer BGP. I dati risiedono in InQ quando il protocollo TCP li ha passati a BGP, ma BGP non li ha ancora elaborati. I dati risiedono in OutQ mentre BGP attende su TCP di suddividere i dati in pacchetti e trasmetterli. Le dimensioni istantanee di BGP InQ/OutQ forniscono una buona indicazione di quanto è occupato il processo BGP.


Comando:

show bgp <AFI> <SAFI> summary

Esempio:

RP/0/RP0/CPU0:xrv9k-01#show bgp all all summary Address Family: VPNv4 Unicast ----------------------------- BGP router identifier 192.168.0.1, local AS number 65000 BGP generic scan interval 60 secs BGP table state: Active Table ID: 0x0 BGP main routing table version 2208096 BGP scan interval 60 secs BGP is operating in STANDALONE mode. Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer Speaker 2208096 2208096 2208096 2208096 2208096 2208096 Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd 10.0.0.2 0 65000 180 601022 2208096 0 0 02:56:18 100 10.0.0.3 0 65000 180 601022 2208096 0 0 02:56:18 100 10.0.0.4 0 65000 180 601022 2208096 0 0 02:56:21 100 10.0.0.5 0 65000 180 601022 2208096 0 0 02:56:21 100 10.0.0.6 0 65000 180 601022 2208096 0 0 02:56:18 100 

Cosa cercare:

• Le dimensioni di InQ/OutQ devono essere pari a zero quando la rete è stabile. Cambia rapidamente quando si scambiano gli aggiornamenti.
• Le dimensioni di InQ/OutQ non devono aumentare in modo monotono nel tempo.

Percorso di telemetria:

• Cisco-IOS-XR-ipv4-bgp-oper:bgp

Monitoraggio delle velocità dei messaggi BGP

Alcuni router BGP adiacenti possono inviare continuamente aggiornamenti o ritiri se la topologia di rete è instabile. Il record di risorse BGP deve quindi replicare tale tabella di routing per migliaia di volte in tutti i relativi client di risorse. Pertanto è importante monitorare le frequenze dei messaggi ricevuti dai vicini, per tenere traccia delle fonti di instabilità.


Comando:

show bgp <AFI> <SAFI> summary

Esempio:

RP/0/RP0/CPU0:xrv9k-01#show bgp all all summary Address Family: VPNv4 Unicast ----------------------------- BGP router identifier 192.168.0.1, local AS number 65000 BGP generic scan interval 60 secs BGP table state: Active Table ID: 0x0 BGP main routing table version 2208096 BGP scan interval 60 secs BGP is operating in STANDALONE mode. Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer Speaker 2208096 2208096 2208096 2208096 2208096 2208096 Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd 10.0.0.2 0 65000 180 601022 2208096 0 0 02:56:18 100 10.0.0.3 0 65000 180 601022 2208096 0 0 02:56:18 100 10.0.0.4 0 65000 180 601022 2208096 0 0 02:56:21 100 10.0.0.5 0 65000 180 601022 2208096 0 0 02:56:21 100 10.0.0.6 0 65000 180 601022 2208096 0 0 02:56:18 100 

Le code dei client RR hanno all'incirca la stessa quantità di messaggi MsgSent, ma alcuni router adiacenti possono avere un numero di messaggi MsgRcvd superiore ad altri. È necessario acquisire più snapshot di questo comando per valutare la frequenza dei messaggi.

Una volta identificati i peer che causano l'errore, è possibile eseguire altri comandi come show bgp neighbor <neighbor> detail  and show bgp neighbor <neighbor> performance-statistics  o show bgp recent-prefixes  per cercare di capire quali prefissi stanno lampeggiando e se sono sempre gli stessi o diversi.

Monitoraggio utilizzo CPU

L'utilizzo della CPU deve essere monitorato su ogni router, ma su un router con un numero elevato di core CPU dedicati al control plane alcuni passaggi possono non essere intuitivi. In un record di risorse BGP con un numero elevato di core CPU dedicati al processore di routing (RP), come nel caso dell'accessorio XRv9k, i thread attivi vengono eseguiti su core CPU diversi, mentre un numero di core CPU rimane inattivo. Di conseguenza, alcuni core CPU possono essere molto occupati, ma l'utilizzo complessivo della CPU calcolato per tutti i core CPU rimane moderato.

Pertanto, per il corretto monitoraggio dell'utilizzo dei core CPU tramite CLI, utilizzare il show processes cpu thread  comando.

Monitoraggio delle statistiche TCP

Cisco IOS® gestisce statistiche dettagliate su ciascuna sessione TCP. Il comando CLI show tcp brief  visualizza l'elenco di tutte le sessioni TCP esistenti. In questo output di riepilogo, per ogni sessione TCP è possibile visualizzare le seguenti informazioni:

• PCB: identificatore univoco della sessione TCP.
• VRF-ID: l'ID del VRF in cui si trova la sessione.
  • Per visualizzare il nome VRF corrispondente, eseguire questo comando:
  • show cef vrf all summary | utility egrep "^VRF:|Vrfid" | utility egrep -B1 <VRF-ID>
• Recv-Q: dimensioni istantanee della coda di ricezione Q. La coda di ricezione contiene i pacchetti ricevuti da NetIO. Il processo tcp estrae i dati da un pacchetto e li invia all'applicazione corrispondente.
• Send-Q: dimensione istantanea della coda di invio. La coda di invio contiene i dati ricevuti da un'applicazione. Il processo tcp suddivide i dati in segmenti TCP (determinati dalle dimensioni massime del segmento negoziate - TCP MSS), incapsula ogni segmento in un'intestazione di layer 3 della famiglia di indirizzi corrispondente (IPv4 o IPv6) e invia il pacchetto a NetIO.
• Indirizzo locale: indirizzo IPv4 o IPv6 locale associato al socket TCP. Le sessioni TCP in stato LISTEN sono in genere associate a un indirizzo IP "any", rappresentato rispettivamente come "0.0.0.0" o "::" in caso di IPv4 o IPv6.
• Indirizzo esterno: indirizzo IPv4 o IPv6 remoto associato al socket TCP. Le sessioni TCP in stato LISTEN sono in genere associate a un indirizzo IP "any", rappresentato rispettivamente come "0.0.0.0" o "::" in caso di IPv4 o IPv6.
• Stato: lo stato della sessione TCP. Gli stati possibili della sessione TCP sono: LISTEN, SYNSENT, SYNRCVD, ESTAB, LASTACK, CLOSING, CLOSEWAIT, FINWAIT1, FINWAIT2, TIMEWAIT, CLOSED.

Poiché il numero di porta BGP noto è 179, è possibile limitare le sessioni TCP visualizzate a quelle associate all'applicazione BGP.

Esempio:

RP/0/RSP0/CPU0:ASR9k-B#show tcp brief | include "PCB|:179 " PCB VRF-ID Recv-Q Send-Q Local Address Foreign Address State 0x00007ff7d403bde0 0x60000000 0 0 :::179 :::0 LISTEN 0x00007ff7d403b020 0x60000002 0 0 :::179 :::0 LISTEN 0x00007ff7d403d130 0x60000000 0 0 192.168.0.4:50144 192.168.0.5:179 ESTAB 0x00007ff7a4025650 0x60000000 0 0 0.0.0.0:179 0.0.0.0:0 LISTEN 0x00007ff7a4024a50 0x60000002 0 0 0.0.0.0:179 0.0.0.0:0 LISTEN 

È possibile utilizzare il valore di PCB visualizzato per ottenere le statistiche per una particolare sessione TCP. Comandi CLI che forniscono informazioni dettagliate sulle statistiche dei processi TCP:

Globale:

  show tcp statistics clients location <active_RP>

  show tcp statistics summary location <active_RP>

Per PCB:

  show tcp brief | i ":179"

  show tcp detail pcb <pcb> location 0/RP0/CPU0

  show tcp statistics pcb <pcb> location <active_RP>

I comandi delle statistiche TCP globali mostrano lo stato complessivo delle sessioni TCP. A parte le statistiche dei pacchetti di dati (in/out), è possibile vedere per esempio se ci sono pacchetti con errori di checksum, pacchetti in formato non valido, pacchetti scartati a causa di errori di autenticazione, pacchetti non ordinati, pacchetti con dati dopo finestra, che dà un'indicazione del comportamento dei peer TCP.

Nei comandi per PCB, è possibile visualizzare parametri importanti di una sessione TCP, come MSS, tempo massimo di andata e ritorno e così via.

I contatori rilevanti nell'output del show tcp detail pcb comando sono:

• Avvio timer ritrasmissione: indica quante volte è stato avviato il timer di ritrasmissione.
• Retrans Timer Wakeups: indica quante volte si è esaurito il timer di ritrasmissione, attivando una ritrasmissione del segmento TCP.
• Dimensioni correnti della coda di invio in byte: byte non riconosciuti dal peer.
• Dimensioni correnti della coda di ricezione in byte/pacchetti: byte/pacchetti non ancora letti dall'applicazione (BGP).
• byte non ordinati: byte accodati nella coda di salvataggio a causa di un buco nella finestra di ricezione TCP.

RP/0/RSP0/CPU0:ASR9k-B#show tcp detail pcb 0x4a4400e4 ============================================================== Connection state is ESTAB, I/O status: 0, socket status: 0 Established at Sat Apr 20 18:26:26 2024 PCB 0x4a4400e4, SO 0x4a42c0ac, TCPCB 0x4a43b708, vrfid 0x60000000, Pak Prio: Normal, TOS: 64, TTL: 255, Hash index: 402 Local host: 10.10.10.229, Local port: 179 (Local App PID: 856311) Foreign host: 10.10.10.254, Foreign port: 46980 (Local App PID/instance/SPL_APP_ID: 856311/0/0) Current send queue size in bytes: 0 (max 16384) Current receive queue size in bytes: 0 (max 65535) mis-ordered: 0 bytes Current receive queue size in packets: 0 (max 60) Timer Starts Wakeups Next(msec) Retrans 2795 0 0 SendWnd 1341 0 0 TimeWait 0 0 0 AckHold 274 2 0 KeepAlive 333 1 299983 PmtuAger 0 0 0 GiveUp 0 0 0 Throttle 0 0 0 FirstSyn 0 0 0 iss: 2030796738 snduna: 2034498828 sndnxt: 2034498828 sndmax: 2034498828 sndwnd: 3291 sndcwnd: 4200 irs: 285455091 rcvnxt: 285455710 rcvwnd: 64917 rcvadv: 285520627 
SRTT: 162 ms, RTTO: 415 ms, RTV: 253 ms, KRTT: 0 ms
minRTT: 0 ms, maxRTT: 247 ms ACK hold time: 200 ms, Keepalive time: 300 sec, SYN waittime: 30 sec Giveup time: 0 ms, Retransmission retries: 0, Retransmit forever: FALSE Connect retries remaining: 0, connect retry interval: 0 secs <...> RP/0/RSP0/CPU0:ASR9k-B#

Monitoraggio dell'utilizzo della memoria

La tabella delle route BGP è archiviata nella memoria heap del processo BGP. La tabella di routing viene archiviata nella memoria heap del processo RIB.

Comandi utili per il monitoraggio della memoria heap:

  show memory summary

  show memory summary detail

  show memory-top-consumers

  show memory heap summary all

Percorso sensore di telemetria:

  Cisco-IOS-XR-nto-misc-oper:memory-summary/nodes/node/detail 

FIB memorizza le voci di inoltro nello spazio di memoria condivisa.

Comandi utili per il monitoraggio della memoria condivisa:

  show memory summary

  show memory summary detail

  show shmwin summary

Monitoraggio delle prestazioni dei processi BGP

Comando utile che fornisce dati interni sulle prestazioni del processo BGP:

  show bgp process performance-statistics 

  show bgp process performance-statistics detail 

Convergenza Monitor BGP

Un altro comando utile è quello che mostra lo stato generale della convergenza BGP: show bgp convergence

Quando la rete è stabile, si può vedere qualcosa come questo:

RP/0/RP0/CPU0:ASR9k-B#show bgp convergence Mon Dec 18 13:55:47.976 UTC Converged. All received routes in RIB, all neighbors updated. All neighbors have empty write queues. RP/0/RP0/CPU0:ASR9k-B#