Tải trọng được phân phối trên các kết nối PPP của Multilink như thế nào

Một trang web tôi hỗ trợ sử dụng thiết lập 3 T1 với PPP đa cấp. Họ đang cố gắng sử dụng Jive , một nhà cung cấp VoIP được lưu trữ, với kết quả khủng khiếp. Tôi muốn biết làm thế nào các gói được phân phối giữa các T1 riêng lẻ vì tôi nghĩ điều này có thể giúp giải thích những gì đang xảy ra.

Giám sát SNMP của giao diện multilink cho thấy rằng họ có dung lượng khả dụng, nhưng các cuộc gọi kiểm tra VoIP của họ thật kinh khủng. Nó hoạt động như thể có một lượng lớn các gói jitter và bị rơi. Mặc dù các thử nghiệm đơn giản với PING / Iperf để không hiển thị jitter / độ trễ tệ như bạn mong đợi về chất lượng cuộc gọi.

Làm thế nào là các gói được phân phối giữa nhiều T1. Tôi cho rằng nó không giống như liên kết Ethernet.

Nếu PPP đa liên kết là một vấn đề, tôi có thể xem xét gì trên các bộ định tuyến sẽ hiển thị điều này? Nó có thể được sửa chữa? Các bộ định tuyến là Cisco, tôi tin rằng chúng là 2800, nhưng tôi sẽ phải kiểm tra lại.

Ôi ... hãy nạo vét những tế bào thần kinh không sử dụng lâu này để nhớ cách thức hoạt động của Multilink PPP.

Trong giai đoạn LCP khi liên kết đầu tiên được đưa ra trong phiên PPP không đa cấp, hai bên đàm phán MRU (Đơn vị nhận tối đa) cho mỗi hướng của liên kết ... về cơ bản, mỗi bên cho bên kia biết gói lớn như thế nào nó có thể xử lý được gửi đến nó.

Với Multilink PPP, họ đàm phán điều đó, nhưng họ cũng thương lượng, khi liên kết đầu tiên được đưa lên, MRRU hoặc Đơn vị nhận tái tạo tối đa.

Do Multilink PPP đã thêm không gian tiêu đề khung bổ sung, nên những người sáng tạo lo ngại về các vấn đề của MTU Đường dẫn, vì vậy họ đã quyết định rằng Multilink sẽ có thể phân mảnh và lắp ráp lại các gói vào cuối phiên của Multilink PPP.

Vì vậy, vâng, không giống như liên kết Ethernet, nó không chỉ là vấn đề cân bằng các khung trên nhiều liên kết ... các khung thực sự có thể bị phân mảnh và ghép lại. Điều này có thể gây ra một bước nhảy trong độ trễ và jitter.

Trên T-1, bạn sẽ có thể định cấu hình mỗi bên với MRU và MRRU lớn hơn đáng kể so với bất kỳ gói nào có thể cần phải vượt qua liên kết và nếu MRU lớn bằng hoặc lớn hơn MRRU, thì bạn không nên ' t thấy bất kỳ sự phân mảnh và lắp ráp lại xảy ra. Hy vọng rằng điều này sẽ kiểm soát được độ trễ và jitter và giúp xử lý hành vi VoIP của bạn. Tuy nhiên, bạn có thể sẽ cần điều chỉnh cấu hình này trên cả hai mặt của các liên kết, vì mỗi hướng được đàm phán độc lập.

Nói chung, tôi sẽ không mong muốn các gói VoIP cần được phân mảnh, mặc dù ... chúng có xu hướng không đủ lớn để cần điều đó. Đáng để thử kiểm tra kích thước MRU và MRRU của bạn trên các liên kết và phiên Multilink, có thể chúng đã thoát khỏi tình trạng hỗn loạn và gây ra sự cố.

(chưa sử dụng MLPPP từ những ngày trước VoIP. Thực tế tôi đang xem một cấu hình lưu trữ từ năm 2003)

Điều duy nhất tôi có thể thêm:

interface Multilink X
  no ppp multilink fragmentation

Mỗi giao diện thành viên có tx-queue-limit 26; Tôi chắc chắn rằng tôi đã làm điều đó vì một lý do.

Nó có thể được sửa chữa?

Nếu bạn có thể khiến cả hai đầu của Cisco thực hiện điều đó ... hãy thử cân bằng tải trên mỗi gói:

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

Điều đó thậm chí còn hoạt động tốt hơn (ít nhất là giữa Cisco.) Trong trường hợp này, chúng tôi buộc phải thực hiện theo cách này vì chúng nằm trên các dòng sản phẩm khác nhau. (7500 không thể [đọc: không , họ bị đưa vào RSP] làm MLPPP trên các VIP)