จาก VXLAN สู่ MPLS IP VPN: VNI ไม่ใช่ป้ายกำกับ MPLS

ทั้งสองเทคโนโลยีวางตัวระบุไว้หน้าของแพ็กเก็ต คำตอบจึงดูเหมือนชัดเจน คือ แมป VNI ไปยังป้ายกำกับ MPLS แล้วให้ทั้งสองเครือข่ายเชื่อมกัน แต่การแมปนั้นไม่มีอยู่จริงในฐานะการดำเนินการที่รองรับ เพราะตัวระบุทั้งสองหมายถึงสิ่งแตกต่างกัน และถูกสร้างโดยระนาบควบคุมที่แตกต่างกัน VNI ระบุเซกเมนต์ VXLAN ภายในโอเวอร์เลย์ ส่วนป้ายกำกับ MPLS ระบุการจัดการส่งต่อตามเส้นทางที่สลับด้วยป้ายกำกับ การเชื่อมโดเมนเข้าด้วยกันเป็นการตัดสินใจด้านการกำหนดเส้นทาง ไม่ใช่การแปลตัวเลข

ความเชื่อที่ผิด: ทั้งสองใช้ป้ายกำกับ จึงแมปกันได้

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

สิ่งที่ทำลายแนวคิดนี้คือทุกอย่างที่อยู่รอบตัวค่า VNI ถูกแปลงโดยระนาบควบคุม EVPN และปลายทางอุโมงค์ในชั้นล่าง ป้ายกำกับถูกกำหนดโดยระนาบการส่งต่อ MPLS ตามเส้นทาง ทั้งสองฝ่ายไม่มีขั้นตอนที่กำหนดไว้สำหรับรับตัวระบุของอีกฝ่ายมาเป็นของตน

แต่ละฝ่ายส่งต่ออะไรจริง ๆ

ฝั่งแฟบริก อุปกรณ์ชายขอบสิ้นสุดอุโมงค์ VXLAN แมป VNI ไปยัง VRF ของผู้เช่า และกำหนดเส้นทางแพ็กเก็ตเป็น IP ปกติ ฝั่งผู้ให้บริการ PE รับเส้นทางของลูกค้าเข้าสู่ VRF ใส่ชั้นป้ายกำกับ MPLS แล้วส่งต่อผ่าน IP VPN

การส่งต่อนั้นคือรูปแบบที่เข้าใจกันดีใน RFC 4364: ขอบฝั่งลูกค้าแลกเปลี่ยนเส้นทาง IP กับขอบฝั่งผู้ให้บริการ และแต่ละโดเมนเป็นเจ้าของการห่อหุ้มของตนเอง VNI หายไปแล้วเมื่อแพ็กเก็ตไปถึง PE นั่นคือเหตุผลที่รูปแบบนี้ทำงานได้

เหตุใดระนาบควบคุมจึงไม่หลอมรวม

EVPN Type 5 บรรทุกเส้นทางพรีฟิกซ์ IP พร้อมฮอปถัดไปแบบโอเวอร์เลย์ ขณะที่ประกาศ VPN-IPv4 อยู่ในตระกูลแอดเดรสอีกตระกูลหนึ่ง เป้าหมายเส้นทางที่ดูเหมือนกันทั้งสองฝ่ายไม่ได้แปลตระกูลหนึ่งเป็นอีกตระกูล และไม่ได้แก้ฮอปถัดไปข้ามขอบ

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

สมมติฐานอีกสองข้อล้มเหลวที่ขอบนี้ MPLS IP VPN ให้การเข้าถึงแบบกำหนดเส้นทาง ไม่ใช่เซกเมนต์ Ethernet การขยายบรอดแคสต์จึงต้องใช้ บริการเลเยอร์ 2 ที่รองรับแทน และการห่อหุ้มทั้งสองกินไบต์ ทำให้ MTU ที่ใช้งานได้จริงเล็กกว่าที่ชั้นล่างใด ๆ บอกไว้

เลือกการส่งต่อแบบกำหนดเส้นทางหรือเกตเวย์แบบรวม

เลือกการส่งต่อแบบกำหนดเส้นทางเมื่อผู้เช่าต้องการการเข้าถึง IP และผู้ให้บริการมีบริการที่หันหน้าไปทาง CE อยู่แล้ว วิธีนี้รักษาความเป็นเจ้าของให้ชัดเจน แฟบริกเป็นเจ้าของ VXLAN และ EVPN ผู้ให้บริการเป็นเจ้าของ MPLS และ VPN และขอบเป็นเจ้าของการแมป VRF ไปยังอินเทอร์เฟซ วางแผนขนาดการเชื่อมต่อ การกำหนดแอดเดรส และการสลับเมื่อขัดข้องร่วมกับผู้ให้บริการ แทนที่จะถือว่าลิงก์เดียวเพียงพอ

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

สิ่งที่ต้องบันทึกต่อผู้เช่า

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

บันทึกนั้นคือสิ่งที่เชื่อมสองโดเมนบริหารโดยไม่แกล้งทำว่าสมมติฐานด้านการกำหนดเส้นทางและการห่อหุ้มของทั้งสองเหมือนกัน เมื่อมีคนถามภายหลังว่า VNI เปลี่ยนเป็นป้ายกำกับได้หรือไม่ เอกสารจะตอบด้วยการออกแบบ ไม่ใช่การโต้แย้ง