อุโมงค์ RSVP-TE ทำงานอยู่ แต่ L3VPN ของลูกค้าไม่มีเส้นทาง
การขนส่งและบริการเป็นการตัดสินใจคนละเรื่อง อ่านสแตกเลเบล ตรวจสอบการแก้ไขฮอปถัดไปและการเชื่อมต่อ VRF แยกกัน แล้วทดสอบโฟลว์ลูกค้าจริงหนึ่งรายการ
สองทีมสามารถถูกทั้งคู่ได้เมื่อลูกค้ารายงานว่า VPN ล่มและทีมขนส่งรายงานว่าอุโมงค์ปกติดี LSP ที่ผ่านวิศวกรรมทราฟฟิกกับ MPLS L3VPN ตอบคำถามคนละข้อ ตัวหนึ่งย้ายแพ็กเก็ตที่ติดเลเบลผ่านคอร์ อีกตัวตัดสินว่าแพ็กเก็ตอยู่ในบริบทการเราท์ติ้งใด เมื่อทั้งสองถูกปนกัน การถกเถียงจึงวนเป็นวงกลม เพราะแต่ละฝ่ายวัดวัตถุคนละอย่างและการวัดทั้งสองถูกต้อง
การขนส่งทำงานแต่บริการล่มเป็นสภาวะปกติ
LSP อาจถูกสร้างขึ้น ขนส่งทราฟฟิก และมองเห็นได้ในทุกระบบตรวจสอบ ขณะที่บริการของลูกค้ายังใช้งานไม่ได้ สิ่งใดในส่วนผสมนี้ก็ไม่ขัดแย้ง เพราะอุโมงค์ไม่มีความเห็นว่ามีคำนำหน้าระยะไกลอยู่หรือไม่ นโยบายนำเข้ามีการยอมรับหรือไม่ หรือวงจรเชื่อมต่อกำลังส่งผ่านเฟรมอยู่หรือไม่
อาการที่มักเผยความสับสนคือความไม่สมมาตร ping จากลูปแบ็กของ PE สำเร็จ ขณะที่โฮสต์บน LAN ของลูกค้ากลับไม่ได้รับอะไร หรือกลับกัน จดบันทึกว่าแอดเดรสใดทำงานก่อนจะสร้างทฤษฎี เมื่อตระหนักว่ากำลังทดสอบวัตถุสองอย่างที่ต่างกัน ขั้นต่อไปคืออ่านสแตกเลเบล ไม่ใช่เถียงว่ากราฟของใครถูก สองแอดเดรส สองเจ้าของ และมักเป็นคนสองคนที่แต่ละฝ่ายเชื่อว่าอีกฝ่ายทำอะไรพัง
อ่านสแตกเป็นสองความรับผิดชอบ
เลเบลล่างเป็นของบริการและเลเบลบนเป็นของเส้นทาง RFC 4364 อธิบายลำดับอย่างง่าย เริ่มจากใส่เลเบลเส้นทาง VPN ก่อน จากนั้นแพ็กเก็ตที่ติดเลเบลนั้นจะถูกส่งผ่านอุโมงค์ไปยังฮอปถัดไปของ BGP ซึ่งเป็นที่ที่อุโมงค์วิศวกรรมทราฟฟิกดันเลเบลของตัวเองทับลงไป
| Object | Decision it encodes | Who owns it |
|---|---|---|
| Attachment and VRF | Which customer context receives the arriving packet | Edge configuration |
| VPN route and service label | Which remote forwarding context handles the destination | BGP VPN signalling |
| Transport LSP and tunnel label | How the core carries the packet to the BGP next hop | RSVP-TE or another tunnel mechanism |
ที่ PE ปลายทาง เลเบลบริการเป็นตัวเลือกวิธีจัดการ ซึ่งอาจเป็นการค้นหา VRF หรือการตัดสินใจเชื่อมต่อ เลเบลนั้นแทนที่ด้วยเลเบลที่เพียงผ่านคอร์ไม่ได้ และทั้งสองใช้แทนกันไม่ได้แม้จะปรากฏในสแตกเดียวกันบนอินเทอร์เฟซเดียวกัน
ความสำเร็จของ RSVP พิสูจน์อะไรและไม่พิสูจน์อะไร
RSVP-TE สร้าง LSP ที่กำหนดเส้นทางอย่างชัดเจน พร้อมหรือไม่พร้อมการจองทรัพยากร ซึ่งเป็นหลักประกันที่เฉพาะเจาะจงและมีประโยชน์เกี่ยวกับเส้นทางที่แพ็กเก็ตใช้ผ่านคอร์ ไม่ใช่ข้อความเกี่ยวกับเส้นทางของลูกค้า และชื่ออุโมงค์ที่กำหนดค่าไว้ก็ไม่ใช่เส้นทางเลย
การมีอยู่ของ RSVP ก็ไม่ได้ให้คำมั่นเรื่องประสิทธิภาพจากต้นจนจบ การจองแบนด์วิดท์บน LSP หนึ่งเส้นไม่ได้บอกอะไรเกี่ยวกับวงจรเชื่อมต่อ สายเข้าของลูกค้าเอง หรือพฤติกรรมคิวที่ขอบปลายทาง การมองสิ่งนี้เป็นหลักประกันทำให้ได้คำตอบที่มั่นใจต่อคำถามที่ไม่มีใครถาม หากข้อกำหนดเป็นการผูกพันแบนด์วิดท์จริง ต้องประกอบจากชิ้นส่วนที่บังคับใช้ได้จริง และ LSP เป็นเพียงกลางของห่วงโซ่นั้น
ตรวจตามลำดับแล้วหยุด
ทำงานจากการขนส่งออกไปด้านนอกและหยุดที่ขั้นแรกที่ล้มเหลว เพราะทุกขั้นถัดไปสมมติว่าขั้นก่อนหน้าคงอยู่ ยืนยันก่อนว่า LSP ถูกสร้างและรายการส่งต่อสำหรับคำนำหน้าบริการชี้ไปที่มันจริง จากนั้นยืนยันว่าเส้นทาง VPN อยู่ในตารางที่ถูกต้อง มีการผูกเลเบล และนโยบายนำเข้ายอมรับแล้ว จากนั้นยืนยันการเชื่อมต่อ อินเทอร์เฟซ การห่อหุ้ม และเมื่อเกี่ยวข้อง ตัวระบุ VLAN ที่เป็นของสัญญานั้น
show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMERไวยากรณ์คำสั่งแตกต่างตามแพลตฟอร์ม จึงควรมองสี่บรรทัดนั้นเป็นสี่คำถามไม่ใช่สคริปต์ ส่วนสำคัญคือแต่ละข้อสอบถามวัตถุคนละอย่าง และนั่นคือเหตุผลที่ความล้มเหลวชี้ไปยังเจ้าของที่เฉพาะเจาะจง
ติดตามคำขอที่ได้รับอนุญาตหนึ่งรายการและเก็บหลักฐานที่ดีไว้
ปิดท้ายด้วยคำขอจริงของลูกค้าหนึ่งรายการที่ได้รับอนุญาตตามนโยบายและคำตอบของมัน โฟลว์เดียวที่ทำงานได้จากต้นจนจบตัดสินได้มากกว่าหน้าหนึ่งของค่าตัวนับ และมันทดสอบส่วนผสมมากกว่าชิ้นส่วนแต่ละชิ้นแยกกัน
เมื่อขั้นตอนหลังล้มเหลว ให้เก็บข้อสังเกตของ LSP ที่สำเร็จไว้แทนการสร้างการขนส่งใหม่ การสร้างอุโมงค์ที่ทำงานอยู่ใหม่ไม่สามารถซ่อมคำนำหน้าระยะไกลที่หายไป การเชื่อมต่อ VRF ที่ผิด หรือกฎการเข้าถึงปลายทางได้ และมันทำลายหลักฐานที่บอกคุณตั้งแต่แรกว่าการขนส่งแข็งแรงดี