ทำไม L2VPN บน Junos จึงแสดงป้ายกำกับแต่ไม่ส่งต่อสิ่งใด
Kompella L2VPN เลือกสถานะการส่งต่อจาก attachment ไม่ใช่จากการค้นหาเส้นทาง อ่านทิศทางป้ายกำกับทั้งฝั่งท้องถิ่นและฝั่งไกลก่อนโทษการขนส่ง
มีรายงานจากลูกค้าว่าการเชื่อมต่อ L2VPN อยู่ในสถานะ Up, attachment ขึ้นแล้ว, แต่ไม่มีเฟรมใดผ่านไป ไฟสถานะนั้นซื่อสัตย์; เฟรมกำลังถูกจัดประเภทเข้าสู่บริการที่ปลายทางไกลไม่มีสถานะการส่งต่อที่ใช้งานได้ ใน L2VPN แบบจุดต่อจุดที่ส่งสัญญาณด้วย BGP การตัดสินใจแรกเป็นของ attachment ไม่ใช่การค้นหาเส้นทาง เฟรมของลูกค้ามาถึงอินเทอร์เฟซเชิงตรรกะ และอินเทอร์เฟซนั้นระบุการเชื่อมต่อและดังนั้นจึงระบุไซต์ปลายทางไกล ทุกสิ่งหลังจากนั้นคือสถานะการส่งต่อด้วยป้ายกำกับที่สร้างจากสิ่งที่เพียร์ประกาศ
เฟรมไม่เคยค้นหาเส้นทาง
การส่งสัญญาณได้เตรียมสถานะไว้แล้ว; การประมวลผลต่อแพ็กเก็ตคือการค้นหาป้ายกำกับบนการเชื่อมต่อที่ถูกเลือกไว้แล้ว ดังนั้นการถามว่าเส้นทางหายไปไหนจึงเป็นคำถามที่ผิด และมันซ่อนค่าสำคัญสองค่าไว้ คือการเชื่อมต่อของ attachment และป้ายกำกับบริการที่มันใช้
นั่นยังอธิบายความไม่สมดุลของความพยายามได้ด้วย การทบทวนการกำหนดค่าบอกว่าอะไรควรถูกติดตั้งไว้ ขณะที่มุมมองการเชื่อมต่อบอกว่าอะไรถูกอนุมานออกมาจริง และมีเพียงอย่างหลังเท่านั้นที่อยู่รอดเมื่อบล็อกป้ายกำกับไม่ตรงกัน
สองป้ายกำกับ สองทิศทาง
แต่ละ PE จัดสรรบล็อกป้ายกำกับในเครื่อง ประกาศฐานและขนาดของมัน และเพียร์ของมันเพิ่มออฟเซตเพื่อหาป้ายกำกับสำหรับไซต์หนึ่ง ๆ การจัดสรรจึงมีความหมายเฉพาะเครื่อง: PE สองตัวสามารถใช้ฐานและขนาดบล็อกต่างกันสำหรับบริการเดียวกัน อ่านการเชื่อมต่อจากทั้งสองปลายก่อนเปลี่ยนแปลงสิ่งใด บล็อกที่ถูกกำหนดขนาดเล็กเกินไปหนึ่งป้ายกำกับดูเหมือนการเชื่อมต่อที่ไม่เคยติดตั้งเลย
show l2vpn connections instance CUST-A extensive
ในเอาต์พุตนั้น ป้ายกำกับขาเข้าคือป้ายที่ PE นี้จัดสรรและบอกให้เพียร์ใช้ ส่วนป้ายกำกับขาออกคือการจัดสรรของเพียร์ที่ PE นี้พุช การอ่านทั้งสองกลับด้านเป็นความผิดพลาดคลาสสิก และมันส่งให้ไปตามหาค่าที่ไม่ควรปรากฏฝั่งนี้เลย เอกสารอ้างอิงการเชื่อมต่อ อธิบายฟิลด์ข้างป้ายกำกับ รวมถึงไซต์ สถานะ และข้อมูลบล็อก
ป้ายกำกับพิสูจน์อะไร
เมื่อได้ค่าขาเข้าแล้ว การค้นหาในเครื่องคือคำสั่งเดียว:
show route label 160042
เอาต์พุตนั้นควรแสดงรายการ l2vpn พร้อมฮอปถัดไป และการดำเนินการกับป้ายกำกับบอกว่าเฟรมถูกพุช สลับ หรือป็อปก่อนออกไปหรือไม่ ถ้าไม่แสดงอะไรเลย สถานะบริการไม่เคยถูกติดตั้งแม้การเชื่อมต่อจะแสดง Up และความคลาดเคลื่อนอยู่ที่การส่งสัญญาณไม่ใช่การขนส่ง
ติดตามหนึ่งเฟรม
แพ็กเก็ตเดียวที่พุชเข้า attachment ตัดสินได้มากกว่าการทบทวนการกำหนดค่าใด ๆ เส้นทางป้ายกำกับบริการควรชี้ไปที่ LSP ขนส่งไปยัง PE ปลายทางไกล และป้ายกำกับทั้งสองควรตรงกับค่าที่เพียร์รายงาน เมื่อการขนส่งแข็งแรงแต่ป้ายกำกับบริการผิด เฟรมจะไปถึงเราเตอร์ที่ถูกต้องและถูกทิ้งที่นั่น จึงเป็นเหตุให้ตัวนับปลายไกลดูว่างเปล่าขณะที่ตัวนับปลายใกล้ดูไม่ว่าง
ตรวจสอบ encapsulation ของ attachment การตั้งค่า control word และ MTU พร้อมกัน เพราะสิ่งเหล่านี้เป็นคุณสมบัติที่ต่อรองกัน ไม่ใช่พฤติกรรมต่อฮอป
แยกแบบจำลองบริการออกจากกัน
VPLS เรียนรู้ที่อยู่ MAC และ EVPN ประกาศปลายทาง ขณะที่ L2VPN แบบจุดต่อจุดไม่ทำทั้งสองอย่าง กระบวนการเลือกเฟรมของทั้งสองจึงแลกเปลี่ยนกันไม่ได้แม้จะวิ่งบนโครงสร้างพื้นฐาน BGP และ MPLS เดียวกัน การยกขั้นตอนแก้ปัญหาไปจากแบบจำลองหนึ่งยังอีกแบบหนึ่งทำให้ได้ข้อสรุปที่มั่นใจแต่ไม่มีพื้นฐาน
เมื่อเส้นทางหายไป ให้บันทึกสถานะการเชื่อมต่อของเพียร์ทั้งสอง attachment ทิศทางป้ายกำกับทั้งสอง encapsulation การตั้งค่า control word และ MTU บันทึกนั้นเชื่อมสิ่งที่ประกาศไว้กับสิ่งที่ระนาบส่งต่อทำจริง ซึ่งเป็นข้อเชื่อมโยงเดียวที่สำคัญ และเป็นสิ่งที่วิศวกรคนต่อไปจะถามหา