PIM-SM ข้าม VPN: ตรวจสอบ BSR, การแมป RP และเส้นทาง RPF

อุโมงค์ทำงานอยู่ ping แบบยูนิคาสต์ผ่านได้ แต่ผู้รับยังแสดงหน้าจอดำ ในระบบ PIM-SM อาการนี้เกือบทุกครั้งหมายความว่าหนึ่งในสี่เส้นทางควบคุมเสีย และเส้นทางข้อมูลไม่เคยเป็นปัญหา ไล่รายการด้านล่างตามลำดับและหยุดที่ขั้นตอนแรกที่ล้มเหลว เพราะทุกขั้นถัดไปขึ้นกับขั้นก่อนหน้า ผมเก็บการตรวจสอบทั้งห้านี้ไว้ในไฟล์ร่างและวางลงในเทอร์มินัลเมื่อมีข้อร้องเรียนเรื่องมัลติคาสต์ ซึ่งทำให้การวินิจฉัยไม่กลายเป็นการเดา

เริ่มจากผู้รับ ไม่ใช่จากอุโมงค์

ผู้รับที่ไม่เคยขอเข้าร่วมกลุ่มจะไม่สร้างสถานะใดบนเราเทอร์ใด ๆ ดังนั้นก่อนตรวจสิ่งอื่นใด ให้ยืนยันว่าการเข้าร่วมมีอยู่บนเซกเมนต์ฝั่งผู้รับ บนแพลตฟอร์มสไตล์ Cisco คำสั่ง show ip igmp groups บนเราเทอร์ฮอปสุดท้ายจะพิมพ์กลุ่มที่เข้าร่วมไว้ข้างอินเทอร์เฟซที่ได้ยินกลุ่มนั้น เมื่อไม่มีกลุ่มในผลลัพธ์นั้น อุโมงค์ก็เป็นเพียงสิ่งเบี่ยงเบนความสนใจ คำขอตายที่สวิตช์เข้าถึง ที่ซ็อกเก็ตของโฮสต์ หรือใน VLAN ที่ไม่มี querier

สาเหตุธรรมดาสองข้ออธิบายการเข้าร่วมที่หายไปส่วนใหญ่ที่ผมพบ คือความไม่ตรงกันของเวอร์ชัน IGMP ระหว่างโฮสต์กับเราเทอร์ และการเลือก querier ที่ไปลงบนสวิตช์ซึ่งไม่ทำเราเตอร์ริ่ง ข้อที่สามละเอียดกว่า คือกลุ่มเข้าร่วมแล้วแต่อยู่ใน VLAN ผิด เพราะโฮสต์มีการ์ดเครือข่ายสองใบและแอปพลิเคชันผูกกับใบที่ผิด ผู้รับ IPv6 มีปัญหาเดียวกันกับ MLD ซึ่ง show ipv6 mld groups ตอบคำถามเดียวกัน ไม่มีข้อใดแก้ได้ด้วยการแตะอุโมงค์ และนั่นคือเหตุผลที่ลำดับสำคัญ

เมื่อเห็นการเข้าร่วมแล้ว ให้ยืนยันว่า PIM เปิดอยู่ทั้งบนอินเทอร์เฟซฝั่งผู้รับและบนอินเทอร์เฟซที่มุ่งไปยังจุดนัดพบ เราเทอร์ที่มีสมาชิกภาพ IGMP แต่ไม่มี PIM บนอินเทอร์เฟซต้นน้ำจะเก็บกลุ่มไว้ในตารางท้องถิ่นและไม่ส่งอะไรไปที่ใดเลย

ชุด BSR ไปถึงอีกฝั่งหรือไม่

