Come viene distribuito il payload tra le connessioni PPP Multilink


13

Un sito che supporto utilizza 3 T1s setup con multilink PPP. Stanno cercando di usare Jive, che è un provider VoIP ospitato, con risultati orribili. Voglio sapere come vengono distribuiti i pacchetti tra i singoli T1 poiché penso che questo possa aiutare a spiegare cosa sta succedendo.

Il monitoraggio SNMP dell'interfaccia multilink mostra che hanno capacità disponibile, ma le loro chiamate al test VoIP sono orribili. Si comporta come se ci fosse un'enorme quantità di jitter e pacchetti rilasciati. Sebbene semplici test con PING / Iperf non mostrino jitter / latenza che è così grave come ci si potrebbe aspettare, vista la qualità della chiamata.

Come vengono distribuiti i pacchetti tra più T1. Presumo che non sia lo stesso del collegamento Ethernet.

Se il PPP multi-link è un problema, cosa posso vedere sui router che mostreranno questo? Può essere corretto? I router sono Cisco, credo che siano 2800, ma dovrei ricontrollare.


Qualche risposta ti è stata d'aiuto? in tal caso, dovresti accettare la risposta in modo che la domanda non continui a comparire per sempre, cercando una risposta. In alternativa, potresti fornire e accettare la tua risposta.
Ron Maupin

Risposte:


12

Oh ... lasciami trasportare quei neuroni a lungo inutilizzati per ricordare come funziona Multilink PPP.

Durante la fase LCP quando il primo collegamento viene richiamato durante una sessione PPP non multilink, le due parti negoziano l'MRU (unità di ricezione massima) per ciascuna direzione del collegamento ... praticamente ciascuna parte dice all'altro quanto è grande un pacchetto può gestire l'invio ad esso.

Con Multilink PPP, lo negoziano, ma negoziano anche, quando viene visualizzato il primo collegamento, una MRRU o unità di ricezione massima ricostruita.

Poiché Multilink PPP ha aggiunto ulteriore spazio per l'intestazione del frame, i creatori erano preoccupati per i problemi di Path MTU, quindi hanno deciso che Multilink sarebbe stato in grado di frammentare e riassemblare i pacchetti su entrambe le estremità della sessione PPP Multilink.

Quindi, sì, a differenza del collegamento Ethernet, non si tratta solo di bilanciare i frame tra i collegamenti multipli ... i frame possono effettivamente essere frammentati e riassemblati. Ciò può causare un salto di latenza e jitter.

Su T-1 dovresti essere in grado di configurare ogni lato con una MRU e una MRRU significativamente più grandi di qualsiasi pacchetto che probabilmente avrebbe bisogno di attraversare il collegamento, e se la MRU è grande come, o più grande della MRRU, allora non dovresti ' vedere eventuali frammentazioni e riassemblaggi in corso. Spero che ciò tenga sotto controllo la latenza e il jitter e aiuti il ​​tuo comportamento VoIP. Tuttavia, sarà probabilmente necessario modificare questa configurazione su entrambi i lati dei collegamenti, poiché ciascuna direzione viene negoziata in modo indipendente.

In generale, non mi aspetto che i pacchetti VoIP debbano essere frammentati, sebbene ... tendano a non essere abbastanza grandi per averne bisogno. Vale la pena provare le dimensioni della tua MRU e MRRU sui collegamenti e sulla sessione Multilink, forse sono fuori dai guai e causano problemi.


3

(non utilizzo MLPPP dai giorni precedenti al VoIP. in effetti sto guardando una configurazione archiviata dal 2003)

L'unica cosa che posso aggiungere:

interface Multilink X
  no ppp multilink fragmentation

Ogni interfaccia membro ha tx-queue-limit 26; Sono sicuro di averlo fatto per un motivo.

Può essere corretto?

Se riesci a ottenere entrambe le estremità Cisco per farlo ... prova il bilanciamento del carico per pacchetto:

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

Funziona ancora meglio (almeno tra quelli di Cisco.) In questo caso, siamo stati costretti a farlo in questo modo perché si trovavano su diverse schede. (7500 non possono [leggere: no , vengono puntati agli RSP] fare MLPPP su VIP)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.