ใช้ /24 เดียวกันสำหรับสองลูกค้า? VPNv4 ต้องมี RD และเลเบล
ผู้เช่าสองรายประกาศ /24 เดียวกันได้ก็เพราะ RD ให้แต่ละเส้นทางมีตัวตนของตัวเอง เลเบลตอบคำถามอีกข้อ: จะส่งต่ออย่างไร
ผู้เช่าสองรายกำหนดเลขให้สาขาของตนด้วย 10.50.0.0/24 เดียวกัน และหลังการเปลี่ยนแปลงเส้นทางของผู้เช่ารายหนึ่งหายไปจากขอบของผู้ให้บริการ ขณะที่อีกรายยังทำงานอยู่ การทำให้ง่ายขึ้นเบื้องหลังตั๋วนั้นมักเป็นการตัดตัวแยกเส้นทาง (RD) ออก เพราะ «เลเบลระบุตัวลูกค้าแล้ว» ซึ่งไม่จริง RD และเลเบลตอบคำถามที่แตกต่างกันสองข้อ และช่องว่างนี้จะมองเห็นได้ก็ต่อเมื่อที่อยู่ที่ทับซ้อนกันบังคับให้เป็นเช่นนั้น
เส้นทางเดียวในที่ที่ควรมีสอง
IPv4 ยูนิแคสต์ทั่วไปเปรียบเทียบสองเส้นทางไปยังคำนำหน้าเดียวกันและติดตั้งเส้นทางที่ดีกว่า 10.50.0.0/24 จากผู้เช่า A และ 10.50.0.0/24 จากผู้เช่า B เป็นกุญแจเดียว ดังนั้นเส้นหนึ่งชนะและอีกเส้นอยู่รอดเพียงเป็นเส้นทางสำรอง โปรโตคอลทำตามที่ถูกสั่ง ระนาบควบคุมถูกขอให้เก็บเส้นทางที่แตกต่างกันสองเส้นทางภายใต้ตัวระบุเดียว
ผลลัพธ์ดูเหมือนเส้นทางที่หายไปมากกว่าข้อผิดพลาด PE ที่แพ้การแข่งขันยังส่งต่อผู้เช่าของตนในเครื่อง จึงทำให้การทดสอบภายในไซต์สำเร็จและการทดสอบระหว่างไซต์ล้มเหลว ก่อนแตะนโยบายใด ๆ ให้นับรายการสำหรับคำนำหน้านั้นในตาราง VPNv4
RD เปลี่ยนกุญแจหนึ่งเป็นสอง
ตัวแยกเส้นทางแปดไบต์ถูกวางไว้หน้าคำนำหน้า IPv4 และวัตถุที่ BGP พาไปกลายเป็นที่อยู่ VPN-IPv4 แทนคำนำหน้า IPv4 ผู้เช่าสองรายถือ 32 บิตเดียวกันได้เพราะ 64 บิตข้างหน้าแตกต่างกัน มีรูปแบบชนิดสำหรับ RD ที่อิง AS และสำหรับ RD ที่อิงที่อยู่ และการเลือกเป็นของ PE ต้นทาง RD ที่อิง AS เป็นเรื่องปกติเมื่อ PE ใช้ AS ร่วมกัน และแบบอิงที่อยู่เมื่อไม่ร่วมกัน
อย่าอ่าน RD เป็นแท็กสมาชิกภาพ. เป้าหมายเส้นทางควบคุมการนำเข้าและการส่งออกและตัดสินว่า VRF ใดติดตั้งเส้นทางได้ RD เพียงรับประกันว่าเส้นทางมีตัวตนของตัวเอง การให้แต่ละ VRF มี RD ของตัวเองเป็นแนวปฏิบัติทั่วไปเพราะทำให้การแมปนั้นอ่านได้ในตัวดูเส้นทาง
เลเบลคือคำสั่งส่งต่อภายในเครื่อง
ทุกประกาศมีเลเบล MPLS ด้วย และความหมายจำกัดอยู่ที่เราเตอร์ที่จัดสรรเลเบลนั้น PE อื่นอาจออกหมายเลขเดียวกันสำหรับปลายทางที่ไม่เกี่ยวข้อง นั่นคือเหตุผลที่เลเบลแทนตัวตนของลูกค้าไม่ได้ หมายเลขนั้นถูกต้องก็ต่อเมื่ออยู่ข้าง ๆ ฮอปถัดไปและสภาพการส่งต่อที่ติดตั้งมันไว้
ความละเอียดของการจัดสรรแตกต่างกันตามการใช้งานและการออกแบบ แพลตฟอร์มบางตัวจัดสรรเลเบลหนึ่งตัวต่อ VRF บางตัวต่อคำนำหน้า และเลเบลอาจระบุการกระทำในการส่งต่อมากกว่าลูกค้า เลเบลสองตัวที่ต่างกันแต่ไปถึงปลายทางเดียวกันไม่ใช่ความขัดแย้ง และหมายเลขเลเบลเดียวกันบน PE สองตัวก็ไม่ใช่เช่นกัน
| Field | Where it lives | Scope | If you remove it |
|---|---|---|---|
| RD | VPNv4 NLRI | Per advertised route | Overlapping prefixes collide |
| Route target | Extended community | Import and export policy | Route lands in the wrong VRF |
| Label | Labeled NLRI and forwarding state | Per allocating router | No instruction for the data plane |
| Next hop | Path attribute | Per path | The label cannot be resolved |
ทำไมตัวหนึ่งแทนอีกตัวไม่ได้
การอ่านประกาศหมายถึงการดูสี่สิ่งพร้อมกัน คำนำหน้าที่ผ่าน RD เป้าหมายเส้นทาง ฮอปถัดไป และเลเบล การอ่านแพ็กเก็ตของผู้ใช้หมายถึงการดูสแต็กที่ติดตั้งจากข้อมูลนั้น การออกแบบที่ดีแสดงทั้งสองด้านสอดคล้องกัน และแบบที่เสียมักมีด้านหนึ่งถูกต้องอีกด้านล้าสมัย การเปรียบเทียบนั้นแยกปัญหาตัวตนออกจากปัญหาการส่งต่อ
ความต่างที่เรียบร้อยระหว่างระนาบควบคุมและระนาบข้อมูลเป็นเครื่องมือสอน ไม่ใช่คำอธิบายของการเข้ารหัส RFC 8277 วางเลเบลไว้ใน NLRI ที่ติดเลเบลไว้ ดังนั้นประกาศเองจึงพาการผูกนั้น การใช้มันเพื่อส่งต่อเป็นขั้นตอนถัดไปที่แยกต่างหาก
เมื่อเส้นทางของผู้เช่าหายไป ให้ตรวจตามลำดับนี้ สองรายการ VPNv4 สำหรับคำนำหน้า เป้าหมายเส้นทางที่ถูกต้องบนแต่ละรายการ ฮอปถัดไปที่แก้ได้ และเลเบลที่ PE ปลายทางมีสภาพสำหรับมัน การแก้ตัวตนด้วยค่าส่งต่อ หรือกลับกัน จะผ่านการตรวจหนึ่งรายการและล้มเหลวในรายการถัดไป