ข้อความ Bootstrap Router เคลื่อนที่ทีละฮอปภายในโดเมน PIM เดียว และนั่นคือทิศทางที่แตกเมื่อข้ามอุโมงค์ RP ที่เป็นผู้สมัครส่งประกาศของตนไปยัง BSR ที่ได้รับเลือกผ่านยูนิคาสต์ ส่วน RP ถึง BSR จึงมักอยู่รอดโดยไม่เปลี่ยนในอุโมงค์ที่ทำงานได้ การท่วมของข้อความ Bootstrap ในอีกทิศทางขึ้นอยู่กับว่าทุกอินเทอร์เฟซกลางเปิด PIM และไม่มีอะไรหยุดข้อความที่ขอบเขต RFC 5059 กำหนดการกระจายนั้นและขอบเขตการบริหารที่ได้รับอนุญาตให้ตัดทอนมัน

คำสั่ง ip pim bsr-border, ACL ที่กรองโปรโตคอล 103 หรืออุโมงค์ IPsec แบบอิงนโยบายที่ไม่สามารถบรรทุกมัลติคาสต์ แต่ละอย่างจะตัดการท่วมนั้นโดยยูนิคาสต์ยังคงสมบูรณ์ การผสมกันนี้นี่เองที่ทำให้ความล้มเหลวดูเหมือนปัญหา RP ทั้งที่จริงเป็นปัญหาการเข้าถึง และนั่นคือเหตุผลที่ผมอ่านสถานะ BSR ก่อนอ่านการกำหนดค่า RP

บนเราเทอร์ฝั่งไกล คำสั่ง show ip pim bsr-router ระบุ BSR ที่ได้รับเลือกและชุด RP ที่เรียนรู้มา หากผลลัพธ์ว่างเปล่า ฝั่งไกลก็อยู่ในโดเมนของตัวเองและการกำหนดค่า RP ใดก็ไม่ทำให้สองฝั่งตรงกัน เปรียบเทียบช่วงกลุ่มและที่อยู่ RP ใน show ip pim rp mapping ทั้งสองฝั่งของอุโมงค์ การแมปที่มีอยู่เพียงท้องถิ่นจะสร้างทรีร่วมที่สิ้นสุดในที่ผิด และผู้รับรอตลอดไป

ทำให้การแมป RP ตรงกันทั้งสองฝั่งของอุโมงค์

RP แบบสแตติก, BSR และ anycast-RP เป็นสามวิธีตอบคำถามเดียวกัน และการผสมกันข้ามอุโมงค์เป็นวิธีที่เชื่อถือได้ในการสร้างโดเมนที่ไม่เคยลู่เข้า หากฝั่งหัวใช้ BSR และสาขาใช้ ip pim rp-address แบบสแตติกที่ชี้ไปยังที่อยู่อื่น สาขาจะสร้างทรีร่วมของตนไปยัง RP ที่ไม่รู้ว่าผู้รับมีอยู่ การแมปต้องตรงกันทั้งช่วงกลุ่มและที่อยู่ เพราะช่วงที่เฉพาะเจาะจงกว่าชนะช่วงที่กว้างกว่า

anycast-RP มีอยู่เพื่อให้สองไซต์ใช้ที่อยู่ RP เดียวกันร่วมกัน และควรกล่าวถึงตรงนี้เพราะมันเปลี่ยนความหมายของ «RP เดียวกัน» RP สองตัวที่ประกาศที่อยู่เดียวมีความสอดคล้องโดยการออกแบบ ส่วน RP สองตัวที่ประกาศคนละที่อยู่สำหรับช่วงเดียวกันไม่เป็นเช่นนั้น ไม่ว่าแต่ละไซต์จะดูแข็งแรงเพียงใดเมื่ออยู่ลำพัง

สำหรับมัลติคาสต์เฉพาะต้นทางภายใน 232.0.0.0/8 จะไม่มีการสอบถาม RP เลย ดังนั้นการแมป RP ที่ว่างเปล่าไม่ใช่ความผิดพลาดโดยอัตโนมัติ ตัดสินว่าแอปพลิเคชันใช้รูปแบบบริการใดก่อนไล่ตาม RP ที่ไม่เคยจำเป็น

อ่านการค้นหา RPF ไปยังต้นทาง

