Як розподіляється корисна навантаження через з'єднання PPP Multilink

Веб-сайт, який я підтримую, використовує налаштування 3 T1 за допомогою PPP multilink Вони намагаються використовувати Jive, який є влаштованим VoIP-провайдером, із жахливими результатами. Я хочу знати, як розподіляються пакети між окремими T1, оскільки я думаю, що це може допомогти пояснити, що відбувається.

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

Як розподіляються пакети між декількома T1. Я припускаю, що це не те саме, що Ethernet зв’язок.

Якщо PPP з багатопосиланням - це питання, що я можу подивитися на маршрутизаторах, які це покажуть? Чи можна це виправити? Маршрутизатори - це Cisco, я вважаю, що це 2800, але мені доведеться двічі перевірити.

Ой ... леме днопоглинання тих давно невикористаних нейронів, щоб пам’ятати, як працює Multilink PPP.

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

З ДПП Multilink вони домовляються про це, але вони також домовляються, коли буде створено перше посилання, MRRU або Максимально реконструйований приймальний відділ.

Оскільки Multilink PPP додав додатковий простір заголовків кадру, творці були стурбовані проблемами MTU Path, тому вони вирішили, що Multilink зможе фрагментувати та збирати пакети на будь-якому кінці сеансу PPP Multilink.

Отже, так, на відміну від зв'язку 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's.) У цьому випадку ми були змушені зробити це саме так, оскільки вони були на різних візитках. (7500 не можуть [читати: чи не , їх карають до RSPs] роблять MLPPP через VIP-персон)