Un site que je supporte utilise 3 configurations T1 avec PPP à liaisons multiples. Ils essaient d'utiliser Jive qui est un fournisseur de VoIP hébergé, avec des résultats horribles. Je veux savoir comment les paquets sont distribués entre les T1 individuels car je pense que cela peut aider à expliquer ce qui se passe.
La surveillance SNMP de l'interface multiliaison montre qu'ils ont une capacité disponible, mais leurs appels de test VoIP sont horribles. Il agit comme s'il y avait une énorme quantité de gigue et de paquets perdus. Bien que des tests simples avec PING / Iperf ne montrent pas une gigue / latence aussi mauvaise que vous pourriez vous y attendre étant donné la qualité de l'appel.
Comment les paquets sont-ils répartis entre les multiples T1? Je suppose que ce n'est pas la même chose que la liaison Ethernet.
Si le PPP multi-liens est un problème, que puis-je regarder sur les routeurs qui le montreront? Peut-il être corrigé? Les routeurs sont Cisco, je crois qu'ils sont 2800, mais je devrais vérifier.
Réponses:
Oi ... lemme drague ces neurones longtemps inutilisés pour se rappeler comment fonctionne PPP Multilink.
Pendant la phase LCP lorsque la première liaison est établie au cours d'une session PPP non multiliaison, les deux parties négocient la MRU (Maximum Receive Unit) pour chaque direction de la liaison ... fondamentalement, chaque côté indique à l'autre la taille d'un paquet il peut gérer son envoi.
Avec Multilink PPP, ils négocient cela, mais ils négocient également, lorsque la première liaison est établie, une MRRU ou une unité de réception maximale reconstruite.
Parce que Multilink PPP a ajouté un espace d'en-tête de trame supplémentaire, les créateurs étaient préoccupés par les problèmes Path MTU, ils ont donc décidé que Multilink serait en mesure de fragmenter et de réassembler les paquets à chaque extrémité de la session PPP Multilink.
Donc, oui, contrairement à la liaison Ethernet, ce n'est pas seulement une question d'équilibrage des trames sur les multiples liaisons ... les trames peuvent en fait être fragmentées et réassemblées. Cela peut provoquer un saut de latence et de gigue.
Sur les T-1, vous devriez être en mesure de configurer chaque côté avec une MRU et MRRU significativement plus grande que tous les paquets qui auraient probablement besoin de traverser la liaison, et si la MRU est aussi grande ou plus grande que la MRRU, alors vous ne devriez pas '' t voir aucune fragmentation et réassemblage se produire. Espérons que cela contrôlera la latence et la gigue et aidera votre comportement VoIP. Vous devrez probablement ajuster cette configuration des deux côtés des liens, car chaque direction est négociée indépendamment.
En général, je ne m'attendrais pas à ce que les paquets VoIP aient besoin d'être fragmentés, bien que ... ils ont tendance à ne pas être assez gros pour en avoir besoin. Cela vaut la peine de vérifier vos tailles MRU et MRRU sur les liens et la session Multilink, peut-être qu'ils sont hors de contrôle et causent des problèmes.
la source
(Je n'ai pas utilisé MLPPP depuis les jours précédant la VoIP. En fait, je regarde une configuration archivée de 2003)
La seule chose que je peux ajouter:
Chaque interface membre a
tx-queue-limit 26; Je suis sûr que je l'ai fait pour une raison.Si vous pouvez obtenir les deux extrémités Cisco pour le faire ... essayez l'équilibrage de charge par paquet:
Cela fonctionne encore mieux (au moins entre Cisco.) Dans ce cas, nous avons été obligés de le faire de cette façon car ils étaient sur des cartes de ligne différentes. (Les 7500 ne peuvent pas [lire: ne le font pas , ils sont bottés vers les RSP] font le MLPPP à travers les VIP)
la source