Как распределяется полезная нагрузка по соединениям Multilink PPP

Сайт, который я поддерживаю, использует настройку 3 T1s с многоканальным PPP. Они пытаются использовать Jive, который является поставщиком VoIP, с ужасными результатами. Я хочу знать, как пакеты распределяются между отдельными T1, так как я думаю, что это может помочь объяснить, что происходит.

Мониторинг SNMP многоканального интерфейса показывает, что они имеют доступную емкость, но их тестовые вызовы VoIP ужасны. Он действует так, как будто существует огромное количество джиттера и отброшенных пакетов. Хотя простые тесты с PING / Iperf не показывают дрожание / задержку, что так плохо, как можно было бы ожидать, учитывая качество вызова.

Как пакеты распределяются между несколькими T1. Я предполагаю, что это не то же самое, что соединение Ethernet.

Если многоканальный PPP является проблемой, что я могу посмотреть на маршрутизаторах, которые покажут это? Это можно исправить? Маршрутизаторы Cisco, я считаю, что они 2800, но я должен был бы перепроверить.

Ой ... дай мне доделать эти давно не использованные нейроны, чтобы вспомнить, как работает Multilink PPP.

Во время фазы LCP, когда первая ссылка устанавливается во время не многоканального сеанса PPP, обе стороны согласовывают MRU (максимальную единицу приема) для каждого направления канала ... в основном, каждая сторона сообщает другой, насколько большой пакет он может справиться с отправкой на него.

С Multilink PPP они согласовывают это, но они также согласовывают, когда первая ссылка установлена, MRRU, или Максимально восстановленный блок приема.

Поскольку Multilink PPP добавил дополнительное пространство заголовка кадра, создатели были обеспокоены проблемами MTU пути, поэтому они решили, что Multilink сможет фрагментировать и повторно собирать пакеты на любом конце сеанса Multilink PPP.

Так что да, в отличие от соединения Ethernet, речь идет не просто о балансировке кадров по нескольким каналам ... кадры могут быть фрагментированы и повторно собраны. Это может вызвать скачок в задержке и дрожание.

На T-1 вы должны быть в состоянии настроить каждую сторону со значительно большим MRU и MRRU, чем любые пакеты, которые, вероятно, должны будут пересечь линию, и если MRU такой же большой или больше, чем MRRU, то вы не должны ' Не происходит фрагментация и повторная сборка. Надеемся, что это позволит контролировать задержку и дрожание и помочь вашему поведению VoIP. Тем не менее, вам, вероятно, потребуется настроить эту конфигурацию на обеих сторонах ссылок, поскольку каждое направление согласовывается независимо.

В общем, я бы не ожидал, что пакеты VoIP должны быть фрагментированными, хотя ... они, как правило, недостаточно велики, чтобы нуждаться в этом. Стоит попробовать проверить размеры MRU и MRRU в ссылках и сеансе Multilink, возможно, они выходят из строя и вызывают проблемы.

(не использовал MLPPP со дня до VoIP. фактически я смотрю на архивную конфигурацию от 2003)

Единственное, что я могу добавить:

interface Multilink X
  no ppp multilink fragmentation

У каждого члена интерфейса есть tx-queue-limit 26; Я уверен, что сделал это по причине.

Это можно исправить?

Если вы можете заставить оба конца Cisco делать это ... попробуйте балансировку нагрузки для каждого пакета:

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

Это работает даже лучше (по крайней мере, между Cisco). В этом случае мы были вынуждены сделать это таким образом, потому что они были на разных линейных картах. (7500 не могут [читай: нет , их наказывают RSP] делают MLPPP через VIP)