แล็บ MPLS L3VPN ปิงไม่ผ่าน? ตรวจสอบห้าฮอปนี้

เราเตอร์ลูกค้าสองตัว อุปกรณ์ provider edge หนึ่งคู่ และปิงที่ตายโดยไม่มีข้อความแสดงข้อผิดพลาด ในแล็บ MPLS L3VPN ขนาดเล็ก ความผิดพลาดมักอยู่ที่จุดตรวจหนึ่งในห้าเสมอ และแต่ละจุดมีคำสั่งที่แสดงว่าการพึ่งพาทำงานหรือหายไป ข้อผิดพลาดคือการรีสตาร์ต BGP ทุกครั้งที่ปิงล้มเหลว แทนที่จะทดสอบการพึ่งพาตามลำดับ ถ้าคุณกระโดดไปที่การตั้งค่า VRF ทันที คุณอาจเสียเวลาหนึ่งชั่วโมงกับปัญหาที่เริ่มจากฮอปถัดไปที่ยังแก้ไม่เสร็จห่างออกไปสองอุปกรณ์

ทำงานกับรายการจากล่างขึ้นบน จุดตรวจที่ผ่านแล้วก็ผ่านเลย และความล้มเหลวแรกคือสิ่งที่ควรดีบัก

จุดตรวจแรก: PE เข้าถึงกันได้

PE แต่ละตัวต้องมีเส้นทางไปยัง loopback ของอีก PE และเส้นทางนั้นต้องแก้ผ่านสิ่งที่มีจริง interior gateway protocol เป็นวิธีปกติ แต่เส้นทางแบบคงที่ก็ใช้ได้ตราบใดที่การค้นหาแบบเรียกซ้ำไปลงที่ adjacency ที่ยังมีชีวิต บนอุปกรณ์สไตล์ IOS คำสั่ง show ip route 10.0.0.2 ตามด้วย show ip cef 10.0.0.2 จะบอกว่า prefix มีอยู่หรือไม่ และมี adjacency ที่แก้แล้วอยู่ข้างหลังหรือไม่ เส้นทางในตารางที่ไม่มี adjacency ข้างหลังไม่ใช่การเข้าถึง

ตรวจทั้งสองทิศทาง ต้นทุน IGP ที่ไม่สมมาตร passive interface ผิดด้าน หรือ distribute list ที่กรอง loopback จะทำให้เสียเพียงทิศทางเดียว และทิศทางเดียวก็เพียงพอที่จะฆ่าเซสชัน ถ้า loopback ปิงได้แต่เซสชัน BGP ค้างอยู่ใน Active ให้ดู update source ก่อนแตะอย่างอื่น

จุดตรวจที่สอง: มีเส้นทางเลเบล

เส้นทาง IP ไปยัง loopback ปลายทางไกลไม่ได้พิสูจน์ว่าการขนส่งจะใส่เลเบล ในดีไซน์ LDP ให้ยืนยันว่า loopback ปลายทางไกลมีทั้งการผูกแบบโลคอลและแบบรีโมต และเลเบลขาออกปรากฏในตาราง forwarding show mpls ldp bindings 10.0.0.2 32 แสดงคู่เลเบล และ show mpls forwarding-table 10.0.0.2 แสดงสิ่งที่ line card จะใส่จริง เมื่อคำสั่งที่สองไม่แสดงเลเบลใดเลยหรือตกกลับไปที่ IP การขนส่งไม่ได้บรรทุกทราฟฟิก VPN ตามที่ดีไซน์สมมติ

ความแตกต่างนี้มาจากวิธีที่ MPLS แยก forwarding state ออกจาก prefix ปลายทาง ซึ่งเป็นแบบจำลองที่อธิบายใน RFC 3031 ถ้าแล็บของคุณใช้ RSVP-TE หรือเลเบลที่อยู่ติดกับ BGP แทน LDP ให้ตรวจสอบสถานะของกลไกนั้นเอง การสมมติว่า LDP แจกจ่ายทุกเลเบลชั้นล่างเป็นวิธีทั่วไปในการไล่บั๊กผี เส้นทางเลเบลที่พังมักปรากฏในภายหลังเป็นเส้นทาง VPN ที่มีอยู่แต่ใช้ไม่ได้

