น้ำหนักบรรทุกกระจายอย่างไรในการเชื่อมต่อ Multilink PPP

ไซต์ที่ฉันสนับสนุนใช้การตั้งค่า 3 T1s กับ multilink PPP พวกเขากำลังพยายามใช้Jiveซึ่งเป็นผู้ให้บริการ VoIP ที่โฮสต์ซึ่งมีผลลัพธ์ที่น่ากลัว ฉันต้องการทราบว่าแพ็คเก็ตมีการกระจายระหว่าง T1 แต่ละตัวอย่างไรเพราะฉันคิดว่านี่อาจช่วยอธิบายสิ่งที่เกิดขึ้นได้

การตรวจสอบ SNMP ของอินเทอร์เฟซ multilink แสดงว่าพวกเขามีความจุ แต่การทดสอบ VoIP ของพวกเขาน่ากลัว มันทำหน้าที่เหมือนมีกระวนกระวายใจจำนวนมากและแพ็คเก็ตลดลง แม้ว่าการทดสอบอย่างง่ายด้วย PING / Iperf จะไม่แสดงความกระวนกระวายใจ / แฝงที่ไม่ดีเท่าที่คุณอาจคาดหวังให้คุณภาพการโทร

แพ็กเก็ตแจกจ่ายอย่างไรระหว่าง T1 หลายตัว ฉันคิดว่ามันไม่เหมือนกับพันธะอีเธอร์เน็ต

หาก multi-link PPP เป็นปัญหาฉันจะดูสิ่งที่เราเตอร์ที่จะแสดงสิ่งนี้ได้อย่างไร สามารถแก้ไขได้ไหม? เราเตอร์คือ Cisco ฉันเชื่อว่าเป็น 2800s แต่ฉันต้องตรวจสอบอีกครั้ง

อ๋อ ... ลองขุดเซลล์ประสาทที่ไม่ได้ใช้มานานเพื่อจำว่า Multilink PPP ทำงานอย่างไร

ในช่วง LCP เมื่อการเชื่อมโยงครั้งแรกถูกนำขึ้นมาในช่วงที่ไม่ใช่มัลติลิงค์ PPP ทั้งสองฝ่ายเจรจา MRU (หน่วยรับสูงสุด) สำหรับแต่ละทิศทางของการเชื่อมโยง ... โดยทั่วไปแต่ละด้านจะบอกอีกว่าแพ็คเก็ตใหญ่แค่ไหน มันสามารถจัดการกับการถูกส่งไปยังมัน

ด้วย Multilink PPP พวกเขาเจรจานั้น แต่พวกเขายังเจรจาเมื่อนำลิงค์แรกขึ้น MRRU หรือหน่วยรับที่สร้างใหม่สูงสุด

เนื่องจาก Multilink PPP เพิ่มพื้นที่ส่วนหัวของเฟรมเพิ่มเติมผู้สร้างมีความกังวลเกี่ยวกับปัญหาของเส้นทาง MTU ดังนั้นพวกเขาจึงตัดสินใจว่า Multilink จะสามารถแยกส่วนและรวมกลุ่มแพ็กเก็ตใหม่ที่ส่วนท้ายของเซสชัน Multilink PPP

ดังนั้นใช่ซึ่งแตกต่างจากพันธะอีเธอร์เน็ตไม่เพียง แต่เป็นเรื่องของการสร้างความสมดุลให้กับเฟรมในลิงก์หลาย ๆ อัน ... เฟรมสามารถแยกส่วนและประกอบใหม่ได้จริง สิ่งนี้อาจทำให้เกิดความล่าช้าในการตอบสนองและความกระวนกระวายใจ

ใน T-1 คุณควรจะสามารถกำหนดค่าแต่ละด้านด้วย MRU และ MRRU ที่มีขนาดใหญ่กว่าแพ็กเก็ตใด ๆ ที่อาจต้องข้ามลิงก์และถ้า MRU นั้นมีขนาดใหญ่หรือใหญ่กว่า MRRU คุณก็ไม่ควรจะ ' ไม่เห็นการแยกส่วนและการประกอบซ้ำเกิดขึ้น หวังว่าสิ่งนี้จะได้รับความล่าช้าและความกระวนกระวายใจภายใต้การควบคุมและช่วยให้พฤติกรรม VoIP ของคุณ คุณอาจจำเป็นต้องปรับแต่งการกำหนดค่านี้ในทั้งสองด้านของลิงก์เนื่องจากแต่ละการเจรจามีความเป็นอิสระ

โดยทั่วไปแล้วฉันไม่คาดหวังว่าแพ็กเก็ต VoIP จะต้องมีการแยกส่วนแม้ว่า ... พวกเขามีแนวโน้มที่จะไม่ใหญ่พอที่จะต้องการมัน คุ้มค่าที่จะตรวจสอบขนาด MRU และ MRRU ของคุณที่ลิงก์และเซสชัน Multilink บางทีพวกเขาอาจจะตีตัวออกห่างและก่อให้เกิดปัญหา

(ไม่ได้ใช้ MLPPP ตั้งแต่วันก่อน VoIP จริง ๆ แล้วฉันกำลังดูการกำหนดค่าที่เก็บถาวรจาก 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) ในกรณีนี้เราถูกบังคับให้ทำเช่นนี้เพราะพวกเขาอยู่บน linecards ที่แตกต่างกัน (7500 ไม่สามารถ [อ่าน: ไม่พวกเขาเขวี้ยงต่อ RSP] ทำ MLPPP ใน VIP)