我支持的一个站点使用 3 个 T1s 设置和多链路 PPP。他们试图使用托管 VoIP 提供商Jive，结果很糟糕。 我想知道数据包是如何在各个 T1 之间分配的，因为我认为这可能有助于解释发生了什么。
多链路接口的SNMP监控显示他们有可用容量，但他们的VoIP测试呼叫很糟糕。它表现得好像有大量的抖动和丢弃的数据包。尽管使用 PING/Iperf 进行的简单测试不会显示抖动/延迟，但考虑到通话质量，您可能会期望如此糟糕。
数据包如何在多个 T1 之间分布。我认为它与以太网绑定不同。
如果多链路 PPP 是一个问题，我可以在路由器上查看什么来显示此问题？可以纠正吗？路由器是 Cisco，我相信它们是 2800，但我必须仔细检查。
哎...让我疏通那些长期未使用的神经元，以记住 Multilink PPP 的工作原理。
在 LCP 阶段，当第一条链路在非多链路 PPP 会话期间建立时，双方协商链路的每个方向的 MRU（最大接收单元）……基本上每一方都告诉对方一个数据包有多大它可以处理被发送给它。
使用多链路 PPP，他们会协商，但他们也会协商，当第一条链路启动时，MRRU，或最大重构接收单元。
由于 Multilink PPP 添加了额外的帧头空间，创建者担心路径 MTU 问题，因此他们决定 Multilink 将能够在 Multilink PPP 会话的任一端对数据包进行分段和重组。
所以，是的，与以太网绑定不同，它不仅仅是跨多个链接平衡帧的问题……实际上可以将帧分段和重新组装。这会导致延迟和抖动的跳跃。
在 T-1 上，您应该能够为每一侧配置比任何可能需要通过链路的数据包大得多的 MRU 和 MRRU，如果 MRU 与 MRRU 一样大或大于 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
这效果更好（至少在 Cisco 之间）。在这种情况下，我们被迫这样做，因为它们在不同的线路卡上。（7500 不能[阅读：不要，他们被踢到 RSP] 跨 VIP 进行 MLPPP）