Quedas de saída na interface serial: Melhor fila ou tamanho da fila de saída?

Nos roteadores de borda da Internet que falam eBGP para várias operadoras e iBGP entre si, todas as interfaces no lado LAN e WAN são GE, exceto um DS3 serial completo (~ 45 Mbps) em cada roteador. Embora eu ache que dificilmente estou enviando muito tráfego de saída nas interfaces seriais - na faixa de 3 a 10 Mbps -, vejo quedas constantes na fila de saída (OQD). É a explicação provável de que realmente há tráfego estourado que eu não estou vendo, pois o intervalo de carga está no mínimo de 30 segundos e a pesquisa SNMP está em média com o tráfego em 5 minutos, para que eles não iluminem o estouro?

A plataforma é um Cisco 7204VXR NPE-G2. O enfileiramento serial é quino .

Serial1 / 0 está ativo, protocolo de linha está ativo
  O hardware é M2T-T3 + pa
  Descrição: -removed-
  O endereço na Internet é abcd / 30
  Bytes MTU 4470, BW 44210 Kbit, DLY 200 usec,
     confiabilidade 255/255, txload 5/255, rxload 1/255
  Encapsulamento HDLC, crc 16, loopback não definido
  Conjunto de manutenção de atividade (10 seg)
  Atraso na reinicialização é 0 segundos
  Última entrada 00:00:02, saída 00:00:00, saída travada nunca
  Última limpeza dos contadores "show interface" 00:35:19
  Fila de entrada: 0/75/0/0 (tamanho / máx / quedas / descargas); Quedas na produção total: 36
  Estratégia de enfileiramento: fifo
  Fila de saída: 0/40 (tamanho / máx.)
  Taxa de entrada de 30 segundos 260000 bits / s, 208 pacotes / s
  Taxa de saída de 30 segundos 939000 bits / s, 288 pacotes / s
     410638 pacotes de entrada, 52410388 bytes, 0 sem buffer
     Recebeu 212 transmissões, 0 runts, 0 gigantes, 0 reguladores de pressão
              0 paridade
     0 erros de entrada, 0 CRC, 0 quadro, 0 saturação, 0 ignorado, 0 cancelado
     515752 pacotes de saída, 139195019 bytes, 0 underruns
     0 erros de saída, 0 apliques, 0 redefinições de interface
     0 falhas no buffer de saída, 0 buffers de saída trocados
     0 transições de portadora
   rxLOS inativo, rxLOF inativo, rxAIS inativo
   txAIS inativo, rxRAI inativo, txRAI inativo

24 horas depois mostrará milhares de OQD. Nós empurramos mais tráfego por volta das 3 da manhã todos os dias, então talvez haja algum tráfego estourado aqui para o qual não estou dando peso suficiente.

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

Eu gostaria de aumentar o tráfego de saída no DS3, mas não com a minha preocupação com o OQD. O ISP de camada 2 atrás do DS3 possui POPs que duplicam como pontos de peering com mais de 6 camadas 1, portanto, a idéia é obter esse tráfego on-net com o cliente o mais cedo possível, em oposição ao nosso ISP principal na GE que é de camada 1 , mas devem seguir o caminho das trocas de pares. O tráfego de entrada não é uma preocupação.

Existe uma estratégia de filas melhor do que o quino nessa situação? Olhando para os documentos da Cisco sobre as filas de entrada e saída, não é recomendável aumentar o tamanho da fila de saída, pois os pacotes já estão no roteador e seria melhor deixá-lo na entrada para que o TCP possa acelerar o aplicativo de volta. Há muita largura de banda em nossos links da GE, portanto não há realmente necessidade de limitar a entrada. Não há mapas de políticas nesses roteadores. 90% do tráfego de saída vem de nossas respostas HTTP; a maioria do resto do FTP e SMTP. Os links da GE empurram 50-200 + Mbps.

Você recomendaria algum ajuste no buffer de tamanho da fila de saída? Essas interfaces seriais são nossos links de backup que eu preferiria utilizar mais pelo motivo indicado anteriormente (se válido), mas temperado com minhas políticas de BGP que tentam não sobrecarregar essa interface serial (que parece muito sub-carregada na maioria das vezes).

Você está certo, você realmente não veria o barulho facilmente no SNMP. O 1GE pode enviar 1,48Mpps, portanto, leva muito pouco tempo para congestionar os 45Mbps, que podem lidar com menos de 75kpps.

Se a sua entrada for 1GE e a saída for 45 Mbps, obviamente o ponto de congestionamento de 45 Mbps precisará descartar pacotes. Isso é normal e esperado. Se você aumentar os buffers, introduzirá mais atraso.
O 1GE leva 0,45 ms para enviar 40 quadros IP 1500B, que atualmente são a quantidade de burst que você pode suportar. No entanto, desenfileirá-los nos 45Mbps já leva 10ms.

Se você não tiver nenhum problema agudo, provavelmente não faria nada a respeito. Mas se algum tráfego for mais elegível para queda do que outro, substitua o FIFO pelo enfileiramento baseado em classe. Digamos que você queira priorizar para que mais ftp seja eliminado e menos voip.
Também fará mais sentido adicionar mais buffer no tráfego ftp, pois não é realmente sensível a atrasos.

Se você quiser tentar a sorte com buffers mais profundos, algo como isso deve ser suficiente:

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

Isso causaria 50ms de buffer no Serial1 e permitiria que você gerencie até 2,25ms de rajada a partir de uma única interface Gige.

Os OQDs geralmente são causados ​​por uma de duas coisas:

1. Você acabou de utilizar o link; com alto uso constante ou tráfego intenso.

2. Você tem um mapa de políticas aplicado à interface configurada para fazer algo como policiar ou moldar parte ou todo o tráfego

3. Há algum tipo de erro na interface, dê uma olhada nos contadores de erros ( show interface Serial1/0 counters errors) e verifique se não está descartando os pacotes devido a um erro.

Você pode examinar (se você ainda não tem um) a criação de um mapa de políticas para fazer coisas como dar ao seu tráfego de missão crítica sua própria fila, permitir evitar congestionamentos no tráfego regular (WRED) ou até mesmo permitir filas justas no tráfego, para que a largura de banda é compartilhada entre os fluxos que transmitem a interface.

Como você mencionou, outra opção seria aumentar o tamanho da fila de saída na interface, mas se você usasse um mapa de políticas, não haveria necessidade disso, pois a política criaria outras sub-filas.