Sommario

Introduzione

Selezione piattaforme hardware/software

Considerazioni Su Scalabilità E Prestazioni

Numero di peer BGP

Famiglie di indirizzi

Numero di gruppi di aggiornamento

Complessità delle RPL (Route Policies)

Frequenza Di Aggiornamento

TCP MSS e MTU interfaccia/percorso

NSR su router Dual-RP

Peer lenti

Ritardo trigger Nexthop

Esempio di scala BGP RR multidimensionale convalidata

Considerazioni sulla progettazione

Monitoraggio degli indicatori di prestazioni chiave (KPI) BGP

Monitor Datapath Forwarder

Monitorare l'agente DPA XRv9000

Monitor ASR9000NP (Network Processor)

Monitoraggio LPTS

SPP monitor

Monitorare NetIO

Monitoraggio delle code XIPC

Monitoraggio delle code di input e output BGP

Monitoraggio delle velocità dei messaggi BGP

Monitoraggio utilizzo CPU

Monitoraggio delle statistiche TCP

Monitoraggio dell'utilizzo della memoria

Monitoraggio delle prestazioni dei processi BGP

Convergenza Monitor BGP

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) è un fattore importante nelle considerazioni sulle prestazioni BGP perché nelle distribuzioni 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 ilshow bgp update-groupcomando. È 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-peerin 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

VPNv4 eBGP: 2500

VPNv4 iBGP: 1700

VPNv4 iBGP: 2000

Route BGP

Per sessione: 200

Totale: 400 k

Percorsi per route: 1

Per sessione: 750

VPNv4: 1,36 M

VPNv6: 150 k

IPv4: 950 k

IPv6: 200 k

Totale: ~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 pkt/s

- Uscita: 31 pacchetti/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 pkt/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

Nota: I contatori di stato LPTS possono essere cancellati. Il sistema di monitoraggio deve tenere conto di questa possibilità.

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 punted/injected ed è di facile lettura e comprensione. Per le sessioni BGP, i contatori rilevanti si trovano sotto client/punt  e client/inject  sul RP attivo.

Il show spp client  router è più ricco di output e offre una visione più dettagliata del numero di pacchetti accodati/scartati verso i client, oltre al 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

show xipcq jid

queue-id

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

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, ad esempio  show bgp neighbor

detail

e  show bgp neighbor

performance-statistics

o,  show bgp recent-prefixes  per cercare di capire quali prefissi stanno lampeggiando e se sono sempre gli stessi o diversi.

Nota: I contatori MsgRcvd e MsgSent sono per router adiacente ma non per famiglia di indirizzi. Quando si esegue un comando come  show bgp all all summary , nelle sezioni relative alle varie famiglie di indirizzi vengono visualizzati gli stessi contatori per ogni router adiacente. Non rappresentano il numero di messaggi ricevuti/inviati da/a quel vicino per quella famiglia di indirizzi ma tra più famiglie di indirizzi.

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  show tcp brief  CLI 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: 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

- Recv-Q: dimensione istantanea 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.

- State: 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 delshow tcp detail pcbcomando sono:

- Inizio timer ritrasmissione: indica quante volte è stato avviato il timer di ritrasmissione.

- Riattivazione timer di ritrasmissione: indica quante volte il timer di ritrasmissione si è esaurito, determinando la 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 correttamente: 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#