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.
Respostas:
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.
fonte
(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:
Cada interface de membro possui
tx-queue-limit 26; Tenho certeza de que fiz isso por um motivo.Se você conseguir que as duas extremidades da Cisco o façam ... tente o balanceamento de carga por pacote:
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)
fonte