PIM สร้างทรีโดยกลับเส้นทางยูนิคาสต์ ดังนั้นการตรวจที่สำคัญคือเส้นทางกลับไปยังต้นทาง หรือกลับไปยัง RP สำหรับทรีร่วม การเข้าร่วมที่มาถึงอินเทอร์เฟซที่เราเทอร์ไม่ถือว่าเป็นต้นน้ำจะถูกทิ้ง และเหตุผลถูกบันทึกเป็นความล้มเหลวของ RPF ไม่ใช่ความล้มเหลวของอุโมงค์ บนเราเทอร์สาขาที่มีเส้นทางเริ่มต้นผ่านอุโมงค์และเส้นทางที่เฉพาะเจาะจงกว่าผ่าน WAN อินเทอร์เฟซ RPF อาจเป็น WAN ได้ง่ายแม้ต้นทางเข้าถึงได้ทางอุโมงค์เท่านั้น นี่คือสาเหตุเดียวที่พบบ่อยที่สุดที่การเข้าร่วมถูกทิ้งอย่างเงียบ ๆ

show ip rpf 192.0.2.10 พิมพ์อินเทอร์เฟซที่เลือก ฮอปถัดไป และเส้นทางที่สร้างการตัดสินใจ ซึ่งมักเพียงพอที่จะเห็นความไม่ตรงกัน เส้นทางมัลติคาสต์แบบสแตติกอย่าง ip mroute 192.0.2.0 255.255.255.0 tunnel0 จะข้ามการค้นหายูนิคาสต์สำหรับคำนำหน้านั้น และเป็นการแก้ที่ชอบด้วยเหตุผลเมื่อโทโพโลจีมัลติคาสต์ต่างจากโทโพโลจียูนิคาสต์จริง ๆ มองมันเป็นการกำหนดค่าที่ต้องจัดทำเอกสาร ไม่ใช่แพตช์ที่ใส่ระหว่างเหตุการณ์แล้วลืม

ยืนยันการเข้าร่วมด้วยคำสั่ง ไม่ใช่ด้วย ping

ping พิสูจน์ว่ายูนิคาสต์ทำงาน ซึ่งคุณรู้อยู่แล้ว การยืนยันจากต้นทางถึงปลายทางคือลำดับที่แสดงการเข้าร่วม การแมป เพื่อนบ้าน และทรีตามลำดับนั้น และแต่ละคำสั่งตอบคำถามต่างกัน

show ip igmp groups 239.1.1.1
show ip pim rp mapping
show ip pim neighbor
show ip rpf 192.0.2.10
show ip mroute 239.1.1.1

รายการ (S,G) ที่เต็มพร้อมอินเทอร์เฟซขาเข้าจริงและรายการขาออกที่ไม่ว่าง หมายความว่าระนาบควบคุมทำงานเสร็จแล้ว รายการที่อินเทอร์เฟซขาเข้าอ่านเป็น Null หรือเคาน์เตอร์ที่ติดป้าย RPF failed ซึ่งเพิ่มขึ้นเรื่อย ๆ ชี้กลับไปยังส่วนก่อนหน้า ไม่ใช่ไปยังอุโมงค์

หากคำสั่งทั้งห้าดูถูกต้องแต่ผู้รับยังไม่เห็นอะไร ผู้ต้องสงสัยที่เหลือคือนโยบายของอุโมงค์เอง: ACL การเข้ารหัสหรือกฎไฟร์วอลล์ที่อนุญาตโปรโตคอลเราเตอร์ริ่งยูนิคาสต์แต่ไม่อนุญาต PIM, IGMP หรือทราฟฟิกของกลุ่มเอง บนอุโมงค์ IPsec แบบอิงนโยบาย มัลติคาสต์ไม่ถูกบรรทุกเลย คำตอบจึงเป็นการออกแบบ GRE หรือ VTI ไม่ใช่ข้อยกเว้นของฟิลเตอร์อีกข้อ จดว่าการตรวจข้อใดในห้าข้อล้มเหลวก่อนเปลี่ยนอะไร แล้วเปลี่ยนเฉพาะชั้นนั้น