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

对多链路接口的SNMP监视显示它们具有可用的容量，但是它们的VoIP测试呼叫太可怕了好像有大量的抖动和丢包现象。尽管使用PING / Iperf进行的简单测试并未显示出抖动/延迟，这在给定呼叫质量的情况下并没有您预期的那么糟糕。

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

如果多链路PPP是一个问题，我该如何在路由器上看到这一点呢？可以纠正吗？路由器是Cisco，我相信它们是2800，但是我必须仔细检查。

评论

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

#1 楼

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

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

通过Multilink PPP，他们协商，但他们还会协商建立第一个链接时的MRRU或最大重构接收单元。

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

所以，是的，与以太网绑定不同，它不仅仅是平衡多个链路上的帧的问题。 ..框架实际上可以被分段和重新组装。这可能会导致延迟和抖动的跳跃。

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

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

#2 楼

（自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


效果更好（至少在Cisco之间）。在这种情况下，我们被迫这样做因为它们在不同的线路卡上。 （7500不能[读取：不，它们被RSP撞了]在VIP之间执行MLPPP）