Quali sono le cause dell'output totale su un'interfaccia switch Cisco?

Ho uno chassis blade HP c7000 che contiene switch Cisco 3120X e Cisco 3120G con iOS 12.2 (58) SE1. I blade stessi sono caricati in modo molto leggero, tuttavia molte interfacce su diversi switch di blade nello chassis mostrano un numero piuttosto elevato di cadute di uscita. Se controllo il numero di output diminuisce ripetutamente, non solo vedo aumentare il contatore, ma a volte diminuisce. I numeri non sono correlati ai pacchetti registrati sull'interfaccia. Le impostazioni QoS sono predefinite per la piattaforma.

I seguenti campioni sono stati tutti prelevati entro un periodo di 30 secondi:

bc1019-3120-stack> sh int gi2 / 0/7 | I cade l'output
  Coda di input: 0/75/0/0 (size / max / drops / flushes); Cadute totali di produzione: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | I cade l'output
  Coda di input: 0/75/0/0 (size / max / drops / flushes); Cadute totali di produzione: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | I cade l'output
  Coda di input: 0/75/0/0 (size / max / drops / flushes); Cadute totali di produzione: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | I cade l'output
  Coda di input: 0/75/0/0 (size / max / drops / flushes); Cadute totali di produzione: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | I cade l'output
  Coda di input: 0/75/0/0 (size / max / drops / flushes); Cadute totali di produzione: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | I cade l'output
  Coda di input: 0/75/0/0 (size / max / drops / flushes); Cadute totali di produzione: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | I cade l'output
  Coda di input: 0/75/0/0 (size / max / drops / flushes); Cadute totali in uscita: 451110
bc1019-3120-stack> sh int gi2 / 0/7 | I cade l'output
  Coda di input: 0/75/0/0 (size / max / drops / flushes); Cadute totali in uscita: 451110
bc1019-3120-stack> sh int gi2 / 0/7 | I cade l'output
  Coda di input: 0/75/0/0 (size / max / drops / flushes); Totale cadute in uscita: 902220
bc1019-3120-stack> sh int gi2 / 0/7 | I cade l'output
  Coda di input: 0/75/0/0 (size / max / drops / flushes); Totale cadute in uscita: 1353330
bc1019-3120-stack> sh int gi2 / 0/7 | I cade l'output
  Coda di input: 0/75/0/0 (size / max / drops / flushes); Cadute totali in uscita: 1804440
bc1019-3120-stack> sh int gi2 / 0/7 | I cade l'output
  Coda di input: 0/75/0/0 (size / max / drops / flushes); Cadute totali in uscita: 1804440
bc1019-3120-stack> sh int gi2 / 0/7 | I cade l'output
  Coda di input: 0/75/0/0 (size / max / drops / flushes); Cadute totali in uscita: 1804440
bc1019-3120-stack> sh int gi2 / 0/7 | I cade l'output
  Coda di input: 0/75/0/0 (size / max / drops / flushes); Cadute totali in uscita: 451490

bc1019-3120-stack> sh int gi2 / 0/7 | tasso di uscita
  Velocità di uscita 5 minuti 301000 bit / sec, 119 pacchetti / sec

1) C'è qualcos'altro che può causare cadute di output oltre al server nic che non riceve i frame abbastanza velocemente?

2) Qual è il numero massimo di cadute di output che il contatore di interfaccia può registrare? Rollover quando raggiunge il massimo?

3) Quale sarebbe considerato un tasso salutare di cali di produzione?

A meno che qualcuno non stia cancellando i contatori, non si dovrebbe mai vedere alcun contatore di tipo contachilometri (quelli che si incrementano in base all'azione di un pacchetto), dovrebbero sempre aumentare. Quella parte sembra un bug.

Per quanto riguarda in particolare le cause dell'output, ci sono così tante cause diverse che è molto difficile individuarlo esattamente. A volte c'è una congestione all'interno del backplane dello switch e questi potrebbero apparire quando l'output scende sull'interfaccia in uscita. In rare circostanze è anche possibile ottenere micro scoppi che non vengono visualizzati quando si esegue il polling a intervalli di 1 minuto che sovraccaricano rapidamente l'interfaccia, ma quindi ricadono rapidamente. Vorrei suggerire di afferrare l'OID SNMP per le cadute di output e quindi di rappresentarlo graficamente e vedere come corrisponde al contatore CLI.

In generale, non si desidera che vengano rilasciati output poiché indicano un pacchetto che non è arrivato a destinazione. Ma, se stai eseguendo i tuoi collegamenti caldi (che dici di non essere) sono inevitabili in una certa misura, principalmente a causa del buffering degli switch interni, ecc.

Il mio primo pensiero è l'inondazione unicast, soprattutto se i contatori aumentano all'unisono attraverso un numero di porte nello stesso vlan. Concordo con Aaron sul fatto che il decremento del contatore suona come un bug. Il contatore verrà probabilmente girato a 2 ^ 64, ma ciò non avverrà in pochi secondi. Vorrei considerare un tasso salutare di risultati in uscita pari a zero, ma ciò non è realistico, neppure nel datacenter. Stai facendo uplink 10G?

Sembra che tu stia colpendo il bug CSCtq86186. Questo errore è stato riscontrato su 3750, 2960, ma potrebbe interessare anche gli switch blade.

Se si verificano inondazioni unicast, l'esecuzione di WireShark su uno degli host o su una delle porte dovrebbe mostrarlo abbastanza rapidamente.

Sembra che tu abbia core ridondanti in una topologia quadrata? In tal caso, prova ad aggiungere questo comando alla tua interfaccia vlan:

arp timeout 300

Le tabelle CAM mantengono le voci per 5 minuti mentre le tabelle ARP vengono conservate per quattro ore (valori predefiniti). L'impostazione dell'ARP in modo che corrisponda alla CAM può eliminare l'inondazione unicast a spese di un leggero aumento della CPU. Catalyst 6500/6000 Switch Risoluzione dei problemi relativi alla tabella ARP o CAM

Le cadute di output sono piuttosto comuni su switch più piccoli con buffer di piccole dimensioni poiché qualsiasi burst esaurirà il buffer. Non ho molta familiarità con il 3120, quindi non posso parlare per le dimensioni del suo buffer, ma almeno questo è un motivo comune fino a quando non si ottengono riduzioni dell'output.

I motivi specifici sono il head of line blocking (HOLB), in cui più porte di origine inviano a una destinazione e quindi otteniamo la congestione. Un altro motivo comune è quando si passa da una velocità della porta più alta a una più bassa, ovvero da 10G a 1G o da 40G a 10G.

Ti consiglio di eseguire i controller di spettacolo controller ethernet X dove X è la tua porta. Dovresti ottenere alcune informazioni relative alle cadute di output, come se qualcosa stesse provando a trasmettere su frame di grandi dimensioni, cosa che potrebbe accadere se non disponi di MTU coerenti in tutta la tua rete.