Caídas de salida en la interfaz en serie: ¿mejor cola o tamaño de cola de salida?

En los enrutadores de borde de Internet que hablan eBGP a múltiples operadores e iBGP entre sí, todas las interfaces en el lado LAN y WAN son GE, excepto un Serial full-DS3 (~ 45Mbps) en cada enrutador. Aunque creo que apenas envío mucho tráfico saliente en las interfaces seriales, en el rango de 3-10 Mbps, veo caídas de cola de salida constantes (OQD). ¿Es la explicación probable de que realmente hay tráfico en ráfagas que no estoy viendo ya que el intervalo de carga está en el mínimo de 30 segundos y el sondeo SNMP está promediando el tráfico durante 5 minutos, por lo que esos no iluminarán el estallido?

La plataforma es un Cisco 7204VXR NPE-G2. La cola en serie es de quince .

Serial1 / 0 está activo, el protocolo de línea está activo
  El hardware es M2T-T3 + pa
  Descripción: -removed-
  La dirección de Internet es abcd / 30
  MTU 4470 bytes, BW 44210 Kbit, DLY 200 usec,
     fiabilidad 255/255, txload 5/255, rxload 1/255
  Encapsulación HDLC, crc 16, loopback no establecido
  Conjunto Keepalive (10 segundos)
  El retraso de reinicio es de 0 segundos
  Última entrada 00:00:02, salida 00:00:00, salida bloqueada nunca
  Última eliminación de los contadores de "show interface" 00:35:19
  Cola de entrada: 0/75/0/0 (tamaño / máx. / Gotas / descargas); La producción total cae: 36
  Estrategia de colas: fifo
  Cola de salida: 0/40 (tamaño / máx.)
  Velocidad de entrada de 30 segundos 260000 bits / seg, 208 paquetes / seg.
  Velocidad de salida de 30 segundos 939000 bits / seg., 288 paquetes / seg.
     410638 paquetes de entrada, 52410388 bytes, 0 sin búfer
     Recibió 212 transmisiones, 0 runas, 0 gigantes, 0 aceleradores
              0 paridad
     0 errores de entrada, 0 CRC, 0 trama, 0 desbordamiento, 0 ignorado, 0 aborto
     Salida de paquetes 515752, 139195019 bytes, 0 subestimaciones
     0 errores de salida, 0 apliques, 0 restablecimientos de interfaz
     0 fallas del búfer de salida, 0 búferes de salida intercambiados
     0 transiciones de portadora
   rxLOS inactivo, rxLOF inactivo, rxAIS inactivo
   txAIS inactivo, rxRAI inactivo, txRAI inactivo

24 horas después mostrará miles de OQD. Impulsamos más tráfico alrededor de las 3 de la madrugada cada día, por lo que tal vez haya un poco de tráfico con ráfagas aquí al que no le estoy dando suficiente peso.

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

Me gustaría impulsar más tráfico saliente en el DS3, pero no con mi preocupación en el OQD. El ISP de nivel 2 detrás del DS3 tiene POP que se duplican como puntos de interconexión con más de 6 niveles 1, por lo que la idea es obtener ese tráfico en la red con el cliente lo antes posible en comparación con nuestro ISP principal en el GE que es un nivel 1 , pero deben abrirse camino hacia sus intercambios entre pares. El tráfico entrante no es una preocupación.

¿Hay una mejor estrategia de cola que Fifo en esta situación? Mirando los documentos de Cisco sobre las caídas de la cola de entrada y salida, no se recomienda incrementar el tamaño de la cola de salida ya que los paquetes ya están en el enrutador y sería mejor soltar en la entrada para que TCP pueda acelerar la aplicación. Hay mucho ancho de banda en nuestros enlaces GE, por lo que no hay necesidad de limitar la entrada. No hay mapas de políticas en estos enrutadores. El 90% del tráfico saliente proviene de nuestras respuestas HTTP; La mayoría del resto de FTP y SMTP. Los enlaces de GE empujan 50-200 + Mbps.

¿Recomendaría algún ajuste en el búfer de tamaño de la cola de salida? Estas interfaces seriales son nuestros enlaces de respaldo que preferiría utilizar más por la razón dada anteriormente (si es válida), pero moderadas con mis políticas BGP que intentan no sobrecargar esa interfaz serial (que parece muy poco cargada la mayor parte del tiempo).

