W jaki sposób ładunek jest rozłożony na połączenia PPP Multilink

Witryna, którą obsługuję, wykorzystuje konfigurację 3 T1 z łączem PPP z wieloma łączami. Próbują używać Jive, który jest hostowanym dostawcą VoIP, ze strasznymi wynikami. Chcę wiedzieć, w jaki sposób pakiety są rozdzielane między poszczególne T1, ponieważ myślę, że może to pomóc wyjaśnić, co się dzieje.

Monitorowanie SNMP interfejsu łącza wielokrotnego pokazuje, że mają one dostępną pojemność, ale ich połączenia testowe VoIP są okropne. Działa tak, jakby była ogromna ilość jittera i upuszczonych pakietów. Mimo że proste testy z PING / Iperf nie wykazały zakłóceń / opóźnień, które są tak złe, jak można się spodziewać, biorąc pod uwagę jakość połączenia.

W jaki sposób pakiety są rozdzielane między wiele T1. Zakładam, że to nie to samo, co łączenie Ethernet.

Jeśli problemem jest PPP z wieloma linkami, na co mogę patrzeć na routerach, które to pokażą? Czy można to poprawić? Routery to Cisco, sądzę, że mają 2800 lat, ale musiałbym dwukrotnie sprawdzić.

Oi ... lemme pogłębiam te dawno nieużywane neurony, aby pamiętać, jak działa Multilink PPP.

Podczas fazy LCP, gdy pierwsze łącze jest wywoływane podczas sesji PPP bez łącza wielokrotnego, obie strony negocjują MRU (Maximum Receive Unit) dla każdego kierunku łącza ... w zasadzie każda strona mówi drugiej stronie, jak duży jest pakiet poradzi sobie z wysłaniem do niego.

Korzystając z Multilink PPP, negocjują to, ale negocjują również, gdy zostanie wyświetlone pierwsze łącze, MRRU lub maksymalną zrekonstruowaną jednostkę odbiorczą.

Ponieważ Multilink PPP dodał dodatkową przestrzeń nagłówka ramki, twórcy byli zaniepokojeni problemami ścieżki MTU, więc zdecydowali, że Multilink będzie w stanie fragmentować i ponownie składać pakiety na każdym końcu sesji Multilink PPP.

Tak więc, w przeciwieństwie do łączenia Ethernet, nie chodzi tylko o równoważenie ramek na wielu łączach ... ramki można faktycznie pofragmentować i ponownie złożyć. Może to spowodować skok opóźnienia i drgania.

Na T-1 powinieneś być w stanie skonfigurować każdą stronę ze znacznie większym MRU i MRRU niż jakikolwiek pakiet, który prawdopodobnie musiałby przekroczyć łącze, a jeśli MRU jest tak duży lub większy niż MRRU, nie powinieneś zobaczyć fragmentację i ponowny montaż. Mamy nadzieję, że pozwoli to kontrolować opóźnienia i fluktuacje oraz pomoże w zachowaniu VoIP. Prawdopodobnie będziesz musiał dostosować tę konfigurację po obu stronach łączy, ponieważ każdy kierunek jest negocjowany niezależnie.

Ogólnie rzecz biorąc, nie spodziewałbym się, że pakiety VoIP będą musiały zostać pofragmentowane, chociaż ... zwykle nie są wystarczająco duże, aby tego potrzebować. Warto spróbować swoich rozmiarów MRU i MRRU na linkach i sesji Multilink, być może są one bardzo dobre i powodują problemy.

(nie korzystałem z MLPPP od czasów poprzedzających VoIP. w rzeczywistości patrzę na zarchiwizowaną konfigurację z 2003 roku)

Jedyne, co mogę dodać:

interface Multilink X
  no ppp multilink fragmentation

Interfejs każdego członka ma tx-queue-limit 26; Jestem pewien, że zrobiłem to bez powodu.

Czy można to poprawić?

Jeśli możesz to zrobić, skorzystaj z obu końców Cisco ... spróbuj wyrównać obciążenie pakietu:

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

Działa to jeszcze lepiej (przynajmniej między Cisco). W tym przypadku byliśmy zmuszeni to zrobić w ten sposób, ponieważ byli na różnych kartach liniowych. (7500 nie może [czytać: nie , oni zostają przyłapani na RSP] zrobić MLPPP między VIPami)