Drop di output sull'interfaccia seriale: accodamento migliore o dimensioni della coda di output?

Sui router perimetrali Internet che parlano tra eBGP a più operatori e iBGP tra loro, tutte le interfacce sul lato LAN e WAN sono GE ad eccezione di un Serial full-DS3 (~ 45 Mbps) su ciascun router. Anche se penso che difficilmente invii molto traffico in uscita sulle interfacce seriali - nell'intervallo 3-10 Mbps - vedo cadute di coda di output costanti (OQD). È probabile la spiegazione che non c'è davvero traffico intenso che non vedo poiché l'intervallo di carico è al minimo di 30 secondi e il polling SNMP sta calcolando la media del traffico su 5 minuti, quindi quelli non illumineranno l'esaurimento?

La piattaforma è un Cisco 7204VXR NPE-G2. L'accodamento seriale è fifo .

Serial1 / 0 è attivo, il protocollo di linea è attivo
  L'hardware è M2T-T3 + pa
  Descrizione: -removed-
  L'indirizzo Internet è abcd / 30
  MTU 4470 byte, BW 44210 Kbit, DLY 200 usec,
     affidabilità 255/255, carico utile 5/255, carico utile 1/255
  Incapsulamento HDLC, crc 16, loopback non impostato
  Keepalive set (10 sec)
  Il ritardo di riavvio è di 0 secondi
  Ultimo input 00:00:02, output 00:00:00, output hang mai
  Ultima cancellazione dei contatori "mostra interfaccia" 00:35:19
  Coda di input: 0/75/0/0 (size / max / drops / flushes); Cadute totali in uscita: 36
  Strategia di accodamento: fifo
  Coda di output: 0/40 (dimensione / max)
  Velocità di ingresso 30 secondi 260000 bit / sec, 208 pacchetti / sec
  Velocità di uscita 30 secondi 939000 bit / sec, 288 pacchetti / sec
     410638 pacchetti in input, 52410388 byte, 0 nessun buffer
     Ricevute 212 trasmissioni, 0 passaggi, 0 giganti, 0 valvole a farfalla
              0 parità
     0 errori di input, 0 CRC, 0 frame, 0 overrun, 0 ignorato, 0 abort
     515752 output di pacchetti, 139195019 byte, 0 underrun
     0 errori di output, 0 applique, 0 reset dell'interfaccia
     0 errori del buffer di output, 0 buffer di output sostituiti
     0 transizioni del corriere
   rxLOS inattivo, rxLOF inattivo, rxAIS inattivo
   txAIS inattivo, rxRAI inattivo, txRAI inattivo

24 ore dopo mostrerà migliaia di OQD. Spingiamo più traffico intorno alle 3 del mattino ogni giorno, quindi forse c'è un po 'di traffico intenso qui a cui non sto dando abbastanza peso.

Last clearing of "show interface" counters 1d01h
Input queue: 0/75/0/158 (size/max/drops/flushes); Total output drops: 12049

Mi piacerebbe spingere più traffico in uscita su DS3, ma non con la mia preoccupazione per l'OQD. L'ISP di livello 2 dietro DS3 ha POP che raddoppiano come punti di peering con 6+ di livello 1, quindi l'idea è quella di mettere quel traffico in rete con il client appena possibile rispetto al nostro ISP primario sul GE che è di livello 1 , ma devono farsi strada verso i loro scambi di peering. Il traffico in entrata non è un problema.

Esiste una strategia di accodamento migliore rispetto a FIFO in questa situazione? Osservando i documenti Cisco sulle cadute della coda di input e output, non è consigliabile aumentare la dimensione della coda in uscita poiché i pacchetti sono già sul router e sarebbe meglio rilasciare in ingresso in modo che TCP possa rallentare l'app. C'è molta larghezza di banda sui nostri collegamenti GE, quindi non c'è davvero bisogno di limitare l'ingresso. Non ci sono mappe delle politiche su questi router. Il 90% del traffico in uscita proviene dalle nostre risposte HTTP; la maggior parte del resto da FTP e SMTP. I collegamenti GE spingono 50-200 + Mbps.

Consiglieresti qualche aggiustamento al buffer delle dimensioni della coda di output? Queste interfacce seriali sono i nostri collegamenti di backup che preferirei utilizzare di più per il motivo indicato in precedenza (se valido), ma temperato con i miei criteri BGP che tentano di non sovraccaricare quell'interfaccia seriale (che appare molto scaricata la maggior parte del tempo).

Hai ragione, non vedresti davvero l'esplosione facilmente su SNMP. 1GE può inviare 1,48 Mbps, quindi ci vuole pochissimo tempo per congestionare i 45 Mbps, che può gestire meno di 75kpps.

Se l'ingresso è 1GE e l'uscita è 45 Mbps, ovviamente il punto di congestione di 45 Mbps dovrà eliminare i pacchetti. Questo è normale e previsto. Se aumenti i buffer, avrai più ritardo.
1GE impiega 0,45 ms per inviare 40 frame IP 1500B, che è in questo momento la quantità di burst che puoi gestire. Tuttavia il dequeueing su 45 Mbps richiede già 10ms.

Se non hai alcun problema acuto, probabilmente non farei nulla al riguardo. Ma se parte del traffico è più idoneo a diminuire rispetto ad altri, è necessario sostituire FIFO con le code basate su classi. Supponiamo che tu voglia dare la priorità in modo da eliminare più ftp e meno voip.
Quindi avrà anche più senso aggiungere più buffering al traffico ftp, poiché non è molto sensibile ai ritardi.

Se vuoi tentare la fortuna con buffer più profondi, dovrebbe bastare qualcosa del genere:

policy-map WAN-OUT
 class class-default
    fair-queue
    queue-limit 200 packets
!
interface Serial1/0
  service-policy output WAN-OUT

Ciò causerebbe buffer da 50 ms su Serial1 e consentirebbe di gestire fino a 2,25 ms di burst dalla singola interfaccia Gige.

Gli OQD sono generalmente causati da una di queste due cose:

1. Stai utilizzando troppo il link; con un utilizzo elevato costante o traffico intenso.

2. All'interfaccia è stata applicata una mappa delle politiche configurata per eseguire operazioni come il controllo o la modellazione di tutto o parte del traffico

3. C'è un qualche tipo di errore sull'interfaccia, dai un'occhiata ai contatori di errori ( show interface Serial1/0 counters errors) e controlla che non stia rilasciando i pacchetti a causa di un errore.

Potresti esaminare (se non ne hai già uno) mettere in atto una mappa delle politiche per fare cose come dare alla tua missione traffico critico la propria coda, abilitare la prevenzione della congestione sul traffico regolare (WRED) o anche solo abilitare una coda corretta sul traffico, quindi che la larghezza di banda sia condivisa tra i flussi che transitano nell'interfaccia.

Come hai accennato, un'altra opzione sarebbe aumentare la dimensione della coda di output sull'interfaccia, ma se si dovesse utilizzare una mappa delle politiche, non sarebbe comunque necessario in quanto la politica creerebbe altre sotto-code.