cisco router

— generalnetworkerror
fuente

Respuestas:

Tienes razón, realmente no verías la explosión fácilmente en SNMP. 1GE puede enviar 1.48Mpps, por lo que lleva muy poco tiempo congestionar los 45Mbps, que pueden manejar menos de 75kpps.

Si su entrada es 1GE y la salida es 45Mbps, entonces obviamente el punto de congestión de 45Mbps necesitará soltar paquetes. Esto es normal y esperado. Si aumenta los búferes, introducirá más demora.
1GE tarda 0,45 ms en enviar 40 marcos IP de 1500 B, que es ahora la cantidad de ráfaga que puede manejar. Sin embargo, eliminarlos en los 45 Mbps ya lleva 10 ms.

Si no tiene ningún problema grave, probablemente no haría nada al respecto. Pero si algún tráfico es más elegible para caer que otro, entonces debe reemplazar FIFO con colas basadas en clases. Digamos que tal vez desee priorizar para que se elimine más ftp y menos voip.
Entonces también tendrá más sentido agregar más almacenamiento en búfer en el tráfico ftp, ya que no es realmente sensible al retraso.

Si quieres probar suerte con buffers más profundos, algo como esto debería ser suficiente:

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

Esto provocaría almacenamientos intermedios de 50 ms en el Serial1 y le permitiría manejar ráfagas de hasta 2.25 ms desde una única interfaz Gige.

— ytti
fuente

La entrada y salida principal son 1GE en nuestras rutas primarias con un porcentaje de tráfico que pasa por los DS3. Q editado para mostrar que el 90% de salida es el tráfico de respuesta HTTP con FTP y SMTP que constituyen el resto.

— generalnetworkerror 01 de

Evitaría usar el DS3 cuando el Gige esté disponible, debido a los retrasos causados por el almacenamiento en búfer. Sin embargo, todas esas aplicaciones mencionadas parecen ser muy resistentes a las demoras y las pérdidas.

— ytti 01 de

La otra razón que no mencioné para tratar de usar más DS3 es para tratar de evitar las cargas de ráfaga en los enlaces GE WAN que activan> 100Mb. Aunque explotamos diariamente por encima de 100Mb, no ha sido lo suficientemente largo como para importar (todavía).

— generalnetworkerror

Podría conducir más tráfico al DS3 e incluso reducir las caídas de paquetes al introducir más demoras. Pero si está proyectando aumentar sus tasas de tráfico, entonces el problema empeorará cada vez más. Recuerde que Ethernet nunca es otra cosa que 100% o 0%, el tiempo que varía es 100%. Por lo tanto, siempre terminará amortiguando las ráfagas causadas por su red 1GE de alta velocidad.

— ytti 01 de

Mi justificación para 200 paquetes es el retraso que se tarda en enviarlos a sus 45 Mbps, que es de 50 ms, que todavía es un retraso tolerable para las aplicaciones de datos. Debe preguntarse cuánto tiempo va a tolerar y luego especificar el búfer para cumplir ese objetivo. En tu situación, solo usaría el gige.

— ytti

Los OQD generalmente son causados por una de dos cosas:

Estás sobreutilizando el enlace; ya sea con alto uso constante o tráfico explosivo.
Tiene un mapa de políticas aplicado a la interfaz que está configurado para hacer algo como vigilar o dar forma a parte o todo el tráfico
Hay algún tipo de error en la interfaz, eche un vistazo a los contadores de errores ( show interface Serial1/0 counters errors) y verifique que no se caigan los paquetes debido a un error.

Podrías investigar (si aún no tienes uno) establecer un mapa de políticas para hacer cosas como darle a tu tráfico de misión crítica su propia cola, evitar la congestión en el tráfico regular (WRED) o incluso habilitar la cola justa en el tráfico para que el ancho de banda se comparte entre los flujos que transitan por la interfaz.

Como ha mencionado, otra opción sería aumentar el tamaño de la cola de salida en la interfaz, pero si fuera a utilizar un mapa de políticas, no habría necesidad de hacerlo de todos modos, ya que la política crearía otras subcolas.

— David Rothera
fuente