ペイロードはマルチリンクPPP接続間でどのように分散されますか

私がサポートするサイトは、マルチリンクPPPで3つのT1セットアップを使用しています。ホステッドVoIPプロバイダーであるJiveを使用しようとしていますが、結果は恐ろしいものです。 これが何が起こっているのかを説明するのに役立つと思うので、個々のT1間でパケットがどのように分配されるかを知りたいです。

マルチリンクインターフェイスのSNMPモニタリングは、利用可能な容量があることを示していますが、VoIPテストコールは恐ろしいものです。膨大な量のジッターとドロップされたパケットがあるかのように動作します。ただし、PING / Iperfを使用した簡単なテストでは、通話品質を考えると予想されるほど悪いジッター/レイテンシーは表示されません。

複数のT1間でパケットはどのように分散されますか。イーサネットボンディングと同じではないと思います。

マルチリンクPPPが問題である場合、これを表示するルーターで何を見ることができますか？修正できますか？ルーターはシスコです。2800であると思いますが、再確認する必要があります。

Oi ... lemmeは、長い間使用されていないニューロンをedgeして、Multilink PPPがどのように機能するかを覚えています。

非マルチリンクPPPセッション中に最初のリンクが起動されるLCPフェーズでは、両側がリンクの各方向のMRU（最大受信ユニット）をネゴシエートします...基本的に、各側はパケットの大きさを相手に伝えますそれに送信されることを処理できます。

マルチリンクPPPでは、ネゴシエートしますが、最初のリンクが確立されると、MRRU、または最大再構築受信ユニットもネゴシエートします。

マルチリンクPPPは余分なフレームヘッダースペースを追加したため、作成者はパスMTUの問題を懸念していたため、マルチリンクはマルチリンクPPPセッションのいずれかの端でパケットをフラグメント化および再構築できると判断しました。

そのため、はい、イーサネットボンディングとは異なり、複数のリンク間でフレームのバランスを取るだけではなく、フレームを実際に断片化して再構成することができます。これにより、レイテンシとジッタが急激に増加する可能性があります。

T-1では、リンクを通過する可能性が高いパケットよりも大幅に大きいMRUとMRRUを各側に設定できる必要があります。MRUがMRRUと同じかそれよりも大きい場合は、フラグメンテーションと再アセンブリが発生するのを確認します。これにより、遅延とジッターが制御され、VoIPの動作が改善されることを願っています。ただし、各方向は個別にネゴシエートされるため、リンクの両側でこの構成を調整する必要があります。

一般に、VoIPパケットを断片化する必要があるとは思わないでしょうが、それを必要とするほど大きくない傾向があります。リンクとマルチリンクセッションでMRUとMRRUのサイズをチェックする価値があります。おそらく、それらは強打から抜け出し、問題を引き起こしています。

（VoIPの前からMLPPPを使用していません。実際、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

それは（少なくともシスコの間で）さらにうまく機能します。この場合、異なるラインカード上にあるため、この方法を強制されました。（7500の人は[読む：しない、RSPにパントされる] VIP全体でMLPPPを行うことはできません）