PDF(297.5 KB) Visualizza con Adobe Reader su diversi dispositivi
ePub(95.2 KB) Visualizza in diverse app su iPhone, iPad, Android, Sony Reader o Windows Phone
Mobi (Kindle)(94.1 KB) Visualizza su dispositivo Kindle o tramite app Kindle su più dispositivi
Aggiornato:6 agosto 2025
ID documento:224027
Linguaggio senza pregiudizi
La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Informazioni su questa traduzione
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
In questo documento viene descritto come risolvere i problemi di prestazioni dei router aziendali C8000v in cloud pubblici e scenari ESXi.
Componenti usati
Le informazioni di questo documento si basano sui seguenti componenti hardware e software:
C800v con versione 17.12
ESXI versione 7.0 U3
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.
Risoluzione dei problemi generali
Sebbene sia possibile ospitare il server C8000v in ambienti diversi, è comunque possibile eseguire alcune operazioni di risoluzione dei problemi identiche indipendentemente dalla posizione in cui è ospitato il server C8000v. Iniziamo con le nozioni di base. La prima cosa da verificare è se il dispositivo sta raggiungendo o meno i limiti di capacità. A tale scopo, è possibile iniziare verificando i seguenti due output:
1. show platform hardware qfp active datapath summary - Questo comando fornisce le informazioni complete sugli input/output che il C8000v sta ricevendo e trasmettendo da ogni porta. È necessario focalizzare l'attenzione sulla percentuale di carico di elaborazione. In uno scenario in cui si raggiunge il 100%, significa che si sta raggiungendo il limite di capacità
------------------ show platform hardware qfp active datapath utilization summary ------------------
CPP 0: 5 secs 1 min 5 min 60 min
Input: Total (pps) 93119 92938 65941 65131
(bps) 997875976 1000204000 708234904 699462016
Output: Total (pps) 93119 92949 65944 65131
(bps) 1052264704 1054733128 746744264 737395744
Processing: Load (pct) 14 14 10 10
2. show platform hardware qfp active datapath infrastructure sw-cio - Considerare questo comando come una versione più dettagliata di quella precedente. Fornisce maggiori dettagli sui singoli core, compresi i core I/O e i core di crittografia che non fanno parte del numero di utilizzo QFP. È molto utile in uno scenario in cui si desidera verificare se un core del piano dati specifico causa un collo di bottiglia.
Suggerimento: Quando si utilizza questo comando, è consigliabile eseguirlo sempre due volte. Calcola la percentuale di utilizzo dei core tra l'ora di esecuzione del comando.
Ora, avete determinato se state raggiungendo o meno il limite della piattaforma. Il passo successivo sarebbe controllare se ci sono cadute. Questi sono intrinsecamente connessi a problemi di prestazioni. Esistono tre tipi di gocce che è possibile prendere in considerazione a seconda della posizione in cui si verificano.
Sovraccarichi: Questo tipo di perdita di pacchetto si verifica sull'estremità Rx. Si verificano perché è stata superata la capacità di elaborazione di uno o più core.
Perdite di funzionalità: Questo tipo di perdita di pacchetti si verifica nel DPI. Sono correlate a funzionalità del router, ad esempio un ACL o una QoS.
Condutture: Questo tipo di perdita di pacchetti si verifica nell'estremità Tx. Sono causate dalla congestione dei buffer Tx.
Per identificare le cadute che si verificano, è possibile utilizzare i seguenti output:
mostra stato di rilascio attivo qfp hardware della piattaforma deselezionato
show interface
mostra interfaccia mappa criteri
Verificate come identificare le gocce che state affrontando e come mitigarle. Tuttavia, l'obiettivo principale di questo articolo saranno le gocce di carico note come "Taildrops", in quanto sono particolarmente difficili da risolvere nei router virtuali.
Sovraccarichi
Una perdita di sovraccarico in Cisco IOS XE si verifica quando l'interfaccia di rete riceve i pacchetti più rapidamente di quanto possa elaborarli o memorizzarli nel proprio buffer. In particolare, i buffer interni delle interfacce (coda FIFO) diventano pieni perché la velocità dei dati in ingresso supera la capacità dell'hardware di gestirli. Di conseguenza, i nuovi pacchetti in arrivo non possono essere archiviati e vengono scartati, incrementando così il contatore di sovraccarico. Si tratta essenzialmente di una perdita di pacchetti causata dal sovraccarico temporaneo dell'interfaccia.
Questo tipo di pacchetti vengono scartati sull'estremità Rx. Questo problema si verifica perché la capacità di elaborazione di uno o più core è stata superata e il thread Rx non è in grado di distribuire i pacchetti in arrivo al thread PP pertinente e i buffer in entrata sono già pieni. Per fare una semplice analogia, si può pensare a una coda a un banco di check-out che diventa troppo piena perché i pacchetti stanno arrivando più velocemente di quanto il cassiere (hardware di interfaccia) può servire loro. Quando la coda è piena, i nuovi clienti devono partire senza ricevere assistenza - queste sono le cadute di sovraccarico.
Anche se l'hardware è menzionato in questa sezione, il C8000v è un router basato su software. In questo caso, il superamento può essere causato da:
Elevato utilizzo del piano dati: Se l'utilizzo del piano dati è elevato, non è possibile eseguire il polling dei pacchetti abbastanza velocemente, con conseguenti sovraccarichi. Ad esempio, la presenza di "flussi di elefanti" (grandi flussi di dati continui) può saturare le risorse di elaborazione e causare sovraccarichi sulle interfacce.
Modello di dispositivo non corretto: L'utilizzo di un modello di dispositivo non appropriato può causare una gestione inefficiente del buffer e sovraccarichi. Per controllare questa condizione, usare il comando show platform software cpu alloc e modificarla con il comando platform resource<template>.
A ogni interfaccia viene assegnato un pool limitato di crediti. Questo meccanismo impedisce che un'interfaccia occupata sovraccarichi le risorse di sistema. Ogni volta che un nuovo pacchetto arriva nel piano dati, è necessario un credito. Al termine dell'elaborazione del pacchetto, il credito viene restituito in modo che il thread Rx possa utilizzarlo di nuovo. Se non è disponibile alcun credito per l'interfaccia che il pacchetto deve attendere nell'anello Rx dell'interfaccia. In genere, ci si aspetta che le perdite relative al limite delle prestazioni siano sovraccaricate da Rx perché è stata superata la capacità di elaborazione di uno o più core.
Per identificare i sovraccarichi, è in genere necessario controllare le statistiche dell'interfaccia per individuare eventuali errori di input, in particolare il contatore di sovraccarico:
Utilizzare il comando show platform hardware qfp active datapath infrastructure sw-cio per identificare l'utilizzo principale e se è stato superato il numero di crediti per un'interfaccia specifica.
Usare il comando show interface <nome-interfaccia>e cercare il conteggio dei sovraccarichi nell'output.
I sovraccarichi vengono visualizzati come parte degli errori di input, ad esempio:
Gig2 is up, line protocol is up 241302424557 packets input, 168997587698686 bytes, 0 no buffer 20150 input errors, 0 CRC, 0 frame, 20150 overrun, 0 ignored <<<<<<<<<<<
Supponiamo che Gig2 stia osservando problemi di prestazioni causati da sovraccarichi. Per determinare il thread di lavoro associato all'interfaccia, è possibile utilizzare il comando seguente:
#show platform hardware qfp active datapath infra binding Port Instance Bindings:
ID Port IOS Port WRKR 2 1 rcl0 rcl0 Rx+Tx 2 ipc ipc Rx+Tx 3 vxe_punti vxe_puntif Rx+Tx 4 Gi1 GigabitEthernet1 Rx+Tx 5 Gi2 GigabitEthernet2 Rx+Tx <<< in this case, WRKR2 is the thread responsible for both Rx and Tx
Quindi, è possibile analizzare l'utilizzo del thread specifico responsabile per il traffico Rx di questa interfaccia e il relativo numero di crediti.
In uno scenario in cui Gig2 osserva problemi di prestazioni dovuti a sovraccarichi, è possibile prevedere che PP#2 sia costantemente utilizzato (inattivo = 0%) e crediti minimi/nulli per l'interfaccia Gig2:
#show platform hardware qfp active datapath infrastructure sw-cio Credits Usage:
Core Utilization over preceding 1.0047 seconds ---------------------------------------------- ID: 0 1 2 % PP: 0.77 0.00 0.00 % RX: 0.00 0.00 0.44 % TM: 0.00 0.00 5.63 % IDLE: 99.23 99.72 93.93 <<< the core ID relevant in this case would be PP#2
Rilasci funzionalità
I pacchetti vengono gestiti da qualsiasi thread del piano dati disponibile e vengono distribuiti esclusivamente in base alla disponibilità dei core QFP tramite la funzione Rx del software (x86) - Load Based Distribution (LBD). I pacchetti che arrivano nel DPI possono essere scartati con uno specifico motivo di rilascio QFP, che può essere controllato utilizzando questo output:
#show drops
------------------ show platform hardware qfp active statistics drop detail ------------------
Last clearing of QFP drops statistics : never
--------------------------------------------------------------------------------
ID Global Drop Stats Packets Octets
--------------------------------------------------------------------------------
319 BFDoffload 403 31434
139 Disabled 105 7487
61 Icmp 135 5994
94 Ipv4NoAdj 1 193
33 Ipv6NoRoute 2426 135856
215 UnconfiguredIpv4Fia 1937573 353562196
216 UnconfiguredIpv6Fia 8046173 1057866418
------------------ show platform hardware qfp active interface all statistics drop_summary ------------------
----------------------------------------------------------------
Drop Stats Summary:
note: 1) these drop stats are only updated when PAL
reads the interface stats.
2) the interface stats include the subinterface
Interface Rx Pkts Tx Pkts
---------------------------------------------------------------------------
GigabitEthernet1 9980371 0
GigabitEthernet2 4012 0
Le ragioni per le gocce sono diverse e di solito sono auto-esplicative. Per ulteriori informazioni, è possibile utilizzare una traccia del pacchetto.
Gocce
Come accennato in precedenza, quando il dispositivo tenta di trasmettere pacchetti si verificano perdite di dati, ma i buffer di trasmissione sono pieni.
In questa sezione vi presenteremo i risultati che potrete ottenere quando affronterete questo tipo di situazione. Quali valori si possono vedere nel loro significato e cosa si può fare per mitigare il problema.
Innanzitutto, devi sapere come identificarli. Uno di questi metodi è semplicemente guardare l'interfaccia dello show. Tieni d'occhio le cadute in aumento:
GigabitEthernet2 is up, line protocol is up Hardware is vNIC, address is 0050.56ad.c777 (bia 0050.56ad.c777) Description: Connected-To-ASR Cloud Gateway Internet address is 10.6.255.81/29 MTU 1500 bytes, BW 10000000 Kbit/sec, DLY 10 usec, reliability 255/255, txload 2/255, rxload 3/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full Duplex, 10000Mbps, link type is force-up, media type is Virtual output flow-control is unsupported, input flow-control is unsupported ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 03:16:21 Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 7982350 <<<<<<<< Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 150449000 bits/sec, 20461 packets/sec 5 minute output rate 89116000 bits/sec, 18976 packets/sec
Questo comando è particolarmente utile per capire se si verifica o meno una congestione:
show platform hardware qfp active datapath infrastructure - HQF sta per 'Hierarchical Queueing Framework'. Questa funzionalità consente la gestione QoS (Quality of Service) a diversi livelli (fisico, logico e di classe) tramite l'interfaccia della riga di comando (MQC) QoS modulare. Mostra i costi correnti di RX e TX. Quando la coda TX è piena, come mostra l'output (full 1959)
L'output suggerisce che l'hardware sottostante non sta tenendo il passo con l'invio dei pacchetti. Per eseguire il debug dell'interfaccia sottostante, è necessario esaminare l'ambiente esterno a C8000v e l'ambiente sottostante su cui è in esecuzione C8000v per verificare se sono stati segnalati errori aggiuntivi sulle interfacce fisiche sottostanti.
Per controllare l'ambiente, è possibile eseguire una sola operazione prima di controllare in quale hypervisor è in esecuzione il router C800v. In questo modo, è possibile controllare l'output del comando show controller. Tuttavia, ci si può trovare persi su cosa ogni contatore significa o dove guardare.
In primo luogo, un dettaglio importante da tenere presente quando si osserva questo output è che le informazioni provengono principalmente dalle vNIC stesse. Ogni driver di scheda NIC dispone di un set specifico di contatori che utilizzano, che possono variare in base al driver. Hypervisor diversi hanno una sorta di effetto anche su ciò che viene presentato. Alcuni contatori, ad esempio i contatori mbuf, sono statistiche del driver DPDK. Queste impostazioni possono variare a seconda dei driver DPDK. Il conteggio effettivo viene in genere eseguito dall'hypervisor a livello di virtualizzazione.
Per informazioni su come interpretare e leggere questi contatori, utilizzare la pagina seguente:
Se viene visualizzato subX, significa che si tratta di una sottointerfaccia, ovvero una divisione logica dell'interfaccia principale. Il valore sub0 è in genere quello principale/predefinito. Queste VLAN vengono spesso usate quando sono coinvolte più VLAN.
Quindi, avete "rx = ricevente" e "tx = trasmittente".
q0 fa infine riferimento alla prima coda predefinita utilizzata dall'interfaccia
Sebbene non esista una descrizione per ogni contatore, nell'articolo ne vengono descritti alcuni, che possono essere rilevanti per la risoluzione dei problemi:
"RX_MISSED_ERRORS:" viene visualizzato quando il buffer della scheda NIC (Rx FIFO) è pieno. Questa condizione determina una riduzione e un aumento della latenza. Una possibile soluzione a questo problema consiste nell'aumentare il buffer della scheda NIC (che nel nostro caso è impossibile) o nel modificare il driver della scheda NIC.
"tx_q0_drop_total" e "tx_q0_tx_ring_full": Questi elementi possono indicare che l'host sta scartando i pacchetti e che il C8000v sta subendo un calo della coda nel C8000v perché l'host sta eseguendo una contropressione nel C8000v
Nell'output precedente, non viene visualizzato alcun "rx_missing_errors". Tuttavia, mentre ci concentriamo sulle code, vediamo sia "tx_q0_drop_total" che "tx_q0_tx_ring_full". In questo modo, si può concludere che esiste effettivamente una congestione causata dall'hardware sottostante dell'host.
Come accennato in precedenza, ogni hypervisor ha una sorta di effetto su ciò che viene presentato. L'articolo affronta questo argomento nella sezione successiva, analizzando le differenze tra i diversi hypervisor in cui può essere ospitato il C8000v. È inoltre possibile trovare i diversi consigli per cercare di mitigare questo tipo di problema in ciascuno di essi.
Hypervisor
Un hypervisor è un livello software che consente l'esecuzione di più sistemi operativi (denominati macchine virtuali o VM) su un singolo host hardware fisico tramite la gestione e l'allocazione di risorse hardware quali CPU, memoria e storage a ciascuna VM. Garantisce che queste macchine virtuali funzionino in modo indipendente senza interferire tra loro.
Nel contesto di Cisco Catalyst 8000V (C8000v), l'hypervisor è la piattaforma che ospita la macchina virtuale C8000v. Come è possibile individuare l'hypervisor che ospita il server C800v? C'è un output piuttosto utile che ci dà quell'informazione. È inoltre possibile verificare il tipo di risorse a cui il router virtuale ha accesso:
C8000v#show platform software system all Processor Details ================= Number of Processors : 8 Processor : 1 - 8 vendor_id : GenuineIntel cpu MHz : 2593.906 cache size : 36608 KB Crypto Supported : Yes model name : Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz
VNIC Details ============ Name Mac Address Driver Name Status Platform MTU GigabitEthernet1 0022.480d.7a05 net_netvsc UP 1500 GigabitEthernet2 6045.bd69.83a0 net_netvsc UP 1500 GigabitEthernet3 6045.bd69.8042 net_netvsc UP 1500
Hypervisor Details =================== Hypervisor: AZURE Manufacturer: Microsoft Corporation Product Name: Virtual Machine Serial Number: 0000-0002-0201-5310-5478-4052-71 UUID: 8b06091c-f1d3-974c-85a5-a78dfb551bf2 Image Variant: None
VMWare ESXi
ESXi è un hypervisor di tipo 1 sviluppato da VMware e installato direttamente sui server fisici per consentire la virtualizzazione. Consente l'esecuzione di più macchine virtuali (VM) su un singolo server fisico, astragendo le risorse hardware e allocandole a ciascuna VM. Il router C8000v è una di queste VM.
È possibile iniziare passando in rassegna uno scenario comune in cui si verifica una congestione. Ciò può essere confermato controllando il contatore tx_q0_tx_ring_full:
Esempio:
------------------ show platform software vnic-if interface-mapping ------------------
------------------------------------------------------------- Interface Name Driver Name Mac Addr ------------------------------------------------------------- GigabitEthernet3 net_vmxnet3 <-- 0050.5606.2239 GigabitEthernet2 net_vmxnet3 0050.5606.2238 GigabitEthernet1 net_vmxnet3 0050.5606.2237 -------------------------------------------------------------
Questa congestione si verifica quando il C8000V tenta di inviare pacchetti tramite l'interfaccia VMXNET3. Tuttavia, l'anello del buffer è già pieno di pacchetti, che finiscono per essere ritardati o scartati.
In queste condizioni, queste gocce si stanno verificando sul lato dell'hypervisor, come accennato in precedenza. Se tutte le raccomandazioni sono state soddisfatte, si consiglia di consultare il supporto VMware per comprendere cosa sta succedendo sulla scheda NIC.
Ecco alcuni suggerimenti su come migliorare le prestazioni:
Utilizzo di uno switch vSwitch e di un uplink dedicati per prestazioni ottimali
Assegnando il C8000V a uno switch vSwitch dedicato supportato da un uplink fisico, è possibile isolare il traffico proveniente dai vicini più rumorosi ed evitare i colli di bottiglia delle risorse condivise.
Vi sono alcuni comandi che meritano di essere esaminati dal lato ESXi. Ad esempio, per verificare la perdita di pacchetti dall'interfaccia ESXi, è possibile effettuare le seguenti operazioni:
Abilitare SSH.
Collegarsi a ESXi utilizzando SSH.
Eseguire esxtop.
Digitare n.
Il comando esxtop può visualizzare i pacchetti ignorati nel commutatore virtuale se il driver di rete del computer virtuale ha esaurito la memoria buffer Rx. Anche se exxtop mostra i pacchetti come scartati allo switch virtuale, in realtà vengono scartati tra lo switch virtuale e il driver del sistema operativo guest.
Cercare i pacchetti ignorati in %DRPTX e %DRPRX:
12:34:43pm up 73 days 16:05, 907 worlds, 9 VMs, 53 vCPUs; CPU load average: 0.42, 0.42, 0.42
Con questo comando vengono elencate tutte le schede NIC configurate su un host:
esxcli network nic list Name PCI Device Driver Admin Status Link Status Speed Duplex MAC Address MTU Description ------ ------------ ------ ------------ ----------- ----- ------ ----------------- ---- ----------- vmnic0 0000:01:00.0 igbn Up Up 1000 Full fc:99:47:49:c5:0a 1500 Intel(R) I350 Gigabit Network Connection vmnic1 0000:01:00.1 igbn Up Up 1000 Full fc:99:47:49:c5:0b 1500 Intel(R) I350 Gigabit Network Connection vmnic2 0000:03:00.0 ixgben Up Up 1000 Full a0:36:9f:1c:1f:cc 1500 Intel(R) Ethernet Controller 10 Gigabit X540-AT2 vmnic3 0000:03:00.1 ixgben Up Up 1000 Full a0:36:9f:1c:1f:ce 1500 Intel(R) Ethernet Controller 10 Gigabit X540-AT2
È inoltre disponibile un comando utile per controllare lo stato della vNIC assegnata a una VM specifica.
Se si esamina la VM c8kv-gw-mgmt, che è una VM C8000v, vengono assegnate 2 reti:
da c8kv a 9200l
da c8kv a cisco
È possibile utilizzare l'ID mondiale per cercare ulteriori informazioni su questa VM:
[root@localhost:~] esxcli network vm port list -w 2101719 Port ID: 67108890 vSwitch: vSwitch-to-9200L Portgroup: c8kv-to-9200l DVPort ID: MAC Address: 00:0c:29:31:a6:b6 IP Address: 0.0.0.0 Team Uplink: vmnic1 Uplink Port ID: 2214592519 Active Filters:
Port ID: 100663323 vSwitch: vSwitch-to-Cisco Portgroup: c8kv-to-cisco DVPort ID: MAC Address: 00:0c:29:31:a6:ac IP Address: 0.0.0.0 Team Uplink: vmnic0 <---- Uplink Port ID: 2248146954 Active Filters: [root@localhost:~]
Dopo aver ottenuto queste informazioni, è possibile identificare la rete a cui è assegnato lo switch vSwitch.
Per controllare alcune statistiche del traffico della scheda NIC fisica assegnata allo switch vSwitch, si dispone di questo comando:
# esxcli network nic stats get -n <vmnic>
Con questo comando vengono visualizzate informazioni quali pacchetti ricevuti, byte ricevuti, pacchetti ignorati e errori ricevuti. In questo modo è possibile identificare eventuali cadute nella scheda NIC.
Esistono alcune configurazioni da verificare che possono migliorare le prestazioni di Cisco Catalyst 8000V in esecuzione su un ambiente ESXi modificando le impostazioni sull'host e sul computer virtuale:
Impostare l'hardware virtuale: Impostazione di prenotazione CPU su Massimo.
Riservare tutta la memoria guest nell'hardware virtuale: Memoria.
Selezionare VMware Paravirtual da Hardware virtuale: Controller SCSI.
Dall'hardware virtuale: Scheda di rete: Tipo scheda, selezionare SR-IOV per le schede NIC supportate
Impostare l'opzione General Guest OS Version > VM Options (Versione generale del sistema operativo guest > Opzioni VM) su Other 3.x or later Linux (64 bit) (Altro Linux 3.x o versioni successive).
Impostare l'opzione Opzioni VM in Sensibilità latenza avanzata su Alta.
In Opzioni VM > Advanced Edit Configuration, aggiungere "numa.nodeAffinity" allo stesso nodo NUMA della scheda NIC SRIOV
Abilitare le impostazioni relative alle prestazioni dell'hypervisor.
Limitare il sovraccarico di vSwitch abilitando SR-IOV sulle schede di interfaccia di rete fisiche supportate.
Configurare le vCPU della VM in modo che vengano eseguite sullo stesso nodo NUMA delle schede di interfaccia di rete fisiche.
Impostare la sensibilità della latenza della VM su Alta.
AWS
Il C8000v supporta l'installazione su AWS lanciando come Amazon Machine Image (AMI) all'interno di Amazon Virtual Private Cloud (VPC), consentendo agli utenti di effettuare il provisioning di una sezione del cloud AWS logicamente isolata per le proprie risorse di rete.
Code Multi-TX
In un C800v in esecuzione su AWS, una caratteristica chiave è l'uso di code Multi-TX (Multi-TXQ). Queste code consentono di ridurre il sovraccarico di elaborazione interno e di migliorare la scalabilità. La presenza di più code rende più rapida e semplice l'assegnazione dei pacchetti in entrata e in uscita alla CPU virtuale (vCPU) corretta.
A differenza di alcuni sistemi in cui le code RX/TX sono assegnate per vCPU, nel C8000v queste code sono assegnate per interfaccia. Le code RX (ricezione) e TX (trasmissione) fungono da punti di connessione tra l'applicazione Catalyst 8000V e l'infrastruttura o l'hardware AWS, gestendo le modalità di invio e ricezione del traffico di rete. AWS controlla il numero e la velocità delle code RX/TX disponibili per ciascuna interfaccia, a seconda del tipo di istanza.
Per creare più code TX, Catalyst 8000V deve avere più interfacce. Quando sono abilitate più code TX, il dispositivo mantiene l'ordine dei flussi di pacchetti utilizzando un metodo di hashing basato sulla 5-tupla del flusso (IP di origine, IP di destinazione, porta di origine, porta di destinazione e protocollo). Questo hashing decide quale coda TX utilizzare per ogni flusso.
Gli utenti possono creare più interfacce su Catalyst 8000V utilizzando la stessa scheda di interfaccia di rete fisica (NIC) collegata all'istanza AWS. A tale scopo, è possibile configurare le interfacce di loopback o aggiungere indirizzi IP secondari.
Con i Multi-TXQ, esistono più code di trasmissione per gestire il traffico in uscita. Nell'esempio sono presenti dodici code TX (numerate da 0 a 11). Questa impostazione consente di monitorare singolarmente ogni coda per verificare se si sta esaurendo.
Guardando l'output, si può vedere che TX Queue 8 ha un contatore "full" molto alto (56.406.998), il che significa che il suo buffer si sta riempiendo frequentemente. Le altre code TX mostrano zero per il contatore "full", a indicare che non sono congestionate.
Router#show platform hardware qfp active datapath infrastructure sw-cio pmd b17a2f00 device Gi2 RX: pkts 9525 bytes 1229599 return 0 badlen 0 Out-of-credits: Hi 0 Lo 0 pkts/burst 1 cycl/pkt 560 ext_cycl/pkt 360 Total ring read 117322273, empty 117312792 TX: pkts 175116324 bytes 246208197526 pri-0: pkts 157 bytes 10238 pkts/send 1 pri-1: pkts 75 bytes 4117 pkts/send 1 pri-2: pkts 91 bytes 6955 pkts/send 1 pri-3: pkts 95 bytes 8021 pkts/send 1 pri-4: pkts 54 bytes 2902 pkts/send 1 pri-5: pkts 75 bytes 4082 pkts/send 1 pri-6: pkts 104 bytes 8571 pkts/send 1 pri-7: pkts 74 bytes 4341 pkts/send 1 pri-8: pkts 175115328 bytes 246208130411 pkts/send 2 pri-9: pkts 85 bytes 7649 pkts/send 1 pri-10: pkts 106 bytes 5784 pkts/send 1 pri-11: pkts 82 bytes 7267 pkts/send 1 Total: pkts/send 2 cycl/pkt 203 send 68548581 sendnow 175024880 forced 1039215617 poll 1155226129 thd_poll 0 blocked 2300918060 retries 68534370 mbuf alloc err 0 TX Queue 0: full 0 current index 0 hiwater 0 TX Queue 1: full 0 current index 0 hiwater 0 TX Queue 2: full 0 current index 0 hiwater 0 TX Queue 3: full 0 current index 0 hiwater 0 TX Queue 4: full 0 current index 0 hiwater 0 TX Queue 5: full 0 current index 0 hiwater 0 TX Queue 6: full 0 current index 0 hiwater 0 TX Queue 7: full 0 current index 0 hiwater 0 TX Queue 8: full 56406998 current index 224 hiwater 224 <<<<<<<<<< TX Queue 9: full 0 current index 0 hiwater 0 TX Queue 10: full 0 current index 0 hiwater 0 TX Queue 11: full 0 current index 0 hiwater 0
Il monitoraggio dei contatori "completi" delle code TX consente di identificare se una coda di trasmissione è sovraccarica. Un conteggio "completo" in costante aumento su una particolare coda TX indica un flusso di traffico che sta causando lo stress del dispositivo. Per risolvere questo problema, è possibile eseguire il bilanciamento del traffico, l'adeguamento delle configurazioni o la scalabilità delle risorse per migliorare le prestazioni.
Metriche superate
AWS imposta alcuni limiti di rete a livello di istanza per garantire prestazioni di rete coerenti e di alta qualità su diverse dimensioni di istanza. Questi limiti consentono di mantenere una rete stabile per tutti gli utenti.
È possibile controllare questi limiti e le statistiche correlate utilizzando il comando show controller sul dispositivo. L'output include molti contatori, ma qui ci concentriamo solo su quelli più importanti per il monitoraggio delle prestazioni della rete:
A questo punto è possibile eseguire un'immersione e vedere a cosa si riferiscono esattamente questi contatori:
bw_in_ALLOW_exceeded: Numero di pacchetti in coda o scartati perché la larghezza di banda in ingresso ha superato il limite dell'istanza.
bw_out_ALLOW_exceeded: Numero di pacchetti in coda o scartati perché la larghezza di banda in uscita ha superato il limite dell'istanza.
pps_ALLOW_exceeded: Numero di pacchetti in coda o scartati perché il numero totale di pacchetti al secondo (PPS) ha superato il limite dell'istanza.
conntrack_alloweded_exceeded: Numero di connessioni rilevate che hanno raggiunto il numero massimo consentito per il tipo di istanza.
linklocal_ALLOW_exceeded: Numero di pacchetti ignorati perché il traffico verso i servizi proxy locali (come Amazon DNS, Instance Metadata Service e Time Sync Service) ha superato il limite PPS per l'interfaccia di rete. Ciò non influisce sui resolver DNS personalizzati.
Conseguenze per le prestazioni del server C8000v:
Se questi contatori aumentano e si verificano problemi di prestazioni, ciò non sempre indica che il router C8000v è il problema. Al contrario, indica spesso che l'istanza AWS in uso ha raggiunto i limiti di capacità. È possibile controllare le specifiche dell'istanza AWS per verificare che possa gestire le esigenze di traffico.
Microsoft Azure
In questa sezione viene illustrato come Microsoft Azure e il router virtuale Cisco C800v si combinano per offrire soluzioni di rete virtuale scalabili, sicure e ad alte prestazioni nel cloud.
Ecco come la funzionalità di rete accelerata (LAN, Accelerated Networking) e la frammentazione dei pacchetti possono influire sulle prestazioni. Oltre a esaminare l'importanza dell'utilizzo di un tipo di istanza supportato per Microsoft Azure.
Reti accelerate
Nei casi di problemi di prestazioni in cui C8000v è ospitato nel cloud di Microsoft Azure. Un aspetto che non è possibile ignorare è se la rete accelerata è abilitata o meno. Aumenta notevolmente le prestazioni del router. In poche parole, una rete accelerata consente la virtualizzazione dell'I/O con un'unica radice (SR-IOV) su VM come Cisco Catalyst 8000V. Il percorso di rete accelerato ignora lo switch virtuale, aumenta la velocità del traffico di rete, migliora le prestazioni di rete e riduce la latenza e l'instabilità della rete.
Esiste un modo molto semplice per verificare se la funzionalità Rete accelerata è abilitata. Ciò significa controllare l'output show controllers e verificare se un certo contatore è presente o meno:
------------------ show controllers ------------------
GigabitEthernet1 - Gi1 is mapped to UIO on VXE
rx_good_packets 6497723453
tx_good_packets 14690462024
rx_good_bytes 2271904425498
tx_good_bytes 6276731371987
rx_q0_good_packets 58576251
rx_q0_good_bytes 44254667162
vf_rx_good_packets 6439147188
vf_tx_good_packets 14690462024
vf_rx_good_bytes 2227649747816
vf_tx_good_bytes 6276731371987
I contatori che si stanno cercando sono quelli che iniziano con vf, ad esempio vf_rx_good_packets. Se si verifica la presenza di questi contatori, si è certi che la funzionalità di rete accelerata sia abilitata.
Azure e frammentazione
La frammentazione può avere implicazioni negative sulle prestazioni. Uno dei motivi principali che hanno influito sulle prestazioni è l'effetto della frammentazione e del riassemblaggio dei pacchetti sulla CPU o sulla memoria. Quando un dispositivo di rete deve frammentare un pacchetto, deve allocare le risorse CPU/memoria per eseguire la frammentazione.
La stessa cosa accade quando il pacchetto viene ricomposto. Il dispositivo di rete deve memorizzare tutti i frammenti finché non li riceve per poterli ricomporre nel pacchetto originale.
Azure non elabora i pacchetti frammentati con le reti accelerate. Quando una VM riceve un pacchetto frammentato, il percorso non accelerato lo elabora. Di conseguenza, i pacchetti frammentati non traggono vantaggio dalle funzionalità di rete accelerata, quali una latenza inferiore, un jitter ridotto e pacchetti più alti al secondo. Per questo motivo si raccomanda di evitare, se possibile, la frammentazione.
Per impostazione predefinita, Azure elimina i pacchetti frammentati che arrivano alla VM in modo non corretto, ovvero i pacchetti non corrispondono alla sequenza di trasmissione dall'endpoint di origine. Questo problema può verificarsi quando i pacchetti viaggiano su Internet o su altre WAN di grandi dimensioni.
Ciò è dovuto al fatto che i tipi di istanza presenti in tale elenco sono quelli in cui il C8KV è stato correttamente testato. A questo punto, è possibile stabilire se C8000v funziona su un tipo di istanza non elencato. La risposta è molto probabilmente sì. Tuttavia, quando si risolvono problemi complessi come quelli relativi alle prestazioni, non si desidera aggiungere un altro fattore sconosciuto al problema. Solo per questo motivo, Cisco TAC consiglia sempre di utilizzare un tipo di istanza supportato.
Ulteriori risorse
Un problema relativo alle prestazioni può essere effettivamente risolto solo quando si verifica in quel momento. Tuttavia, questo può essere difficile da scoprire come può accadere in ogni dato momento. Per questo motivo, forniamo questo script EEM. Aiuta a catturare output importanti nel momento in cui i pacchetti vengono scartati e i problemi di prestazioni ne derivano:
Feedback