Perché otteniamo un'elevata fluttuazione sul grafico dei cactus per la misurazione della larghezza di banda?

Eravamo in test di ridondanza di Etherchannel e Routing sulla nostra rete. Durante questo intervento abbiamo effettuato alcune misurazioni. Il nostro strumento di monitoraggio è Cactus per il grafico. L'apparecchiatura monitorata è un 4500-X su VSS. Ogni collegamento si trova su un telaio fisico diverso.

Schema:

Cronologia del test:
[t0] Il collegamento sulla porta te1 / 1/14 è stato rimosso fisicamente. Te2 / 1/14 è attivo. Po1 è operativo.
[t0 + 15] Il collegamento sulla porta Te1 / 1/14 è tornato in servizio e ha verificato che la porta di ritorno nell'etere Po1
[t0 + 20] Il collegamento sulla porta te1 / 1/14 sia stata rimossa fisicamente. Te2 / 1/14 è attivo. Po1 è operativo.
[t0 + 35] Il collegamento sulla porta Te1 / 1/14 è tornato in servizio e ha verificato che la porta sia ritornata nell'etere Po1

Nei nostri test, abbiamo monitorato il canale di traffico Po1 attraverso i cactus (grafico sotto) e abbiamo notato un cambiamento significativo nel valore del flusso quando abbiamo disabilitato il collegamento te1 / 1/14 (collegamento risorse te2 / 1/14) piuttosto stabile durante il contrario . Abbiamo controllato anche i contatori su Int Po1 e questi sono stati mantenuti abbastanza stabili.

Due interfacce di 10G sono raggruppate su Etherchannel con LACP configurato. All'interno del canale eterico ci sono 2 valli. Uno per il traffico multicast e un altro per Internet / Tutto il traffico.

Conosci una possibile causa di questo comportamento?

Per estendere il commento di ytti.

Il tuo intervallo di sondaggio sembra davvero ridotto, ogni 10 secondi se sto leggendo bene. Ci sono alcuni motivi per cui potresti ottenere quel risultato.

Lato attrezzatura:

• Scelta errata dei contatori, se si utilizzano contatori a 32 bit, potrebbero scorrere ogni ~ 3,4 secondi se si esegue un'interfaccia da 10 g alla frequenza di linea
• Aggiornamento contatore, molti dispositivi più grandi aggiornano i contatori solo due o tre volte al minuto e non possono mai essere considerati affidabili. Ogni 30 secondi è basso quanto mi preoccuperei del polling e anche allora vorrei sempre almeno due punti prima di attivare qualsiasi avviso o agire
• Può esserci un gotcha poiché i pacchetti inviati per l'elaborazione della CPU (forse netflow) possono essere contati immediatamente rispetto a quelli che non stanno andando a RE in batch (l'ho visto su Juniper MX)

Lato Poller:

• Il poller sta eseguendo il polling con precisione all'intervallo e, in caso contrario, sta iniettando il suo risultato con il tempo di polling effettivo (ad es. X bit in yz secondi) in modo da poter calcolare una frequenza ragionevole
• Cosa succede quando si ripristinano i contatori o quando i GET SNMP non ricevono risposta, strumenti diversi rispondono a questi in modi diversi

Il tuo problema è che il campionamento del tuo router e il tuo polling non stanno colpendo nello stesso momento. Cioè, anche se l'intervallo di polling è statico, gli intervalli di polling contengono diverse quantità di campioni, che la tua matematica non tiene in considerazione.
Considera di aver eseguito il polling di t1, t2, t3 ma il router non ha campionato nulla all'intervallo t1, t2, quindi tutto il traffico tra t1, t3 è finito a t2, valore di polling t3. Causando che la tua frequenza sia 0 a t1, t2 e oltre linerato a t2, t3

Ora suggerirò una soluzione, ma per favore verificalo con qualcuno che abbia una comprensione superficiale della matematica.

Prima capire l'interfaccia che ti interessa (se ge-1/1/1):

snmpbulkwalk INTERRUTTORE ifDescr | grep ge-1/1/1

Quindi vedrai il suo numero ifIndex, supponiamo che sia '42'.

Quindi fai qualcosa del tipo:

while true; do
  snmpbulkwalk SWITCH ifHCInOctets.42 >> DATA
  date >> DATA
  sleep 1
done

Ora analizza i risultati per determinare con quale frequenza in media i contatori vengono effettivamente aggiornati. (Posso produrre script per l'analisi se necessario)

Poi arriva la parte in cui avremmo bisogno della matematica, ma suggerirò una soluzione ingenua.

Se l'intervallo di aggiornamento è 10 s, casella di polling ogni 5 s, ovvero due volte più spesso rispetto all'aggiornamento. Quindi i tuoi campioni sarebbero

t0, t5, t10, t15, t20, t25, t30

Ora questi sarebbero i tuoi dati grezzi, che non utilizzeresti, ma preferiresti recuperare campioni reali da questi in questo modo

s1 = (t0+t5+t10)/3
s2 = (t10+t15+t20)/3
s3 = (t20+t25+t30)/3

La logica qui è che vogliamo trapelare oltre i confini per ridurre l'effetto di intervalli di polling imprecisi sul tuo switch.

Quindi tracciare s1, s2, s3 e dovresti avere risultati molto più fluidi / precisi di quello che stai vedendo ora.

Tuttavia, sono sicuro che questo non è un problema nuovo e sono sicuro che esiste una soluzione formale su come recuperare una precisione ottimale, purtroppo producendo quella soluzione non rientra nelle mie competenze. Qualcosa di matematico. Scambiare le persone sarebbe meglio attrezzato per affrontare.

Dato che stai eseguendo il polling alla stessa velocità con cui i contatori vengono aggiornati, probabilmente non sei sincronizzato.

Con la configurazione

snmp-server hc poll <<hundredths of a second>>

puoi ridurre l'intervallo in cui i contatori SNMP vengono aggiornati a qualcosa come 1 secondo. Ciò dovrebbe comportare un valore più accurato per la velocità effettiva quando si esegue il polling ogni 10 secondi.

Cordiali saluti, questo è un comando nascosto.