Como a carga útil é distribuída nas conexões Multilink PPP

Um site que eu suporte usa a configuração de 3 T1s com o PPP multilink. Eles estão tentando usar o Jive, que é um provedor de VoIP hospedado, com resultados horríveis. Quero saber como os pacotes são distribuídos entre os T1s individuais, pois acho que isso pode ajudar a explicar o que está acontecendo.

O monitoramento SNMP da interface multilink mostra que eles têm capacidade disponível, mas suas chamadas de teste de VoIP são horríveis. Ele age como se houvesse uma quantidade enorme de tremulação e queda de pacotes. Embora testes simples com o PING / Iperf não mostrem tremulação / latência tão ruins quanto o esperado, dada a qualidade da chamada.

Como os pacotes são distribuídos entre os vários T1s. Presumo que não seja o mesmo que ligação Ethernet.

Se o PPP com vários links for um problema, o que posso ver nos roteadores que mostrarão isso? Pode ser corrigido? Os roteadores são da Cisco, acredito que sejam 2800s, mas eu precisaria verificar novamente.

Oi ... deixe-me desenterrar esses neurônios há muito não utilizados para lembrar como o Multilink PPP funciona.

Durante a fase LCP, quando o primeiro link é criado durante uma sessão PPP não multilink, os dois lados negociam o MRU (Maximum Receive Unit) para cada direção do link ... basicamente, cada lado diz ao outro qual o tamanho de um pacote ele pode lidar com o envio para ele.

Com o Multilink PPP, eles negociam isso, mas também negociam, quando o primeiro link é ativado, uma MRRU ou Unidade de recebimento máxima reconstruída.

Como o Multilink PPP adicionou espaço extra ao cabeçalho do quadro, os criadores estavam preocupados com os problemas do Path MTU, então eles decidiram que o Multilink seria capaz de fragmentar e remontar pacotes nas duas extremidades da sessão do Multilink PPP.

Então, sim, ao contrário da ligação Ethernet, não é apenas uma questão de balancear quadros pelos vários links ... os quadros podem realmente ser fragmentados e remontados. Isso pode causar um salto na latência e tremulação.

Nos T-1, você deve poder configurar cada lado com um MRU e MRRU significativamente maior do que quaisquer pacotes que provavelmente precisariam cruzar o link, e se o MRU for tão grande quanto ou maior que o MRRU, você não deverá ' Não vejo nenhuma fragmentação e remontagem ocorrendo. Espero que isso controle a latência e a instabilidade e ajude o seu comportamento de VoIP. Você provavelmente precisará ajustar essa configuração nos dois lados dos links, pois cada direção é negociada de forma independente.

Em geral, eu não esperaria que os pacotes VoIP precisassem ser fragmentados, embora ... eles tendem a não ser grandes o suficiente para precisar disso. Vale a pena conferir os tamanhos de MRU e MRRU nos links e na sessão Multilink, talvez eles estejam fora de sintonia e causando problemas.

(não usei o MLPPP desde os dias anteriores ao VoIP. na verdade, estou vendo uma configuração arquivada de 2003)

A única coisa que posso acrescentar:

interface Multilink X
  no ppp multilink fragmentation

Cada interface de membro possui tx-queue-limit 26; Tenho certeza de que fiz isso por um motivo.

Pode ser corrigido?

Se você conseguir que as duas extremidades da Cisco o façam ... tente o balanceamento de carga por pacote:

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

Isso funciona ainda melhor (pelo menos entre os da Cisco). Nesse caso, fomos forçados a fazer dessa maneira porque estavam em placas de linha diferentes. (7500 não pode [leia-se: não , eles são apontados para os RSPs] fazem MLPPP entre VIPs)