VPNv4 จำเป็นต้องมี MPLS ในแกนหรือไม่? ไม่จำเป็นเสมอไป
BGP VPNv4 เจรจาบริบทการกระจายเส้นทาง ไม่ใช่เส้นทางส่งต่อ แยกการนำเข้า การแก้ไขฮอปถัดไป และการห่อหุ้มที่คุณใช้งานได้
การเปิดใช้ตระกูลที่อยู่ VPNv4 ระหว่างเราเตอร์สองตัวสร้างเพียงบริบทการกระจายเส้นทางเท่านั้น ไม่มีอะไรมากกว่านั้น มันไม่ได้ติดตั้งเส้นทางส่งต่อและไม่ได้บอกว่าการห่อหุ้มแบบใดจะพาแพ็กเก็ตลูกค้าไปยังปลายทางระยะไกล เมื่อแยกข้อเท็จจริงสองข้อนี้ออกจากกัน คำถาม «สิ่งนี้ต้องมี MPLS ในแกนหรือไม่» จึงกลายเป็นคำถามที่แคบลงและตอบได้ เกี่ยวกับระนาบข้อมูลที่แพลตฟอร์มรองรับ
ตระกูลที่อยู่เจรจาอะไรจริง ๆ
BGP หลายโปรโตคอลพาข้อมูลการเข้าถึงได้ของชั้นเครือข่าย VPNv4 ภายใต้ AFI 1 และ SAFI 128 และแต่ละรายการจับคู่ตัวจำแนกเส้นทางกับคำนำหน้าและป้ายกำกับ เซสชันเจรจาว่าทั้งสองฝ่ายสามารถเข้ารหัสและถอดรหัสข้อมูลนั้นได้ สิ่งที่ไม่เจรจาคือระนาบข้อมูล ทุกอย่างหลังย่อหน้านี้เกี่ยวกับการส่งต่อ และไม่มีสิ่งใดถูกตัดสินโดยการที่เซสชันขึ้นมา
ดังนั้นเซสชันที่สำเร็จเป็นหลักฐานของความสามารถของระนาบควบคุม ไม่ใช่การส่งต่อ เราเตอร์สามารถถือรายการ VPNv4 หลายพันรายการและยังคงทิ้งแพ็กเก็ตลูกค้าทุกแพ็กเก็ต และนั่นคือเหตุผลที่ประเภทความล้มเหลวทั้งสองถูกสับสนตั้งแต่แรก
สังเกตป้ายกำกับใน NLRI มันเป็นป้ายกำกับบริการ ผูกกับคำนำหน้าภายใน VRF และมีบทบาทในการส่งต่อเมื่อแพ็กเก็ตไปถึงปลายทางออก การที่อุปกรณ์ส่งผ่านใด ๆ อ่านมันหรือไม่เป็นการตัดสินใจออกแบบแยกต่างหาก
การรับ การนำเข้า และการส่งต่อเป็นสามขั้นตอน
การรับเส้นทาง การได้รับอนุญาตให้ใช้ และความสามารถในการส่งต่อด้วยเส้นทางนั้นดำเนินการโดยส่วนต่าง ๆ ของอุปกรณ์ BGP เก็บสิ่งที่ได้ยิน นโยบายการนำเข้าและการจับคู่เป้าหมายเส้นทางตัดสินว่า VRF ใดพิจารณาได้ จากนั้นระนาบการส่งต่อต้องแก้ไขฮอปถัดไปที่ประกาศให้เป็นสิ่งที่ผลักออกไปบนสายได้จริง
| Step in the chain | What has to be true | How it fails quietly |
|---|---|---|
| NLRI exchange | Both speakers negotiate the VPNv4 capability | Session stays up while the family is never activated |
| Import eligibility | A route target on the received route matches the VRF import policy | The route exists in the table but never enters the VRF |
| Next-hop resolution | The advertised next hop resolves to a usable tunnel or label path | Best path is selected, then marked unreachable or unusable |
| Encapsulation | The egress endpoint can decapsulate what the ingress produced | Packets arrive and are discarded for a format mismatch |
ความล้มเหลวที่น่าประหลาดใจที่สุดอาศัยอยู่ในขั้นกลางนี้ เส้นทางอาจมีอยู่ในตาราง BGP ถูกต้องและแม้แต่ดีที่สุด ขณะที่ตารางเส้นทางของ VRF ยังว่างเปล่าเพราะไม่มีเป้าหมายเส้นทางใดตรงกับรายการนำเข้า ไม่มีสิ่งใดบันทึกข้อผิดพลาดโปรโตคอล เพราะไม่มีข้อผิดพลาดโปรโตคอลเกิดขึ้น
ขั้นสุดท้ายคือที่ซึ่งการสนับสนุนของแพลตฟอร์มปรากฏ ฮอปถัดไปที่เข้าถึงได้ในชั้นล่างไม่สามารถแก้ไขเป็น transport ของบริการ VPN ได้โดยอัตโนมัติ และอุปกรณ์อาจต้องการประเภทอุโมงค์เฉพาะ การดำเนินการป้ายกำกับเฉพาะ หรือทั้งสองอย่าง การอ่านสถานะการแก้ไขให้ข้อมูลมากกว่าการอ่านจำนวนเส้นทาง
แกน IP สามารถบรรทุกสแต็กที่มันไม่เคยสลับ
ความแตกต่างที่ควรเก็บไว้คือระหว่าง «แกนไม่ได้รัน MPLS» กับ «ไม่มีป้ายกำกับที่ใดในบริการ» สิ่งเหล่านี้เป็นการกล่าวอ้างที่ต่างกัน และมีเพียงอย่างแรกเท่านั้นที่เกี่ยวกับอุปกรณ์ส่งผ่าน RFC 4023 กำหนดการบรรทุก MPLS ผ่านอุโมงค์ IP หรือ GRE และกลไกนั้นเองที่ทำให้การกล่าวอ้างที่สองเป็นไปได้บนแกน IP ล้วน
customer packet + service label
encapsulated in GRE, addressed to the egress tunnel endpoint
forwarded by ordinary IP routers on the outer header
decapsulated at the endpoint, label still meaningfulเราเตอร์ส่งผ่านส่งต่อตามปลายทาง IP ภายนอกและไม่ต้องการทั้งคำนำหน้าลูกค้าและการสลับป้ายกำกับแบบเนทีฟ ที่ปลายไกลอุโมงค์ภายนอกถูกถอดออกและป้ายกำกับบริการกลับมาทำงานต่อ แกนย้ายเพย์โหลดทึบแสง ซึ่งเป็นสิ่งที่เครือข่าย IP เก่ง
สิ่งที่การออกแบบนี้ไม่ได้ให้คือการรับประกันสากล มันไม่ใช่หลักฐานว่าเราเตอร์ทุกตัวแก้ไขฮอปถัดไป VPNv4 ทุกฮอปผ่านอินเทอร์เฟซ GRE ใด ๆ และไม่ใช่เหตุผลที่จะลบการกำหนดค่า MPLS แบบเนทีฟที่ทำงานอยู่ มันเป็นตัวอย่างค้านกับการกล่าวอ้างสากล และคำถามเชิงปฏิบัติยังคงเป็นเรื่องเฉพาะของแพลตฟอร์ม บันทึกคำถามนั้นเป็นข้อจำกัดของแพลตฟอร์ม ไม่ใช่กฎของโปรโตคอล
เดินไปตามห่วงโซ่บนกล่องจนกว่าจะขาด
เริ่มจากเส้นทางที่รับมาและหยุดที่ขั้นแรกที่ล้มเหลว เพราะขั้นถัดไปไม่สามารถวินิจฉัยได้ขณะที่ขั้นก่อนหน้าเสีย สี่คำสั่งครอบคลุมส่วนใหญ่ในการติดตั้งใช้งานทั่วไป
show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_Aอ่านเป็นลำดับ ไม่ใช่การตรวจสอบอิสระสี่อย่าง อย่างแรกยืนยันว่าตระกูลทำงานและเพียร์แลกเปลี่ยนเส้นทาง อย่างที่สองแสดงว่าคำนำหน้ามาพร้อมฮอปถัดไปที่ใช้ได้หรือไม่ อย่างที่สามพิสูจน์คุณสมบัติการนำเข้า อย่างที่สี่แสดงว่าระนาบการส่งต่อผูกป้ายกำกับหรืออุโมงค์ไว้หรือไม่
จากนั้นทดสอบเส้นทางภาระงานทั้งสองทิศทาง ด้วย MTU ที่ทนต่อการห่อหุ้ม GRE เพิ่มไบต์หัวเรื่อง และเส้นทางที่ผ่านการทดสอบเล็ก ๆ อาจล้มเหลวกับแพ็กเก็ตขนาดเต็มในทิศทางเดียวเท่านั้น ซึ่งดูเหมือนความผิดพลาดของแอปพลิเคชันไม่ใช่การขนส่ง
บันทึกการปฏิบัติงานสองข้อปิดวงจร GRE คือการห่อหุ้ม ไม่ใช่ความลับ ดังนั้นเครือข่ายส่งผ่านที่ไม่น่าเชื่อถือต้องมีการจัดความปลอดภัยที่รองรับด้านบนแทนการสันนิษฐาน และบันทึกว่าการห่อหุ้มแบบใดที่แพลตฟอร์มรองรับจริงก่อนการทบทวนการออกแบบ เพราะคำตอบเดียวนั้นกำหนดว่าแกน IP ล้วนเป็นทางเลือกที่ใช้ได้หรือแผนที่ไม่สามารถส่งต่อได้