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

การไต่ตามแพ็กเก็ตหนึ่งตัวตลอดเส้นทางเป็นวิธีที่เร็วที่สุดในการดูว่าส่วนใดเป็นความรับผิดชอบของลูกค้าและส่วนใดเป็นของบริการ

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

งานของแต่ละฮอปสิ้นสุดตรงไหน

CE-A ต้องการเส้นทางไปยัง LAN ปลายทางที่ชี้ไปยังจุดเชื่อมต่อผู้ให้บริการท้องถิ่นของตน ไม่ใช่ไปยังที่อยู่ WAN ของสาขาปลายทาง จากนั้นผู้ให้บริการขนแพ็กเก็ตผ่านแกนหลักของตนโดยใช้สถานะการรูตติ้งของ VPN และ CE-B ส่งมอบไปยัง LAN ปลายทาง ไม่มีจุดใดที่โฮสต์ต้องเข้าใจเลเบล VRF หรือวงจรอินเทอร์เน็ตของอีกฝั่ง

ข้อผิดพลาดที่เกิดซ้ำในตั๋วคือการกำหนดที่อยู่ WAN ของสาขา B เป็นฮอปถัดไปที่สาขา A ทั้งสองสาขาซื้อบริการเดียวกัน จึงรู้สึกว่าควรเป็นเพื่อนบ้านกัน แต่ไม่ใช่ ฮอปถัดไปต้องเข้าถึงได้ผ่านการออกแบบรูตติ้งที่คุณมีจริง และ CE ปลายทางมักอยู่ห่างหลายฮอปหลังอุปกรณ์ที่คุณไม่ได้ดูแล เส้นทางสถิตที่สร้างบนสมมติฐานนั้นจะแสดงว่าใช้งานอยู่และไม่คลี่คลายไปที่ใดเลย ซึ่งแย่กว่าเส้นทางที่หายไปเพราะในตารางดูเหมือนถูกต้อง

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

การส่งมอบต้องตกลงเรื่องอะไร

เลือกกลไกกับผู้ให้บริการ ไม่ใช่เลี่ยงรอบตัวเขา เส้นทางสถิต BGP หรือข้อตกลงโปรโตคอลรูตติ้งระหว่าง CE กับ PE ล้วนชอบด้วยกฎหมาย และ OSPF มีโมเดล MPLS VPN ที่กำหนดไว้สำหรับการส่งมอบเช่นนี้ ไม่มีสิ่งใดเป็นเหตุผลให้สร้างความสัมพันธ์เพื่อนบ้าน OSPF ระหว่างขอบลูกค้าปลายทางสองแห่งผ่านแกนหลักผู้ให้บริการที่ไม่ได้ระบุไว้ เพราะนั่นคือการออกแบบที่ผู้ให้บริการไม่ได้ตกลงและไม่สามารถรองรับได้

ก่อน LAN ใหม่เริ่มให้บริการ จดสี่อย่างไว้ ได้แก่ คำนำหน้า เส้นทางถัดไปฝั่งท้องถิ่นบน CE การประกาศที่ผู้ให้บริการจะยอมรับ และเส้นทางที่ผู้ให้บริการจะส่งกลับ เพิ่มการกรอง ขีดจำกัดคำนำหน้า หรือข้อจำกัดระหว่างไซต์ที่สัญญากำหนด เรียกได้ว่าความเป็นเพื่อนบ้านที่ดีคือช่องทางแลกเปลี่ยนข้อมูล ไม่ใช่หลักฐานว่าคำนำหน้าหนึ่งได้รับการยอมรับ เซสชันอาจขึ้นอยู่ขณะที่ซับเน็ตใหม่ของคุณติดอยู่ในตัวกรอง

จากนั้นไต่ตามการตอบกลับ สาขา B ต้องการเส้นทางกลับไปยัง LAN ต้นทาง และโฮสต์ฝั่งรับต้องการเกตเวย์และสิทธิ์บริการของตัวเอง เส้นทางที่ปรากฏบน CE-A สร้างการเดินทางไปกลับได้เพียงครึ่งเดียว และครึ่งเดียวนี้เองคือเหตุผลที่การทดสอบ ping ทิศทางหนึ่งดูปกติในขณะที่แอปพลิเคชันยังล้มเหลว

ตรวจสอบการส่งมอบทั้งสองก่อนการรับมอบ

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

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

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

รู้ว่าบริการไม่ได้ให้อะไร

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

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

สุดท้าย เก็บโมเดลบริการไว้เป็นลายลักษณ์อักษรข้างการกำหนดค่ารูตติ้งของไซต์ วิศวกรคนถัดไปที่เพิ่มซับเน็ตควรอ่านได้ว่าคำนำหน้าใดถูกประกาศ ใครยอมรับ และเส้นทางกลับที่คาดหวังคืออะไร ข้อกำหนด BGP/MPLS IP VPN เป็นเอกสารอ้างอิงของโมเดลที่อยู่เบื้องหลังทั้งหมดนี้

บทความที่เกี่ยวข้อง