โปรโตคอล PIM คือชุดของโปรโตคอลสำหรับการส่งมัลติคาสต์ในเครือข่ายระหว่างเราเตอร์ ความสัมพันธ์ในบริเวณใกล้เคียงถูกสร้างขึ้นในลักษณะเดียวกับในกรณีของโปรโตคอลการกำหนดเส้นทางแบบไดนามิก PIMv2 ส่งข้อความ Hello ทุก ๆ 30 วินาทีไปยังที่อยู่มัลติคาสต์ที่สงวนไว้ 224.0.0.13 (All-PIM-Routers) ข้อความประกอบด้วย Hold Timers - โดยปกติจะเท่ากับ 3.5*Hello Timer ซึ่งก็คือ 105 วินาทีตามค่าเริ่มต้น
PIM ใช้โหมดการทำงานหลักสองโหมด - โหมดหนาแน่นและโหมดเบาบาง มาเริ่มกันที่โหมดหนาแน่น
แผนผังการกระจายตามแหล่งที่มา
ขอแนะนำให้ใช้โหมดโหมดหนาแน่นในกรณีที่มีไคลเอนต์จำนวนมากในกลุ่มมัลติคาสต์ที่แตกต่างกัน เมื่อเราเตอร์ได้รับการรับส่งข้อมูลแบบหลายผู้รับ สิ่งแรกที่เราเตอร์ทำคือตรวจสอบกฎ RPF RPF - กฎนี้ใช้เพื่อตรวจสอบแหล่งที่มาของมัลติคาสต์ด้วยตารางเส้นทางแบบผู้รับเดียว จำเป็นที่การรับส่งข้อมูลจะมาถึงอินเทอร์เฟซด้านหลังซึ่งโฮสต์นี้ถูกซ่อนไว้ตามเวอร์ชันของตารางเส้นทางแบบผู้รับเดียว กลไกนี้แก้ปัญหาการวนซ้ำที่เกิดขึ้นระหว่างการส่งข้อมูลแบบหลายผู้รับ
R3 จะจดจำแหล่งมัลติคาสต์ (Source IP) จากข้อความมัลติคาสต์ และตรวจสอบโฟลว์ทั้งสองจาก R1 และ R2 โดยใช้ตารางยูนิคาสต์ สตรีมจากอินเทอร์เฟซที่ตารางชี้ไป (R1 ถึง R3) จะถูกส่งต่อไป และสตรีมจาก R2 จะลดลง เนื่องจากในการที่จะไปยังแหล่งมัลติคาสต์ คุณจะต้องส่งแพ็กเก็ตผ่าน S0/1
คำถามคือ จะเกิดอะไรขึ้นถ้าคุณมีสองเส้นทางที่เทียบเท่ากันและมีเมตริกเดียวกัน ในกรณีนี้ เราเตอร์จะเลือกฮอปถัดไปจากเส้นทางเหล่านี้ ใครก็ตามที่มีที่อยู่ IP สูงกว่าจะเป็นผู้ชนะ หากคุณต้องการเปลี่ยนลักษณะการทำงานนี้ คุณสามารถใช้ ECMP ได้ รายละเอียดเพิ่มเติม .
หลังจากตรวจสอบกฎ RPF แล้ว เราเตอร์จะส่งแพ็กเก็ตแบบหลายผู้รับไปยังเพื่อนบ้าน PIM ทั้งหมด ยกเว้นเพื่อนบ้านที่ได้รับแพ็กเก็ตนั้น เราเตอร์ PIM อื่นๆ ทำซ้ำขั้นตอนนี้ เส้นทางที่แพ็กเก็ตแบบหลายผู้รับนำมาจากต้นทางไปยังผู้รับขั้นสุดท้ายจะสร้างแผนผังที่เรียกว่าแผนผังการแจกจ่ายตามแหล่งที่มา แผนผังเส้นทางที่สั้นที่สุด (SPT) แผนผังต้นทาง สามชื่อที่แตกต่างกัน เลือกชื่อใดชื่อหนึ่ง
วิธีแก้ปัญหาที่เราเตอร์บางตัวไม่ยอมแพ้กับสตรีมมัลติคาสต์บางรายการและไม่มีใครส่งไปให้ แต่เราเตอร์อัปสตรีมส่งมาให้เขา กลไกลูกพรุนถูกประดิษฐ์ขึ้นเพื่อสิ่งนี้
ข้อความพรุน.
ตัวอย่างเช่น R2 จะส่งมัลติคาสต์ไปยัง R3 ต่อไป แม้ว่า R3 ตามกฎ RPF จะปล่อยไว้ก็ตาม ทำไมต้องโหลดช่อง? R3 ส่งข้อความ PIM Prune และ R2 เมื่อได้รับข้อความนี้ จะลบอินเทอร์เฟซ S0/1 ออกจากรายการอินเทอร์เฟซขาออกสำหรับโฟลว์นี้ ซึ่งเป็นรายการอินเทอร์เฟซที่ควรส่งการรับส่งข้อมูลนี้
ต่อไปนี้เป็นคำจำกัดความที่เป็นทางการมากขึ้นของข้อความ PIM Prune:
ข้อความ PIM Prune ถูกส่งโดยเราเตอร์ตัวหนึ่งไปยังเราเตอร์ตัวที่สอง เพื่อให้เราเตอร์ตัวที่สองลบลิงก์ที่ได้รับ Prune จาก SPT เฉพาะ (S,G)
หลังจากได้รับข้อความ Prune แล้ว R2 จะตั้งเวลา Prune เป็น 3 นาที หลังจากผ่านไปสามนาที มันจะเริ่มส่งทราฟฟิกอีกครั้งจนกว่าจะได้รับข้อความ Prune อีกครั้ง นี่คือใน PIMv1
และใน PIMv2 มีการเพิ่มตัวจับเวลาการรีเฟรชสถานะ (60 วินาทีโดยค่าเริ่มต้น) ทันทีที่มีการส่งข้อความ Prune จาก R3 ตัวจับเวลานี้จะเริ่มต้นที่ R3 เมื่อตัวจับเวลานี้หมดอายุ R3 จะส่งข้อความ State Refresh ซึ่งจะรีเซ็ตตัวจับเวลา Prune 3 นาทีบน R2 สำหรับกลุ่มนี้
เหตุผลในการส่งข้อความพรุน:
- เมื่อแพ็กเก็ตมัลติคาสต์ล้มเหลวในการตรวจสอบ RPF
- เมื่อไม่มีไคลเอนต์ที่เชื่อมต่อในพื้นที่ที่ร้องขอกลุ่มมัลติคาสต์ (IGMP เข้าร่วม) และไม่มีเพื่อนบ้าน PIM ที่สามารถส่งทราฟฟิกมัลติคาสต์ไปได้ (อินเทอร์เฟซที่ไม่ใช่พรุน)
ข้อความการรับสินบน
ลองจินตนาการว่า R3 ไม่ต้องการการรับส่งข้อมูลจาก R2 ส่ง Prune และรับมัลติคาสต์จาก R1 แต่ทันใดนั้นช่องระหว่าง R1-R3 ก็ลดลงและ R3 ก็ถูกทิ้งไว้โดยไม่มีมัลติคาสต์ คุณสามารถรอ 3 นาทีจนกว่า Prune Timer บน R2 จะหมดอายุ 3 นาทีถือเป็นการรอที่ยาวนาน ดังนั้นเพื่อไม่ให้รอ คุณต้องส่งข้อความที่จะนำอินเทอร์เฟซ S0/1 นี้ไปยัง R2 ออกจากสถานะถูกตัดทันที ข้อความนี้จะเป็นข้อความการรับสินบน หลังจากได้รับข้อความ Graft แล้ว R2 จะตอบกลับด้วย Graft-ACK
ลูกพรุนแทนที่
ลองดูแผนภาพนี้ R1 ออกอากาศมัลติคาสต์ไปยังเซ็กเมนต์ด้วยเราเตอร์สองตัว R3 รับและออกอากาศการรับส่งข้อมูล R2 ได้รับ แต่ไม่มีผู้ใดถ่ายทอดการรับส่งข้อมูลไป มันจะส่งข้อความ Prune ไปที่ R1 ในส่วนนี้ R1 ควรลบ Fa0/0 ออกจากรายการและหยุดการออกอากาศในส่วนนี้ แต่จะเกิดอะไรขึ้นกับ R3 และ R3 ก็อยู่ใน Segment เดียวกัน ได้รับข้อความนี้จาก Prune และเข้าใจถึงโศกนาฏกรรมของสถานการณ์นี้ด้วย ก่อนที่ R1 จะหยุดออกอากาศ มันจะตั้งเวลาไว้ 3 วินาที และจะหยุดออกอากาศหลังจากผ่านไป 3 วินาที 3 วินาที - นี่คือระยะเวลาที่ R3 มีเพื่อไม่ให้สูญเสียมัลติคาสต์ ดังนั้น R3 จึงส่งข้อความ Pim Join ให้กับกลุ่มนี้โดยเร็วที่สุด และ R1 ไม่คิดจะหยุดออกอากาศอีกต่อไป เกี่ยวกับเข้าร่วมข้อความด้านล่าง
ยืนยันข้อความ
ลองจินตนาการถึงสถานการณ์นี้: เราเตอร์สองตัวออกอากาศไปยังเครือข่ายเดียวพร้อมกัน พวกเขาได้รับสตรีมเดียวกันจากแหล่งที่มา และทั้งสองออกอากาศไปยังเครือข่ายเดียวกันด้านหลังอินเทอร์เฟซ e0 ดังนั้นพวกเขาจึงต้องพิจารณาว่าใครจะเป็นผู้แพร่ภาพกระจายเสียงเพียงรายเดียวสำหรับเครือข่ายนี้ ข้อความยืนยันใช้สำหรับสิ่งนี้ เมื่อ R2 และ R3 ตรวจพบความซ้ำซ้อนของการรับส่งข้อมูลแบบหลายผู้รับ นั่นคือ R2 และ R3 ได้รับมัลติคาสต์ที่ออกอากาศเอง เราเตอร์จะเข้าใจว่ามีบางอย่างผิดปกติที่นี่ ในกรณีนี้เราเตอร์จะส่งข้อความ Assert ซึ่งรวมถึง Administrative Distance และเมตริกเส้นทางที่เข้าถึงแหล่งมัลติคาสต์ - 10.1.1.10 ผู้ชนะจะถูกกำหนดดังนี้:
- อันที่มีค่า AD ต่ำกว่า
- ถ้า AD เท่ากัน แล้วใครมีเมตริกต่ำกว่า
- หากมีความเท่าเทียมกันแสดงว่าผู้ที่มี IP สูงกว่าในเครือข่ายที่พวกเขาออกอากาศมัลติคาสต์นี้
ผู้ชนะการโหวตนี้จะกลายเป็นเราเตอร์ที่กำหนด Pim Hello ยังใช้เพื่อเลือก DR อีกด้วย ในตอนต้นของบทความ ข้อความ PIM Hello ปรากฏขึ้น คุณจะเห็นช่อง DR อยู่ที่นั่น ผู้ที่มีที่อยู่ IP สูงสุดในลิงค์นี้จะเป็นผู้ชนะ
สัญญาณที่เป็นประโยชน์:
โต๊ะ มรูท
หลังจากดูเบื้องต้นว่าโปรโตคอล PIM ทำงานอย่างไร เราจำเป็นต้องเข้าใจวิธีทำงานกับตารางเส้นทางแบบหลายผู้รับ ตาราง mroute เก็บข้อมูลว่าสตรีมใดได้รับการร้องขอจากไคลเอนต์ และสตรีมใดที่ไหลจากเซิร์ฟเวอร์มัลติคาสต์
ตัวอย่างเช่น เมื่อได้รับรายงานการเป็นสมาชิก IGMP หรือ PIM Join บนอินเทอร์เฟซบางส่วน บันทึกประเภท ( *, G ) จะถูกเพิ่มลงในตารางเส้นทาง:
รายการนี้หมายความว่าได้รับคำขอการรับส่งข้อมูลด้วยที่อยู่ 238.38.38.38 ธง DC หมายความว่ามัลติคาสต์จะทำงานในโหมด Dense และ C หมายความว่าผู้รับเชื่อมต่อโดยตรงกับเราเตอร์ นั่นคือเราเตอร์ได้รับรายงานสมาชิก IGMP และ PIM Join
หากมีบันทึกประเภท (S,G) หมายความว่าเรามีสตรีมแบบหลายผู้รับ:
ในฟิลด์ S - 192.168.1.11 เราได้ลงทะเบียนที่อยู่ IP ของแหล่งมัลติคาสต์ซึ่งจะถูกตรวจสอบโดยกฎ RPF หากเกิดปัญหา สิ่งแรกที่คุณต้องทำคือตรวจสอบตารางยูนิคาสต์เพื่อดูเส้นทางไปยังแหล่งที่มา ในฟิลด์อินเทอร์เฟซขาเข้า ระบุอินเทอร์เฟซที่ได้รับมัลติคาสต์ ในตารางเส้นทางแบบผู้รับเดียว เส้นทางไปยังต้นทางต้องอ้างอิงถึงอินเทอร์เฟซที่ระบุที่นี่ อินเทอร์เฟซขาออกระบุตำแหน่งที่มัลติคาสต์จะถูกเปลี่ยนเส้นทาง หากว่างเปล่า แสดงว่าเราเตอร์ยังไม่ได้รับคำขอใดๆ สำหรับการรับส่งข้อมูลนี้ ข้อมูลเพิ่มเติมเกี่ยวกับธงทั้งหมดสามารถพบได้ .
PIM โหมดกระจัดกระจาย
กลยุทธ์ของโหมด Sparse นั้นตรงกันข้ามกับโหมด Dense เมื่อโหมด Sparse ได้รับการรับส่งข้อมูลแบบหลายผู้รับ ระบบจะส่งเฉพาะการรับส่งข้อมูลผ่านอินเทอร์เฟซที่มีการร้องขอสำหรับโฟลว์นี้ เช่น ข้อความ Pim Join หรือ IGMP Report ที่ร้องขอการรับส่งข้อมูลนี้
องค์ประกอบที่คล้ายกันสำหรับ SM และ DM:
- ความสัมพันธ์ในละแวกใกล้เคียงถูกสร้างขึ้นในลักษณะเดียวกับใน PIM DM
- กฎ RPF ใช้งานได้
- การเลือก DR จะคล้ายกัน
- กลไกของ Prune Overrides และ Assert Messages มีความคล้ายคลึงกัน
เพื่อควบคุมว่าใคร ที่ไหน และประเภทของการรับส่งข้อมูลแบบหลายผู้รับที่ต้องการบนเครือข่าย จำเป็นต้องมีศูนย์ข้อมูลทั่วไป ศูนย์กลางของเราคือ Rendezvous Point (RP) ใครก็ตามที่ต้องการการรับส่งข้อมูลแบบหลายผู้รับหรือบางคนเริ่มรับการรับส่งข้อมูลแบบหลายผู้รับจากแหล่งที่มา เขาก็จะส่งไปที่ RP
เมื่อ RP ได้รับการรับส่งข้อมูลแบบหลายผู้รับ RP จะส่งไปยังเราเตอร์ที่เคยร้องขอการรับส่งข้อมูลนี้ก่อนหน้านี้
ลองจินตนาการถึงโทโพโลยีโดยที่ RP คือ R3 ทันทีที่ R1 ได้รับการรับส่งข้อมูลจาก S1 มันจะห่อหุ้มแพ็กเก็ตมัลติคาสต์นี้ไว้ในข้อความ Unicast PIM Register และส่งไปที่ RP เขารู้ได้อย่างไรว่าใครคือ RP? ในกรณีนี้ มีการกำหนดค่าแบบคงที่ และเราจะพูดถึงการกำหนดค่า RP แบบไดนามิกในภายหลัง
ip pim ที่อยู่ rp 3.3.3.3
RP จะดู - มีข้อมูลจากคนที่ต้องการรับการเข้าชมนี้หรือไม่? สมมติว่ามันไม่ใช่ จากนั้น RP จะส่งข้อความ PIM Register-Stop ไปให้ R1 ซึ่งหมายความว่าไม่มีใครต้องการมัลติคาสต์นี้ การลงทะเบียนจะถูกปฏิเสธ R1 จะไม่ส่งมัลติคาสต์ แต่โฮสต์ต้นทางแบบหลายผู้รับจะส่ง ดังนั้น R1 หลังจากได้รับ Register-Stop แล้ว จะเริ่มจับเวลา Register-Suppression เท่ากับ 60 วินาที 5 วินาทีก่อนที่ตัวจับเวลานี้จะหมดเวลา R1 จะส่งข้อความ Register ว่างเปล่าพร้อมบิต Null-Register (นั่นคือ โดยไม่มีแพ็กเก็ตมัลติคาสต์แบบห่อหุ้ม) ไปยัง RP ในทางกลับกัน RP จะทำหน้าที่ดังนี้:
- หากไม่มีผู้รับ ระบบจะตอบกลับด้วยข้อความ Register-Stop
- หากผู้รับปรากฏตัวเขาจะไม่ตอบกลับแต่อย่างใด R1 หากไม่ได้รับการปฏิเสธที่จะลงทะเบียนภายใน 5 วินาที จะยินดีและส่งข้อความลงทะเบียนพร้อมมัลติคาสต์แบบห่อหุ้มไปยัง RP
ดูเหมือนว่าเราจะเข้าใจแล้วว่ามัลติคาสต์เข้าถึง RP ได้อย่างไร ตอนนี้เรามาลองตอบคำถามว่า RP ส่งทราฟฟิกไปยังผู้รับได้อย่างไร จำเป็นต้องแนะนำแนวคิดใหม่ที่นี่ - ต้นไม้เส้นทางราก (RPT) RPT เป็นต้นไม้ที่ฝังรากอยู่ใน RP ซึ่งเติบโตไปสู่ผู้รับ โดยแตกแขนงออกไปบนเราเตอร์ PIM-SM แต่ละตัว RP สร้างขึ้นโดยรับข้อความ PIM Join และเพิ่มสาขาใหม่ให้กับแผนผัง เราเตอร์ดาวน์สตรีมทุกตัวก็ทำเช่นนั้น กฎทั่วไปมีลักษณะดังนี้:
- เมื่อเราเตอร์ PIM-SM ได้รับข้อความ PIM Join บนอินเทอร์เฟซใดๆ นอกเหนือจากอินเทอร์เฟซที่ซ่อน RP ไว้ จะเพิ่มสาขาใหม่ให้กับแผนผัง
- สาขาจะถูกเพิ่มเมื่อเราเตอร์ PIM-SM ได้รับรายงานสมาชิก IGMP จากโฮสต์ที่เชื่อมต่อโดยตรง
สมมติว่าเรามีไคลเอนต์แบบหลายผู้รับบนเราเตอร์ R5 สำหรับกลุ่ม 228.8.8.8 ทันทีที่ R5 ได้รับ IGMP Membership Report จากโฮสต์ R5 จะส่ง PIM Join ไปในทิศทางของ RP และตัวมันเองจะเพิ่มอินเทอร์เฟซให้กับแผนผังที่ดูที่โฮสต์ ถัดไป R4 รับ PIM Join จาก R5 เพิ่มอินเทอร์เฟซ Gi0/1 ให้กับแผนผัง และส่ง PIM Join ไปในทิศทางของ RP ในที่สุด RP ( R3 ) ได้รับ PIM Join และเพิ่ม Gi0/0 ให้กับแผนผัง ดังนั้นผู้รับมัลติคาสต์จึงถูกลงทะเบียน เรากำลังสร้างต้นไม้ด้วยราก R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0
หลังจากนี้ PIM Join จะถูกส่งไปยัง R1 และ R1 จะเริ่มส่งทราฟฟิกแบบหลายผู้รับ สิ่งสำคัญคือต้องทราบว่าหากโฮสต์ร้องขอการรับส่งข้อมูลก่อนที่การออกอากาศแบบหลายผู้รับจะเริ่มขึ้น RP จะไม่ส่ง PIM Join และจะไม่ส่งสิ่งใดไปยัง R1 เลย
หากจู่ๆ ในขณะที่มัลติคาสต์ถูกส่ง โฮสต์จะหยุดต้องการรับมัน ทันทีที่ RP ได้รับ PIM Prune บนอินเทอร์เฟซ Gi0/0 มันจะส่ง PIM Register-Stop โดยตรงไปยัง R1 จากนั้น PIM Prune ข้อความผ่านอินเทอร์เฟซ Gi0/1 PIM Register-stop จะถูกส่งผ่าน unicast ไปยังที่อยู่ที่ PIM Register มา
ดังที่เราได้กล่าวไว้ก่อนหน้านี้ ทันทีที่เราเตอร์ส่ง PIM Join ไปยังอีกเครื่องหนึ่ง เช่น R5 ถึง R4 บันทึกจะถูกเพิ่มใน R4:
และตัวจับเวลาเริ่มต้นขึ้นโดยที่ R5 ต้องรีเซ็ตตัวจับเวลานี้ PIM เข้าร่วมข้อความอย่างต่อเนื่อง มิฉะนั้น R4 จะถูกแยกออกจากรายการขาออก R5 จะส่งข้อความเข้าร่วม PIM ทุก ๆ 60 ข้อความ
การสลับต้นไม้เส้นทางที่สั้นที่สุด
เราจะเพิ่มอินเทอร์เฟซระหว่าง R1 และ R5 และดูว่าการรับส่งข้อมูลด้วยโทโพโลยีนี้เป็นอย่างไร
สมมติว่าการรับส่งข้อมูลถูกส่งและรับตามรูปแบบเก่า R1-R2-R3-R4-R5 และที่นี่เราเชื่อมต่อและกำหนดค่าอินเทอร์เฟซระหว่าง R1 และ R5
ก่อนอื่น เราต้องสร้างตารางเส้นทาง unicast ใหม่บน R5 และตอนนี้เครือข่าย 192.168.1.0/24 เข้าถึงได้ผ่านอินเทอร์เฟซ R5 Gi0/2 ตอนนี้ R5 ซึ่งรับมัลติคาสต์บนอินเทอร์เฟซ Gi0/1 เข้าใจว่ากฎ RPF ไม่เป็นไปตามกฎ และการรับมัลติคาสต์บน Gi0/2 จะสมเหตุสมผลมากกว่า ควรตัดการเชื่อมต่อจาก RPT และสร้างแผนผังที่สั้นกว่าที่เรียกว่า Shortest-Path Tree (SPT) เมื่อต้องการทำเช่นนี้ เขาส่ง PIM Join ไปที่ R0 ถึง Gi2/1 และ R1 เริ่มส่งมัลติคาสต์ผ่าน Gi0/2 เช่นกัน ตอนนี้ R5 จำเป็นต้องยกเลิกการสมัครจาก RPT เพื่อไม่ให้ได้รับสำเนาสองชุด ในการทำเช่นนี้เขาจะส่งข้อความถึง Prune เพื่อระบุที่อยู่ IP ต้นทางและใส่บิตพิเศษ - RPT-bit ซึ่งหมายความว่าคุณไม่จำเป็นต้องส่งการจราจรมาให้ฉัน ฉันมีต้นไม้ที่ดีกว่าที่นี่ RP ยังส่งข้อความ PIM Prune ไปที่ R1 แต่ไม่ได้ส่งข้อความ Register-Stop คุณสมบัติอื่น: R5 จะส่ง PIM Prune ไปยัง RP อย่างต่อเนื่อง เนื่องจาก R1 ยังคงส่ง PIM Register ไปยัง RP ทุกนาที จนกว่าจะไม่มีคนใหม่ที่ต้องการการรับส่งข้อมูลนี้ RP จะปฏิเสธ R5 แจ้ง RP ว่ายังคงรับมัลติคาสต์ผ่าน SPT
ค้นหา RP แบบไดนามิก
ออโต้-RP
เทคโนโลยีนี้เป็นกรรมสิทธิ์ของ Cisco และไม่ได้รับความนิยมมากนัก แต่ยังมีชีวิตอยู่ การดำเนินการ Auto-RP ประกอบด้วยสองขั้นตอนหลัก:
1) RP ส่งข้อความ RP-Announce ไปยังที่อยู่ที่สงวนไว้ - 224.0.1.39 โดยประกาศตัวเอง RP สำหรับทุกคนหรือสำหรับกลุ่มเฉพาะ ข้อความนี้ถูกส่งทุกนาที
2) จำเป็นต้องมีตัวแทนการแมป RP ซึ่งจะส่งข้อความ RP-Discovery เพื่อระบุว่ากลุ่มใดที่ควรรับฟัง RP จากข้อความนี้ที่เราเตอร์ PIM ปกติจะกำหนด RP ด้วยตนเอง Mapping Agent อาจเป็นได้ทั้งเราเตอร์ RP หรือเราเตอร์ PIM ที่แยกต่างหาก RP-Discovery ถูกส่งไปยังที่อยู่ 224.0.1.40 โดยใช้เวลาหนึ่งนาที
มาดูกระบวนการโดยละเอียดเพิ่มเติม:
มากำหนดค่า R3 เป็น RP:
ip pim send-rp-ประกาศลูปแบ็ค 0 ขอบเขต 10
R2 เป็นตัวแทนการแม็ป:
ip pim send-rp-discovery ลูปแบ็ค 0 ขอบเขต 10
และในส่วนอื่นๆ ทั้งหมด เราจะคาดหวัง RP ผ่าน Auto-RP:
ip pim ผู้ฟัง autorp
เมื่อเรากำหนดค่า R3 แล้ว มันจะเริ่มส่ง RP-Announce:
และ R2 หลังจากตั้งค่าเอเจนต์การแมปแล้ว จะเริ่มรอข้อความ RP-Announce เมื่อพบอย่างน้อยหนึ่ง RP เท่านั้นที่จะเริ่มส่ง RP-Discovery:
ด้วยวิธีนี้ ทันทีที่เราเตอร์ทั่วไป (PIM RP Listener) ได้รับข้อความนี้ พวกเขาจะรู้ว่าจะหา RP ได้ที่ไหน
ปัญหาหลักอย่างหนึ่งของ Auto-RP คือเพื่อรับข้อความ RP-Announce และ RP-Discovery คุณต้องส่ง PIM Join ไปยังที่อยู่ 224.0.1.39-40 และเพื่อที่จะส่ง คุณจำเป็นต้องรู้ว่าที่ใด ร.พ.ตั้งอยู่ ปัญหาไก่กับไข่สุดคลาสสิค เพื่อแก้ปัญหานี้ จึงได้คิดค้น PIM Sparse-Dense-Mode หากเราเตอร์ไม่ทราบ RP แสดงว่าเราเตอร์ทำงานในโหมด Dense ถ้าทราบ จะทำงานในโหมด Sparse เมื่อกำหนดค่า PIM Sparse-mode และคำสั่ง ip pim autorp Listener บนอินเทอร์เฟซของเราเตอร์ทั่วไป เราเตอร์จะทำงานในโหมด Dense สำหรับมัลติคาสต์โดยตรงจากโปรโตคอล Auto-RP (224.0.1.39-40) เท่านั้น
เราเตอร์ BootStrap (BSR)
ฟังก์ชั่นนี้ทำงานคล้ายกับ Auto-RP RP แต่ละตัวจะส่งข้อความไปยังเอเจนต์การแมป ซึ่งจะรวบรวมข้อมูลการแมปแล้วแจ้งให้เราเตอร์อื่นๆ ทั้งหมดทราบ เรามาอธิบายกระบวนการคล้ายกับ Auto-RP:
1) เมื่อเรากำหนดค่า R3 เป็นตัวเลือกให้เป็น RP ด้วยคำสั่ง:
ip pim rp-ผู้สมัครย้อนกลับ 0
จากนั้น R3 จะไม่ทำอะไรเลย ในการเริ่มส่งข้อความพิเศษ เขาจำเป็นต้องค้นหาตัวแทนการทำแผนที่ก่อน ดังนั้นเราจึงไปยังขั้นตอนที่สอง
2) กำหนดค่า R2 เป็นตัวแทนการทำแผนที่:
ip pim bsr-ผู้สมัครย้อนกลับ 0
R2 เริ่มส่งข้อความ PIM Bootstrap โดยที่ข้อความระบุว่าตัวเองเป็นตัวแทนการแมป:
ข้อความนี้ถูกส่งไปยังที่อยู่ 224.0.013 ซึ่งโปรโตคอล PIM ยังใช้สำหรับข้อความอื่นๆ ด้วย มันส่งไปทุกทิศทางจึงไม่มีปัญหาไก่กับไข่เหมือนใน Auto-RP
3) ทันทีที่ RP ได้รับข้อความจากเราเตอร์ BSR มันจะส่งข้อความแบบผู้รับเดียวไปยังที่อยู่เราเตอร์ BSR ทันที:
หลังจากนั้น BSR เมื่อได้รับข้อมูลเกี่ยวกับ RP จะส่งผ่านมัลติคาสต์ไปยังที่อยู่ 224.0.0.13 ซึ่งเราเตอร์ PIM ทั้งหมดรับฟัง ดังนั้นแบบอะนาล็อกของคำสั่ง ip pim ผู้ฟัง autorp สำหรับเราเตอร์ทั่วไปที่ไม่ได้อยู่ใน BSR
Anycast RP พร้อมด้วย Multicast Source Discovery Protocol (MSDP)
Auto-RP และ BSR ช่วยให้เราสามารถกระจายโหลดบน RP ได้ดังต่อไปนี้: แต่ละกลุ่ม multicast มี RP ที่ใช้งานอยู่เพียงกลุ่มเดียวเท่านั้น จะไม่สามารถกระจายโหลดสำหรับกลุ่มมัลติคาสต์กลุ่มเดียวผ่านหลาย RP ได้ MSDP ทำได้โดยการออกที่อยู่ IP เดียวกันกับเราเตอร์ RP โดยมีมาสก์ 255.255.255.255 MSDP เรียนรู้ข้อมูลโดยใช้วิธีใดวิธีหนึ่ง: คงที่, Auto-RP หรือ BSR
ในภาพเรามีการกำหนดค่า Auto-RP ด้วย MSDP RP ทั้งสองได้รับการกำหนดค่าด้วยที่อยู่ IP 172.16.1.1/32 บนอินเทอร์เฟซ Loopback 1 และใช้สำหรับทุกกลุ่ม ด้วย RP-Announce เราเตอร์ทั้งสองจะประกาศตัวเองโดยอ้างอิงถึงที่อยู่นี้ เมื่อได้รับข้อมูลแล้ว ตัวแทนการแมป Auto-RP จะส่ง RP-Discovery เกี่ยวกับ RP พร้อมที่อยู่ 172.16.1.1/32 เราบอกเราเตอร์เกี่ยวกับเครือข่าย 172.16.1.1/32 โดยใช้ IGP และตามลำดับ ดังนั้น เราเตอร์ PIM จะร้องขอหรือลงทะเบียนโฟลว์จาก RP ที่ระบุว่าเป็นฮอปถัดไปบนเส้นทางไปยังเครือข่าย 172.16.1.1/32 โปรโตคอล MSDP นั้นได้รับการออกแบบสำหรับ RP เพื่อแลกเปลี่ยนข้อความเกี่ยวกับข้อมูลมัลติคาสต์
พิจารณาโทโพโลยีนี้:
Switch6 ออกอากาศการรับส่งข้อมูลไปยังที่อยู่ 238.38.38.38 และจนถึงตอนนี้มีเพียง RP-R1 เท่านั้นที่รู้เรื่องนี้ Switch7 และ Switch8 ขอกลุ่มนี้ เราเตอร์ R5 และ R4 จะส่ง PIM Join ไปที่ R1 และ R3 ตามลำดับ ทำไม เส้นทางไปยัง 13.13.13.13 สำหรับ R5 จะอ้างอิงถึง R1 โดยใช้ตัววัด IGP เช่นเดียวกับ R4
RP-R1 รู้เกี่ยวกับสตรีมและจะเริ่มออกอากาศไปยัง R5 แต่ R4 ไม่รู้อะไรเลย เนื่องจาก R1 จะไม่เพียงแค่ส่งมันไป ดังนั้น MSDP จึงเป็นสิ่งจำเป็น เรากำหนดค่าบน R1 และ R5:
ip msdp peer 3.3.3.3 เชื่อมต่อแหล่งที่มา Loopback1 บน R1
ip msdp peer 1.1.1.1 เชื่อมต่อแหล่งที่มา Loopback3 บน R3
พวกเขาจะยกเซสชั่นระหว่างกัน และเมื่อได้รับโฟลว์ใดๆ พวกเขาจะรายงานให้เพื่อนบ้าน RP ทราบ
ทันทีที่ RP-R1 ได้รับสตรีมจาก Switch6 มันจะส่งข้อความ MSDP Source-Active แบบผู้รับเดียวทันที ซึ่งจะมีข้อมูลเช่น (S, G) - ข้อมูลเกี่ยวกับต้นทางและปลายทางของมัลติคาสต์ ตอนนี้ RP-R3 รู้แล้วว่าแหล่งที่มา เช่น Switch6 เมื่อได้รับคำขอจาก R4 สำหรับโฟลว์นี้ จะส่ง PIM Join ไปยัง Switch6 ตามคำแนะนำของตารางเส้นทาง ดังนั้น R1 เมื่อได้รับ PIM Join ดังกล่าวจะเริ่มส่งการรับส่งข้อมูลไปยัง RP-R3
MSDP ทำงานบน TCP, RP ส่งข้อความ Keepalive ซึ่งกันและกันเพื่อตรวจสอบความมีชีวิตชีวา ตัวจับเวลาคือ 60 วินาที
ฟังก์ชันการแบ่งเพียร์ MSDP ออกเป็นโดเมนต่างๆ ยังคงไม่ชัดเจน เนื่องจากข้อความ Keepalive และ SA ไม่ได้ระบุถึงความเป็นสมาชิกในโดเมนใดๆ นอกจากนี้ ในโทโพโลยีนี้ เราได้ทดสอบการกำหนดค่าที่ระบุโดเมนที่แตกต่างกัน - ประสิทธิภาพไม่แตกต่างกัน
หากใครสามารถชี้แจงได้ฉันก็ยินดีที่จะอ่านในความคิดเห็น
ที่มา: will.com