DMVPN เฟส 3: อ่านทางลัดในทั้งสองทิศทาง
ping ตรงเพียงครั้งเดียวไม่ได้พิสูจน์ทางลัด DMVPN เฟส 3 เดินเส้นทางขาไปและขากลับ แล้วอ่านสถานะ NHRP เส้นทาง และ IPsec แยกกัน
คุณเห็น ping หนึ่งวิ่งจาก spoke ไปยัง spoke โดยใช้เส้นทางยาวผ่าน hub และอีกอันวิ่งตรง การสรุปว่าทางลัดทำงาน ณ จุดนั้นเป็นเรื่องที่ชวนให้ทำ ข้อสรุปนั้นถูกครึ่งเดียว เส้นทางขาไปอาจเป็นทางลัดในขณะที่ขากลับยังวิ่งผ่าน hub และสถานะที่พิสูจน์แต่ละทิศทางเป็นสถานะที่ต่างกัน เดินทั้งสองทิศทางและอ่านตารางสามตารางก่อนยอมรับว่าการออกแบบนี้แข็งแรง
เริ่มจากเส้นทางของแพ็กเก็ตที่คุณเห็นจริง
เริ่มที่ spoke ที่มีปลายทางซึ่งควรเป็นเส้นทางตรง ติดตามแพ็กเก็ตแรก: มันวิ่งตามเส้นทางของ spoke ไปยัง hub เพราะยังไม่มีทางลัด hub ส่งต่อแพ็กเก็ตนั้น และในการออกแบบเฟส 3 ยังส่งการเปลี่ยนเส้นทางกลับไปยังต้นทางว่ามีเส้นทางที่ดีกว่า
การเปลี่ยนเส้นทางนั้นคือตัวกระตุ้น ไม่ใช่ข้อพิสูจน์ มันบอกว่า hub เห็นทราฟฟิกที่ปรับให้ดีขึ้นได้ มันไม่ได้บอกว่าต้นทางสร้างทางลัด ปลายทางตอบการแปลงที่อยู่ หรือเส้นทางขากลับใช้ทางลัดนั้น
ดังนั้นการสังเกตที่มีประโยชน์อย่างแรกคือก่อนและหลัง: กระแสแรกผ่าน hub กระแสหลังจากนั้นวิ่งตรง
สามสถานะที่ดูเหมือนอุโมงค์เดียว
ทางลัดขึ้นอยู่กับสถานะสามส่วน และแต่ละส่วนมีอายุและคำสั่งของตัวเอง
| State | What it answers | Where to read it |
|---|---|---|
| NHRP cache | Which transport address maps to this overlay address | show ip nhrp |
| Route or shortcut | Where one specific inner prefix is forwarded | show ip route 10.10.20.5 |
| IPsec association | Which peer traffic is protected, and by which SA | show crypto ipsec sa peer 203.0.113.5 |
รายการแคช NHRP จับคู่ที่อยู่ overlay กับที่อยู่ขนส่ง NBMA เส้นทางหรือทางลัดตัดสินว่าเป้าหมายภายในหนึ่งรายการถูกส่งต่อไปที่ใด การเชื่อมโยง IPsec ปกป้องทราฟฟิกใดก็ตามที่เกิดขึ้น คำตอบที่หายไปอาจมาจากหนึ่งในสาม และคำสั่งบอกคุณว่าสิ่งใดขาด
อ่านตามลำดับนั้น เพราะการแมปที่ขาดทำให้อีกสองอย่างไม่น่าสนใจ
เดินคำขอและคำตอบแยกกัน
จาก spoke A ขอการแปลงที่อยู่และดูว่าอะไรกลับมา คำขอวิ่งผ่านเส้นทางส่งต่อ NHRP ที่รองรับ และปลายทางสามารถตอบได้โดยตรงแทนที่จะผ่าน hub ความไม่สมมาตรนั้นเป็นเรื่องปกติ และนั่นคือเหตุผลที่คำตอบเป็นครึ่งที่น่าสนใจของการแลกเปลี่ยน
ตอนนี้สลับบทบาท ส่งจาก B ไปยัง A และอ่านซ้ำทั้งสามครั้ง การออกแบบที่ทำทางลัดทิศทางเดียวและไม่ทำอีกทิศทางไม่สมมาตร และความไม่สมมาตรนั้นมักมาจากคำนำหน้าที่ขาดหายในด้านหนึ่งหรือการแปลงที่อยู่ที่ไม่เคยได้รับคำตอบ
คำตอบของคู่ไม่ได้ต้องผ่าน hub เพียงเพราะคำขอผ่านไป อย่าอ่านสิ่งนั้นเป็นข้อผิดพลาดและอย่าเริ่มตามหาข้อบกพร่องด้านเส้นทางที่ไม่มีอยู่
อ่านการเปลี่ยนเส้นทางของ hub ไม่ใช่แค่เส้นทางของมัน
ตารางเส้นทางของ hub บอกคุณว่า hub จะส่งแพ็กเก็ตไปที่ใด การเปลี่ยนเส้นทางบอกคุณว่า hub ขอให้ต้นทางทำอะไรกับเรื่องนั้น สองสิ่งนี้เป็นข้อเท็จจริงที่ต่างกัน และ hub ที่มีเส้นทางถูกต้องแต่ไม่มีการเปลี่ยนเส้นทางจะทำให้ทุกกระแสอยู่บนเส้นทางยาวอย่างไม่มีกำหนด ตรวจสอบเหตุการณ์ NHRP ของ hub และยืนยันว่ามีการสร้างการเปลี่ยนเส้นทางสำหรับทราฟฟิกที่คุณสนใจ
เฟส 3 ยังเปลี่ยนความหมายของการสรุปเส้นทาง ด้วยพฤติกรรมทางลัด spoke ไม่ต้องการชุดเส้นทางระยะไกลเฉพาะทั้งหมดที่การออกแบบเฟส 2 คาดหวัง ดังนั้นเส้นทางที่สรุปแล้วบน spoke จึงไม่ใช่เครือข่ายที่ขาดหายโดยอัตโนมัติ ยืนยันเฟสและนโยบายเส้นทางก่อนอ่านการสรุปว่าเป็นข้อบกพร่อง
ความเข้าใจผิดเรื่องเดียวนี้ทำให้เกิดตั๋ว DMVPN มากกว่าสิ่งอื่นใด
บันทึกข้อสรุปเป็นออบเจ็กต์ที่ขาดหาย
จบด้วยกระแสแอปพลิเคชันที่ได้รับอนุญาตและคำตอบของมัน และบันทึกสำหรับแต่ละทิศทางว่าใช้เส้นทางตรงหรือไม่ จากนั้นเขียนข้อสรุปเป็นออบเจ็กต์ที่ขาดหาย: การแมป ทางลัดการส่งต่อ การเชื่อมโยงการปกป้อง หรือการตอบกลับของแอปพลิเคชัน
ความเป็นเพื่อนบ้านของเส้นทางและการเชื่อมโยงความปลอดภัยที่ใช้ร่วมกันเป็นหลักฐานของความแข็งแรง ไม่ใช่หลักฐานของเส้นทาง ทั้งสองอย่างสมบูรณ์แบบได้ในขณะที่ทุกแพ็กเก็ตยังวิ่งอ้อมเส้นทางยาว ตรวจสอบการตัดสินใจส่งต่อก่อน แล้วจึงตรวจสอบการเชื่อมโยงที่รับมันไว้ ลำดับสำคัญ เพราะการเชื่อมโยงเกิดขึ้นไม่ว่าอย่างไร
นิสัยนั้นได้ผลในตั๋วใบถัดไป «อุโมงค์ขึ้นแต่ช้า» กลายเป็น «B ไม่มีทางลัดไปยังโฮสต์ของ A» และประโยคที่สองคือการแก้ไขห้านาที เก็บเอาต์พุตของคำสั่งไว้กับข้อสรุป และเก็บคู่มือเฟส 3 ของผู้ขายไว้ข้าง ๆ