IPv6 ใน MPLS VPN: สามทางเลือก ไม่ใช่ตระกูลที่อยู่เดียว
เส้นทาง VPN ของลูกค้า เซสชัน BGP ระหว่าง PE และการขนส่งในคอร์เป็นการตัดสินใจแยกกัน เซสชันหนึ่งทำงานในตระกูลที่อยู่หนึ่งและบรรทุกอีกตระกูลหนึ่งได้
ถ้าคุณพูดในที่ประชุมทบทวนการออกแบบว่า “รัน IPv6 L3VPN บน IPv6 BGP” ในประโยคเดียวนั้นมีการตัดสินใจแยกกันสามเรื่องซ่อนอยู่ เรื่องแรกคือพรีฟิกซ์ใดเป็นของ VPN ของลูกค้า เรื่องที่สองคือที่อยู่ใดบรรทุกเซสชันการจัดเส้นทางระหว่างขอบของผู้ให้บริการ และเรื่องที่สามคือคอร์ใดเคลื่อนย้ายแพ็กเก็ตที่มีป้ายกำกับ ทั้งสามเป็นทางเลือกที่เป็นอิสระต่อกัน ทั้งหมดเป็น IPv6 ได้ ผสมกันได้ และการผสมก็ได้รับอนุญาตโดยเจตนา การแยกสามเรื่องนี้ออกจากกันคือสิ่งที่เปลี่ยนข้อกำหนดที่คลุมเครือให้เป็นสิ่งที่ทดสอบแพลตฟอร์มได้
แยกสามงานออกจากกัน
งานแรกคือเส้นทางของลูกค้า ได้แก่พรีฟิกซ์ IPv6 ที่เป็นของบริบทการจัดเส้นทาง VPN หนึ่งบริบท และต้องอยู่นอกทุกบริบทอื่น งานที่สองคือการเชื่อมต่อการจัดเส้นทางระหว่างเราเตอร์ขอบของผู้ให้บริการที่แลกเปลี่ยนพรีฟิกซ์เหล่านั้น งานที่สามคือการขนส่งที่พาแพ็กเก็ตลูกค้าที่มีป้ายกำกับผ่านคอร์ไปยังขอบปลายทาง การระบุเพียงหนึ่งในสามยังไม่ถือเป็นการออกแบบ
| Job | The question it answers | What confusion looks like |
|---|---|---|
| Customer VPN routes | Which IPv6 prefixes belong to each VPN context, and how are they kept apart? | Prefixes leak into the global table and between customers |
| PE-to-PE BGP session | Which addresses carry the routing connection between the two edges? | A session-family mismatch gets chased as a core transport fault |
| Transport to the remote PE | How does the chosen core move the labelled packet to the far edge? | A route is present and unforwardable in the same moment |
แต่ละงานมีตระกูลที่อยู่ของตัวเอง มีรูปแบบความล้มเหลวของตัวเอง และมักมีทีมของตัวเอง ตารางนี้มีประโยชน์ก็เพราะประโยคเดียวในเอกสารออกแบบมักบีบทั้งสามแถวให้เหลือแถวเดียว
ตระกูลของเส้นทางคือ VPN-IPv6 ไม่ใช่ IPv6 unicast
RFC 4659 กำหนดตระกูล BGP/MPLS IPv6 VPN และการเป็นสมาชิกนั้นเจาะจงกว่าที่คำว่า IPv6 บอกเป็นนัย เส้นทางที่นั่นคือตัวแยกเส้นทางที่ผูกกับพรีฟิกซ์ IPv6 และเข้ารหัสภายใต้ AFI 2 และ SAFI 128 ส่วน IPv6 unicast ทั่วไปเป็นอีกตระกูลหนึ่ง ดังนั้นประกาศที่ดูเหมือนพรีฟิกซ์ใน looking glass อาจไม่ใช่วัตถุเดียวกันเลย การอ่านตระกูลผิดคือทางแรกที่การออกแบบนี้ไปผิดทาง
ความแตกต่างกัดที่ขอบ ซึ่งเส้นทางต้องลงไปในบริบท VPN ที่ถูกต้องก่อนจะทำอะไรได้ การได้รับพรีฟิกซ์พิสูจน์ว่าเกิดการแลกเปลี่ยนแล้ว และไม่ได้บอกอะไรเกี่ยวกับการติดตั้ง ช่องว่างนั้นทำให้เกิดรายงานคลาสสิกที่เซสชันขึ้นแล้วแต่ลูกค้ายังมืดอยู่
เซสชันสามารถทำงานในตระกูลอื่นที่ไม่ใช่ VPN ได้
ไม่มีอะไรบังคับให้การเชื่อมต่อ BGP ระหว่างสองขอบใช้ตระกูลของ VPN เอง ข้อกำหนดอนุญาตให้ใช้เซสชัน IPv4 หรือ IPv6 และการขนส่ง IPv6 VPN เองก็ถูกกำหนดบนคอร์ทั้งสองชนิด ดังนั้นเซสชัน IPv6 จึงไม่บอกอะไรเกี่ยวกับตระกูลของสิ่งที่มันบรรทุก และไม่ได้เลือก data plane ด้วย สามบิตที่เป็นอิสระ และการออกแบบควรถือทั้งสามแยกกัน
เรื่องนี้ให้อิสระและในเวลาเดียวกันก็อ่านผิดได้ง่าย เส้นทางลูกค้า IPv6 สามารถวิ่งบนเซสชันที่ใช้ที่อยู่ IPv4 และเส้นทาง IPv4 ก็วิ่งบนเซสชัน IPv6 ได้ หากแพลตฟอร์มรองรับการผสมนั้นและฮอปถัดไปแก้ได้ สิ่งที่ไม่ควรเกิดขึ้นคือปล่อยให้เซสชันบอกเป็นนัยถึงเพย์โหลด ไม่ว่าในเอกสารออกแบบหรือในการเฝ้าระวังที่พิสูจน์บริการในภายหลัง
ฮอปถัดไปบนคอร์ IPv4 มีการเข้ารหัสของตัวเอง
เมื่อคอร์ใต้ VPN เป็น IPv4 เส้นทางจะไม่ปรากฏพร้อมฮอปถัดไปที่ขอบขาเข้าสามารถใช้ได้โดยตรง มันมาในรูปแบบ IPv6 ที่แมปกับ IPv4 และนั่นคือวิธีที่ข้อกำหนดแสดงขอบขาออกเมื่อการขนส่งข้างใต้เป็น IPv4 จากนั้นเราเตอร์ขาเข้าต้องเปลี่ยนที่อยู่ที่แมปนั้นให้เป็นสิ่งที่เข้าถึงได้จริงผ่านคอร์ และการแก้ที่อยู่คือขั้นตอนที่ล้มเหลวอย่างเงียบ ๆ
อ่านเรื่องนี้เป็นความขึ้นต่อกันของการส่งต่อ ไม่ใช่สตริงให้คัดลอกระหว่างอุปกรณ์ ตรวจสอบสามอย่างบนแพลตฟอร์มที่คุณดูแลจริง ฮอปถัดไปที่ประกาศแก้ไปเป็นเส้นทางที่ใช้งานได้ สแตกป้ายกำกับได้รับการยอมรับ และปลายทางลงในบริบท VPN ที่ตั้งใจ หากข้อใดข้อหนึ่งล้มเหลวจะเหลือเซสชันที่ดูปกติแต่ไม่ส่งต่ออะไรเลย เพราะการตรวจนี้จึงอยู่ในรอบการยอมรับ ไม่ใช่ในเหตุการณ์ภายหลัง
เขียนข้อกำหนดเป็นสี่บรรทัด
ข้อกำหนดที่ควรค่าแก่การทดสอบระบุสี่อย่าง ตระกูลของ VPN การขนส่งของเซสชัน การเข้ารหัสฮอปถัดไป และการจัดวางคอร์ จากนั้นระบุพรีฟิกซ์ลูกค้าหนึ่งรายการให้ติดตามตั้งแต่ต้นจนจบ ผ่านการแลกเปลี่ยน การติดตั้ง การแก้ป้ายกำกับ และเส้นทางขากลับ “รองรับ IPv6 BGP” ไม่ครอบคลุมทั้งสี่ข้อและซ่อนไว้ว่าความไม่สอดคล้องอยู่ที่ใดจริง ๆ
เซสชันที่ปกติแต่ไม่มีการแลกเปลี่ยน VPN-IPv6 นั้นไม่สมบูรณ์ และเส้นทาง VPN ที่ได้รับมาโดยไม่มีการส่งต่อที่ทำงานได้ก็ไม่สมบูรณ์เช่นกัน การเก็บสองข้อนี้เป็นบรรทัดการยอมรับแยกกันทำให้บทสนทนาแก้ปัญหาในครั้งหน้าสั้นลง เพราะบรรทัดที่ล้มเหลวถูกเขียนไว้แล้ว