จุดตรวจที่สาม: เส้นทาง VPN มาถึงครบถ้วน

ดูเส้นทาง VPNv4 หรือ VPNv6 ของ prefix ลูกค้าที่แน่นอน ไม่ใช่สรุปเซสชัน show bgp vpnv4 unicast all 10.10.1.0/24 ควรแสดง route distinguisher, next hop ที่ตั้งไปยัง loopback ของ PE ปลายทางไกล และเลเบล ถ้า prefix หายไป ผู้ต้องสงสัยแรกคือนโยบาย export บน PE ต้นทางหรือนโยบาย import บน PE ผู้รับ และ route target คือตัวการปกติ

อ่านการตรวจ route target แยกจากการรับ BGP เส้นทางอาจมาถึงพร้อม next hop ที่ถูกต้องและยังลงใน VRF ไม่ได้เพราะ importtarget ไม่ตรงกัน บน PE ผู้รับ show ip route vrf CUSTOMER 10.10.1.0 คือการทดสอบที่มีความหมาย ตาราง BGP พิสูจน์เพียงว่าเส้นทางข้ามระนาบควบคุมมาแล้ว

จุดตรวจที่สี่: interface อยู่ใน VRF

นิยาม VRF ที่มี route distinguisher และ route target ไม่ได้ย้าย interface ใดเข้าไป ข้าง interface ฝั่ง CE ต้องการการกำหนด VRF และ show ip vrf interfaces หรือ show ip interface brief ควรแสดงมันภายใต้อินสแตนซ์ที่ถูกต้อง นี่คือจุดตรวจที่การตั้งค่าที่คัดลอกมามักผิดพลาดบ่อยที่สุด เพราะบล็อก VRF ดูสมบูรณ์ในขณะที่ interface ยังอยู่ในตารางส่วนกลาง

จากนั้นยืนยันว่า PE ได้เรียนรู้ prefix ลูกค้าท้องถิ่นเข้าใน VRF นั้น และ CE มีเส้นทางกลับผ่านการเชื่อมต่อ default แบบคงที่บน CE ที่ชี้ไปยัง PE เพียงพอสำหรับแล็บ โดยมีเงื่อนไขว่า VRF ของ PE มีเส้นทางไปยัง LAN ของ CE ถ้าครึ่งใดครึ่งหนึ่งหายไป ปิงจะล้มเหลวก่อนที่จะมีเลเบลใดถูกใส่

จุดตรวจที่ห้า: คำตอบหาเส้นทางกลับบ้านได้

ติดตามแพ็กเก็ตขาไปแล้วจึงติดตามแพ็กเก็ตขากลับ เพราะทั้งสองใช้ตารางต่างกัน บน PE ขาเข้า ต้นทางของลูกค้าควรแก้ภายใน VRF ไปยัง prefix ปลายทางไกลด้วยเลเบลปลายทางไกล บน PE ขาออก ปลายทางควรแก้ภายใน VRF เดียวกันไปยัง interface ฝั่ง CE ปิงที่ส่งจาก PE เองไม่ใช่หลักฐาน เพราะอาจออกผ่านตารางส่วนกลางหรือที่อยู่ต้นทางอื่น ซึ่งเป็นเหตุผลว่าทำไม ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 คือการทดสอบที่ต้องรัน

ไฟร์วอลล์บนโฮสต์ reverse-path filtering และ access list บน CE ยังมีผลอยู่ ถ้าเส้นทางขาไปทำงานแต่คำตอบตาย ปัญหาอยู่ที่เส้นทางหรือตัวกรองฝั่งขากลับ ไม่ใช่การขนส่ง MPLS

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