El ASR920 y la salida disminuyen: sorprendentemente, IPTV parece funcionar bien

Tal vez mi pregunta sea un poco inusual porque no preguntaré por qué algo no funciona. En cambio, preguntaré por qué las cosas parecen funcionar bien.

Tengo ASR-920-24SZ-IM conectado a ASR9ks aguas arriba con enlaces 2x10G. El dispositivo aguas abajo es cisco 4948E que actúa como un dispositivo de acceso (conectado a través de otro enlace 10G). Los servicios que se entregan al 4948E son acceso a Internet, un montón de E-LINE e IPTV.

Los enlaces ascendentes se utilizan moderadamente: ~ 20% y 10%. Sin embargo, observo caídas de salida en la interfaz hacia 4948E.

 Last clearing of "show interface" counters 01:52:25
 Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 122398
 Queueing strategy: fifo

Como no hay una configuración de QoS en la interfaz ASR920 hacia 4948E, debe haber 120kB de búfer disponible en ese puerto. Si mis cálculos son correctos, esto significaría que ASR920 puede almacenar aproximadamente 0,1 ms de tráfico durante la ráfaga de velocidad de línea proveniente de enlaces 10G ascendentes.

Lo que es interesante, los clientes de IPTV ni el sistema de monitoreo no informan ningún problema con el tráfico de multidifusión, que es sensible a las caídas de paquetes. Cada canal de IPTV tiene una transmisión de 10-20 Mbps (velocidad de bits variable o constante) con un tamaño de paquete de 1358 bytes.

¿Cómo es posible que la multidifusión no parezca sufrir a pesar de las caídas de producción?

EDITAR:

Después de 48 horas, los contadores se ven a continuación:

Last clearing of "show interface" counters 2d05h
Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 1217201
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 576849000 bits/sec, 243662 packets/sec
30 second output rate 3706610000 bits/sec, 374245 packets/sec
 29523227831 packets input, 8591353468212 bytes, 0 no buffer
 Received 44508 broadcasts (0 IP multicasts)
 0 runts, 0 giants, 0 throttles 
 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
 0 watchdog, 977069 multicast, 0 pause input
 50286674450 packets output, 62508590137876 bytes, 0 underruns

Desafortunadamente no sé qué códec es, pero intentaré averiguarlo.

La secuencia de prueba es una tasa de bits constante y el intervalo entre paquetes es de 500 us.

Timestamp: 0.523377 Diff: 0.000544 Sender: 10.200.200.207:34620 Size:1316
Timestamp: 0.523866 Diff: 0.000489 Sender: 10.200.200.207:34620 Size:1316
Timestamp: 0.524424 Diff: 0.000558 Sender: 10.200.200.207:34620 Size:1316
Timestamp: 0.524935 Diff: 0.000511 Sender: 10.200.200.207:34620 Size:1316
Timestamp: 0.525474 Diff: 0.000539 Sender: 10.200.200.207:34620 Size:1316
Timestamp: 0.525977 Diff: 0.000503 Sender: 10.200.200.207:34620 Size:1316

Solo hay una explicación que me viene a la mente en este momento: las explosiones son inferiores a 500 us. Sé que las caídas de salida están ahí y nos lleva más de 100 a la caída de cola. Si las ráfagas son de 200-300 us de largo, causará caídas de salida, pero no debería afectar la multidifusión.

A continuación proporciono algunos resultados según lo solicitado.

ASR920#show interfaces te0/0/27 stats
TenGigabitEthernet0/0/27
      Switching path    Pkts In   Chars In   Pkts Out  Chars Out
           Processor          0          0      22354    8324046
         Route cache          0          0          0          0
   Distributed cache          0          0          0          0
               Total          0          0      22354    8324046

El comando sh interfaces te0/0/27 switchno parece ser compatible con esta plataforma.

Como se señaló en los comentarios, mientras que el conteo de caídas parece alto, en comparación con el tráfico total, en realidad es bastante bajo. La tasa de caída de salida es 2.4e-5 o 0.0024%, por lo que si las caídas ocurren a intervalos regulares, su flujo de prueba experimentará un paquete perdido aproximadamente cada 41.7k paquetes enviados. Incluso la multidifusión no debería tener problemas para recuperarse de una tasa de caída tan baja y un usuario final probablemente no notará nada de qué quejarse. Eso también supone que cualquiera o todas las gotas son multidifusión.

También parece estar tratando de entender cómo / por qué se producen las gotas y está mirando las explosiones como fuente de las gotas. ¿Hay alguna razón por la que creas que este es el caso? No ha proporcionado su versión de código o la configuración del ASR, pero me inclinaría más hacia algo como un error como CSCuw45886 para ser la fuente de sus problemas.

La tasa de caída fue tan baja que puede ignorarse