Yük, Multilink PPP bağlantılarında nasıl dağıtılır

Desteklediğim bir site, çoklu bağlantı PPP'si olan 3 T1 kurulumu kullanıyor. Onlar kullanmaya çalıştığınız Jive korkunç sonuçlarla barındırılan bir VoIP sağlayıcı vardır. Paketlerin bireysel T1'ler arasında nasıl dağıtıldığını bilmek istiyorum, çünkü bunun neler olduğunu açıklamaya yardımcı olabileceğini düşünüyorum.

Çoklu bağlantı arayüzünün SNMP izlemesi, kullanılabilir kapasiteye sahip olduklarını gösterir, ancak VoIP test çağrıları korkunçtur. Çok miktarda titreme ve bırakılan paketler varmış gibi davranır. PING / Iperf ile yapılan basit testler, arama kalitesi göz önüne alındığında beklediğiniz kadar kötü olan titreşim / gecikme göstermemektedir.

Paketler çoklu T1'ler arasında nasıl dağıtılır. Ethernet bağları ile aynı olmadığını varsayıyorum.

Çok bağlantılı PPP bir sorunsa, bunu gösterecek yönlendiricilerde nelere bakabilirim? Düzeltilebilir mi? Yönlendiriciler Cisco, 2800'lü olduklarına inanıyorum, ancak iki kez kontrol etmek zorunda kalacağım.

Oi ... lemme, Multilink PPP'nin nasýl çalýţtýđýný hatýrlamak için uzun süredir kullanılmayan nöronlarý tarar.

Çoklu bağlantı olmayan bir PPP oturumu sırasında ilk bağlantının getirildiği LCP aşamasında, iki taraf, bağlantının her yönü için MRU (Maksimum Alma Birimi) ile görüşür ... temelde her bir taraf diğerine bir paketin ne kadar büyük olduğunu söyler kendisine gönderilmesini idare edebilir.

Multilink PPP ile bunu müzakere ederler, ancak aynı zamanda ilk link açıldığında bir MRRU veya Maksimum Yeniden Yapılandırılmış Alma Ünitesi ile müzakere ederler.

Multilink PPP fazladan çerçeve başlık alanı eklediğinden, içerik oluşturucular Path MTU sorunları hakkında endişelendiler, bu nedenle Multilink'in Multilink PPP oturumunun her iki ucundaki paketleri parçalayabileceğine ve yeniden birleştirebileceğine karar verdiler.

Evet, Ethernet bağlamasından farklı olarak, bu sadece çerçevelerin çoklu bağlantılar arasında dengelenmesi meselesi değil ... çerçeveler aslında parçalanabilir ve yeniden birleştirilebilir. Bu, gecikme ve titremede bir sıçramaya neden olabilir.

T-1'lerde, her bir tarafı, bağlantıyı geçmesi gereken herhangi bir paketten önemli ölçüde daha büyük bir MRU ve MRRU ile yapılandırabilmelisiniz ve MRU, MRRU kadar büyük veya daha büyükse, yapmamalısınız. t meydana gelen parçalanma ve yeniden birleştirme işlemlerine bakın. Umarım bu gecikme ve titremeyi kontrol altına alır ve VoIP davranışınıza yardımcı olur. Bununla birlikte, her bir yön bağımsız olarak anlaşıldığı için, muhtemelen bu yapılandırmayı bağlantıların her iki tarafında ayarlamanız gerekecektir.

Genel olarak, VoIP paketlerinin parçalara ayrılmasını beklemem ... Bağlantılarda ve Multilink oturumunda MRU ve MRRU boyutlarınızı kontrol etmek için bir çekim yapmaya değer, belki de patlaktan ve sorunlara neden olabilirler.

(VoIP'den önceki günlerden beri MLPPP kullanmadım. Aslında 2003'ten beri arşivlenmiş bir yapılandırmaya bakıyorum)

Ekleyebileceğim tek şey:

interface Multilink X
  no ppp multilink fragmentation

Her üye arayüzünde tx-queue-limit 26; Eminim bunu bir nedenden dolayı yaptım.

Düzeltilebilir mi?

Her iki Cisco'nun da bitmesini sağlayabiliyorsanız ... paket başına yük dengelemeyi deneyin:

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

Bu daha da iyi çalışıyor (en azından Cisco'lar arasında). Bu durumda, farklı hatlarda oldukları için bu şekilde yapmak zorunda kaldık. (: 7500 en [okuyamaz yok VIP genelinde MLPPP do, bunlar RSPs için punted olsun])