เซสชัน BGP ขึ้นแล้ว แต่เส้นทางลูกค้าขาด: MPLS บน DMVPN

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

ช่องว่างนี้เห็นได้ชัดที่สุดในการออกแบบ MPLS บน DMVPN ซึ่งเส้นทางผ่านฮับกับเส้นทางตรงผ่านสโปคอาจทำงานต่างกันด้วยเหตุผลที่ไม่เกี่ยวกับการเพียร์ริ่งเลย

เซสชันพิสูจน์อะไรจริง ๆ

BGP ทำงานบน TCP ดังนั้นแต่ละ peer ต้องมีเส้นทางไปยังที่อยู่ปลายอีกด้านก่อนที่สิ่งอื่นจะเกิดขึ้นได้ หากเลือก loopback เป็นปลายทางนั้น คุณได้สร้างข้อกำหนดเรื่องการเข้าถึง ไม่ใช่การรับประกันการส่งต่อ เซสชันจึงอาจคงอยู่ผ่านอินเทอร์เฟซที่ทราฟฟิกของลูกค้าไม่มีวันใช้

บันทึกข้อเท็จจริงสี่ประการที่ทั้งสองด้านก่อนสรุป: ที่อยู่ต้นทางของเซสชัน ที่อยู่ปลายทาง บริบทการกำหนดเส้นทางที่มันอยู่ และอินเทอร์เฟซที่เคอร์เนลหรือเราเตอร์จะเลือกสำหรับคู่นั้น ข้อเท็จจริงเหล่านี้บรรยายระนาบควบคุม แพ็กเก็ตของลูกค้าเพิ่ม VRF, สแต็กป้ายกำกับ และการแมป overlay เข้าไปด้านบน

สี่กลไก ไม่ใช่หนึ่ง

เอกสารของ Cisco เกี่ยวกับ MPLS บน DMVPN แยกส่วนประกอบออกจากกันอย่างชัดเจน MP-BGP กระจายป้ายกำกับ overlay ของลูกค้าระหว่างอุปกรณ์ที่ขอบของผู้ให้บริการ MPLS ใช้ป้ายกำกับเหล่านั้นเพื่อเลือกบริบทการส่งต่อของแพ็กเก็ต NHRP แมปที่อยู่ overlay ไปยังปลายทางขนส่งที่ทันเนลแบบไดนามิกต้องการ IPsec ปกป้องเส้นทาง peer ในจุดที่เกี่ยวข้อง

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

เปรียบเทียบเส้นทางผ่านฮับกับทางลัด ทีละตัวแปร

ตรึงโฮสต์ต้นทาง โฮสต์ปลายทาง และ VRF แล้วติดตามโฟลว์เดียวกันสองครั้ง บนเส้นทางผ่านฮับ บันทึกฮอปถัดไป ป้ายกำกับบริการที่ระบุบริบทลูกค้าปลายทางไกล และการแมป overlay ไปยังการขนส่งที่ใช้อยู่ บนเส้นทางตรงที่ตั้งใจไว้ บันทึกสามอย่างเดียวกัน ความต่างระหว่างสองรายการคือความผิดพลาด หรือการไม่มีอยู่ของมัน

รักษาโฟลว์ให้คงที่ระหว่างการเปรียบเทียบ การเปลี่ยนโฮสต์ต้นทาง VRF หรือปลายทางระหว่างการสังเกตทำให้ได้สองเรื่องที่ไม่สัมพันธ์กัน และนี่คือวิธีที่ทำให้แบบฝึกหัดนี้ผิดพลาดบ่อยที่สุด

เก็บการทดสอบ loopback ไว้ในช่องของมันเอง

ping ที่ส่งจาก loopback ของเราเตอร์เป็นการทดสอบที่มีประโยชน์ และฝึกกรณีที่ต่างจากโฟลว์จากโฮสต์ ที่อยู่ต้นทางเป็นของเราเตอร์ บริบทการกำหนดเส้นทางอาจเป็นแบบทั่วโลกแทน VRF และเส้นทางตอบกลับอาจต่างจากที่พรีฟิกซ์ของลูกค้าจะใช้ ดังนั้น loopback ที่ตอบสนองกับแอปพลิเคชันที่ทำงานผ่านทางลัดจึงเป็นผลลัพธ์แยกกัน และมีเพียงอย่างที่สองเท่านั้นที่อธิบายลูกค้า

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

ข้อกล่าวอ้างเรื่องเวอร์ชันและเรื่องข้อบกพร่องต้องมีหลักฐานของตัวเอง

รายงานภาคสนามบางครั้งแนะนำให้เปลี่ยนมาสก์โฮสต์หรือที่อยู่ต้นทางของ BGP และรายงานเช่นนั้นควรอ่านควบกับข้อบกพร่องที่เขียนถึงและเวอร์ชันที่ได้รับผลกระทบเท่านั้น วิธีเลี่ยงจากเวอร์ชันหนึ่งไม่ใช่คำกล่าวอ้างว่าสถาปัตยกรรมไม่รองรับพรีฟิกซ์ /32 ใด ๆ

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