有效负载如何在Multilink PPP连接上分配

13

我支持的站点使用3个T1设置和多链路PPP。他们正在尝试使用托管的VoIP提供商Jive，结果令人震惊。 我想知道数据包如何在各个T1之间分配，因为我认为这可能有助于解释发生了什么。

SNMP对多链路接口的监视表明它们具有可用的容量，但是它们的VoIP测试呼叫太可怕了。它的作用就好像存在大量的抖动和丢包。尽管使用PING / Iperf进行的简单测试并未显示出抖动/等待时间，它不会像您给定的通话质量那样糟糕。

数据包如何在多个T1之间分配。我认为它与以太网绑定不同。

如果多链路PPP出现问题，我可以在显示此消息的路由器上查看什么？可以纠正吗？路由器是思科，我相信它们是2800，但是我必须仔细检查。

ppp

— Zoredache
source

有什么答案对您有帮助吗？如果是这样，您应该接受答案，这样问题就不会永远弹出来寻找答案。或者，您可以提供并接受自己的答案。

— 罗恩·莫平

12

Oi ... lemme疏通了那些长期未使用的神经元，以记住Multilink PPP的工作原理。

在LCP阶段中，当在非多链路PPP会话中建立第一条链路时，双方就链路的每个方向协商MRU（最大接收单元）...基本上，每一端都告诉对方数据包的大小它可以处理被发送给它。

使用Multilink PPP，他们可以协商，但是当建立第一个链路时，他们也可以协商MRRU或最大重建接收单元。

由于Multilink PPP添加了额外的帧头空间，因此创建者担心Path MTU问题，因此他们决定Multilink能够在Multilink PPP会话的任一端对数据包进行分段和重组。

因此，是的，与以太网绑定不同，它不只是平衡多个链路上的帧的问题……这些帧实际上可以被分段和重组。这会导致延迟和抖动的增加。

在T-1上，您应该能够为每一端配置比可能需要通过链路的任何数据包大得多的MRU和MRRU，并且如果MRU等于或大于MRRU，那么您不应该看不到任何碎片和重组发生。希望这可以控制延迟和抖动，并帮助您解决VoIP行为。但是，由于每个方向都是独立协商的，因此您可能需要在链接的两侧调整此配置。

通常，我不希望VoIP数据包需要分段，尽管...它们往往不够大而无法满足需要。值得一试来检查链接和Multilink会话上的MRU和MRRU大小，也许它们已经不合时宜并引起了问题。

— 杰夫·麦克亚当斯
source

3

（自VoIP出现以来，就没有使用过MLPPP。实际上，我正在查看的是2003年的存档配置）

我唯一可以添加的内容是：

interface Multilink X
  no ppp multilink fragmentation

每个成员接口都有tx-queue-limit 26；我确定我这样做是有原因的。

可以纠正吗？

如果您可以让思科双方都做到这一点，请尝试按数据包进行负载平衡：

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）

— 瑞奇光束
source