เพื่อนบ้าน EIGRP ไม่ขึ้นบนโอเวอร์เลย์ DMVPN

อุโมงค์ขึ้นแล้ว สโป๊กหนึ่งปิงอีกอันได้ แต่ EIGRP ยังไม่แสดงเพื่อนบ้านบนฮับเลย การผสมแบบนี้เป็นเรื่องปกติ ไม่ใช่เรื่องลึกลับ เพราะ ping พิสูจน์การเข้าถึง unicast ผ่าน NHRP และ hello ของ EIGRP เป็น multicast บนโอเวอร์เลย์ DMVPN โมเดลการส่งของโปรโตคอลจัดเส้นทางเป็นระนาบการตั้งค่าที่สอง และนั่นคือสิ่งที่คนข้ามไปเพราะระนาบแรกดูดีอยู่แล้ว แต่ละชั้นด้านล่างถูกตรวจด้วยคำสั่งของตัวเอง ความล้มเหลวในชั้นหนึ่งจึงไม่ส่งคุณกลับไปบนสุดของรายการ

จดบันทึกความเป็นเพื่อนบ้านที่คุณคาดหวัง

ก่อนคำสั่ง show ใด ๆ ให้ทำรายการสั้น ๆ ว่า สโป๊กใดควรจับคู่กับฮับใด ผ่านอินเทอร์เฟซอุโมงค์ใด และในระบบอิสระ EIGRP ใด การออกแบบหลายฮับล้มเหลวในช่องว่างระหว่างฮับ และรายการจะเปลี่ยน «EIGRP พัง» เป็น «สโป๊ก 3 ไม่ลงทะเบียนกับฮับ 2» รวมซับเน็ตอุโมงค์ที่คุณคาดหวังในแต่ละลิงก์ด้วย เพราะความไม่ตรงกันของแอดเดรสระหว่างสองปลายดูเหมือนความล้มเหลวของโปรโตคอลทุกประการ เขียนรายการลงในตั๋ว เพื่อให้กะถัดไปเทียบกับการออกแบบ ไม่ใช่ภาพหน้าจอล่าสุด

ตรวจ NHRP แล้วจึงตรวจเส้นทาง multicast

เริ่มจากสถานะการลงทะเบียนและแมปปิ้งที่ฮับถืออยู่จริง สโป๊กที่ไม่มีรายการไดนามิกบนฮับยังไม่ได้ลงทะเบียน และไม่มีโปรโตคอลจัดเส้นทางใดแก้ไขได้ จากนั้นยืนยันว่าสโป๊กรับ multicast จากแอดเดรส NBMA ของฮับ ซึ่งเป็นบรรทัดแยกจากรายการ NHS

show dmvpn
show ip nhrp
show ip nhrp nhs detail
interface Tunnel0
 ip nhrp network-id 1
 ip nhrp nhs 203.0.113.1 nbma 198.51.100.1
 ip nhrp map multicast 198.51.100.1
 tunnel mode gre multipoint
 tunnel key 100

บรรทัด ip nhrp map multicast คือสิ่งที่ทำให้สโป๊กส่ง hello ไปยังฮับเป็น multicast ที่ทำสำเนาผ่านโอเวอร์เลย์ และทำให้ multicast ของฮับไปถึงสโป๊กที่ลงทะเบียนไว้ หากไม่มี unicast ผ่าน NHRP จะทำงานแต่ multicast จะไม่ทำงาน และนั่นคือการแบ่งที่ทำให้ ping ดูเหมือนหลักฐาน คู่มือ Cisco IOS XE DMVPN อธิบายพฤติกรรม multicast ของฮับและสโป๊กในแต่ละเฟส ดังนั้นจงปรับการตั้งค่าของคุณให้ตรงกับเฟสที่คุณใช้งานจริง แทนที่จะคัดลอกชิ้นส่วนจากโทโพโลยีอื่น

ตรวจสอบนโยบายอินเทอร์เฟซของ EIGRP เอง

อุโมงค์ที่ไม่อยู่ในโปรเซส EIGRP หรือเป็น passive จะไม่มีวันสร้างความเป็นเพื่อนบ้าน ไม่ว่าโอเวอร์เลย์จะแข็งแรงแค่ไหน อ่านการมีส่วนร่วมของอินเทอร์เฟซและตารางเพื่อนบ้านพร้อมกัน เพราะอันแรกอธิบายอันที่สอง

show ip eigrp interfaces detail Tunnel0
show ip eigrp neighbors detail
show run | section router eigrp
router eigrp 100
 network 10.10.0.0 0.0.0.255
 passive-interface default
 no passive-interface Tunnel0

การพิสูจน์ตัวตนและน้ำหนักเมตริกต้องตรงกันทั้งสองปลาย สายคีย์ที่โหมดผิด หรือค่า K ไม่ตรงกัน จะทำให้ hello หลุดโดยไม่มีบรรทัด syslog ชัดเจนที่ผู้รับ หากการออกแบบใช้เพื่อนบ้าน unicast ที่กำหนดค่าไว้อย่างชัดเจน ให้ทำตามโมเดลนั้นทั้งหมด แทนที่จะวางทับบนการตั้งค่า multicast จนกว่าอะไรจะขึ้นมา

แยกการขนส่ง GRE กับการป้องกัน IPsec ออกจากกัน

DMVPN ขนส่ง multicast ภายใน GRE และ IPsec ป้องกันแพ็กเก็ต GRE ไม่ใช่ multicast ภายในโดยตรง นี่คือเหตุผลที่ข้อกล่าวอ้างกว้าง ๆ ว่า IPsec ขนส่ง multicast ไม่ได้นั้นผิดสำหรับการออกแบบนี้และไร้ประโยชน์ในฐานะการวินิจฉัย ตรวจสอบโปรไฟล์ IPsec บนอุโมงค์ สมาคมความปลอดภัยของแต่ละ peer และสถานะอินเทอร์เฟซอุโมงค์เป็นข้อเท็จจริงสามข้อแยกกัน

show crypto ipsec sa peer 198.51.100.1
show interfaces Tunnel0 | include line protocol
show ip nhrp multicast

SA ที่ขึ้นอยู่และตัวนับเคลื่อนไหวในขณะที่ EIGRP ยังลงอยู่ จะพาการสอบสวนกลับขึ้นไปบนสแตก เพราะแพ็กเก็ตได้รับการป้องกันและส่งถึงแล้ว ปัญหาจึงอยู่ที่โปรโตคอลเลือกส่งแพ็กเก็ตใด

ตรวจสอบเส้นทาง ไม่ใช่แค่จำนวนเพื่อนบ้าน

เมื่อความเป็นเพื่อนบ้านเกิดขึ้นแล้ว ให้อ่านว่ามันประกาศและติดตั้งอะไร บนอุโมงค์หลายจุด split horizon และพฤติกรรม next-hop ตัดสินว่าสโป๊กจะไปถึงอีกสโป๊กผ่านฮับได้หรือไม่ และการสรุปอาจซ่อนพรีฟิกซ์ได้แม้ความสัมพันธ์เพื่อนบ้านจะสมบูรณ์

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

บันทึกการออกแบบเป็นเฟส การแมป multicast และนโยบาย EIGRP ไว้ในที่เดียว วิศวกรคนต่อไปจะต้องการการออกแบบ ไม่ใช่บทถอดเสียง