¿Cómo se distribuye la carga útil a través de conexiones PPP Multilink?

Un sitio que apoyo utiliza la configuración de 3 T1s con PPP multienlace. Están tratando de usar Jive, que es un proveedor de VoIP alojado, con resultados horribles. Quiero saber cómo se distribuyen los paquetes entre los T1 individuales, ya que creo que esto puede ayudar a explicar lo que está sucediendo.

El monitoreo SNMP de la interfaz multienlace muestra que tienen capacidad disponible, pero sus llamadas de prueba de VoIP son horribles. Actúa como si hubiera una gran cantidad de jitter y paquetes descartados. Aunque las pruebas simples con PING / Iperf no muestran jitter / latencia que es tan malo como cabría esperar dada la calidad de la llamada.

Cómo se distribuyen los paquetes entre los múltiples T1. Supongo que no es lo mismo que la vinculación de Ethernet.

Si el PPP multienlace es un problema, ¿qué puedo ver en los enrutadores que mostrarán esto? ¿Se puede corregir? Los enrutadores son Cisco, creo que son 2800, pero tendría que verificarlo dos veces.

Oi ... déjame desenterrar esas neuronas que no se usaron hace mucho tiempo para recordar cómo funciona Multilink PPP.

Durante la fase LCP, cuando se abre el primer enlace durante una sesión PPP sin enlaces múltiples, las dos partes negocian la MRU (Unidad de recepción máxima) para cada dirección del enlace ... básicamente, cada lado le dice al otro qué tan grande es un paquete puede manejar ser enviado a él.

Con Multilink PPP, negocian eso, pero también negocian, cuando se abre el primer enlace, un MRRU o Unidad de recepción máxima reconstruida.

Debido a que Multilink PPP agregó espacio de encabezado de trama adicional, los creadores estaban preocupados por los problemas de Path MTU, por lo que decidieron que Multilink podría fragmentar y volver a ensamblar paquetes en cualquier extremo de la sesión de Multilink PPP.

Entonces, sí, a diferencia de los enlaces de Ethernet, no se trata solo de equilibrar tramas a través de los enlaces múltiples ... las tramas en realidad se pueden fragmentar y volver a ensamblar. Esto puede causar un salto en la latencia y la inquietud.

En T-1, debería poder configurar cada lado con una MRU y MRRU significativamente más grande que cualquier paquete que probablemente necesite cruzar el enlace, y si la MRU es tan grande o más grande que la MRRU, entonces no debería ' No se produce ninguna fragmentación y reensamblaje. Con suerte, esto controlará la latencia y la fluctuación y ayudará a su comportamiento de VoIP. Sin embargo, es probable que deba ajustar esta configuración en ambos lados de los enlaces, ya que cada dirección se negocia de forma independiente.

En general, no esperaría que los paquetes de VoIP necesiten fragmentarse, aunque ... tienden a no ser lo suficientemente grandes como para necesitar eso. Vale la pena intentar comprobar sus tamaños de MRU y MRRU en los enlaces y en la sesión Multilink, tal vez estén fuera de control y causen problemas.

(No he usado MLPPP desde los días anteriores a VoIP. De hecho, estoy viendo una configuración archivada de 2003)

Lo único que puedo agregar:

interface Multilink X
  no ppp multilink fragmentation

Cada interfaz de miembro tiene tx-queue-limit 26; Estoy seguro de que lo hice por una razón.

¿Se puede corregir?

Si puede lograr que ambos extremos de Cisco lo hagan ... intente el equilibrio de carga por paquete:

interface Serial0/0/4:0
 ip address 198.xx.xx.210 255.255.255.252
 ip load-sharing per-packet
 no fair-queue
!
interface Serial1/0/5:0
 ip address 198.xx.xx.22 255.255.255.252
 ip load-sharing per-packet
 no fair-queue
!
ip route xxx.xxx.201.0 255.255.255.0 198.xx.xx.21
ip route xxx.xxx.201.0 255.255.255.0 198.xx.xx.209

Eso funciona aún mejor (al menos entre Cisco). En este caso, nos vimos obligados a hacerlo de esta manera porque estaban en tarjetas de línea diferentes. (Los 7500 no pueden [leer: no , son castigados por los RSP] hacen MLPPP a través de VIP)