เพื่อนบ้าน EIGRP หรือทางผ่าน DMVPN? ตรวจบทบาทก่อน

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

ขั้นที่ 1: วาดบทบาททั้งสอง

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

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

ขั้นที่ 2: ตรวจว่าอุปกรณ์ตรงกลางสิ้นสุดอะไร

ถ้าเราเตอร์ตรงกลางสิ้นสุดอุโมงค์และควรสร้างความเป็นเพื่อนบ้าน EIGRP กับ spoke คำตอบจะเปลี่ยนไปทั้งหมด อุปกรณ์นั้นต้องมีพฤติกรรมการเราเตอร์ overlay ที่รองรับ และการเรียกมันว่าทางผ่านไม่ได้ลบข้อกำหนดเรื่องเพื่อนบ้านออกไป อ่านการกำหนดค่าอุโมงค์ก่อนการกำหนดค่าการเราเตอร์ คำตอบนั้นกำหนดทุกการตรวจที่ตามมา

ดังนั้นคำถามจริงข้อแรกจึงไม่ใช่จะปรับโปรโตคอลใด คำถามคือกล่องนั้นเป็น hub เป็น spoke เป็นเพียง hop ของ underlay หรือเป็นบริการ Layer 2 ที่ขนเฟรมระหว่างปลายทาง

ขั้นที่ 3: ตรวจสอบระนาบควบคุมของเพื่อนบ้าน

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

RFC 7868 อธิบาย EIGRP ว่าเป็นโปรโตคอล IP ที่มีการแลกเปลี่ยนควบคุมแบบ multicast ด้วยเหตุนี้ความสัมพันธ์แบบเพื่อนบ้านจึงไม่ใช่สิ่งที่เราเตอร์ตัวกลางจะแทนได้ด้วยการเราเตอร์แพ็กเก็ตไปยังปลายทาง ไม่การแลกเปลี่ยนควบคุมไปถึงคู่ก็ความเป็นเพื่อนบ้านไม่เกิดขึ้น

ขั้นที่ 4: ตรวจสอบว่าการขนส่งนำการแลกเปลี่ยนควบคุมไปถึง

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

บริการ Layer 2 แบบโปร่งใส อุโมงค์แบบจุดต่อจุด และคลาวด์ DMVPN แบบหลายจุดส่ง multicast ต่างกัน ปฏิบัติตามรูปแบบอินเทอร์เฟซ NHRP และ multicast ที่รองรับสำหรับสิ่งที่ปรับใช้จริง แทนที่จะถือว่าทั้งสามอย่างทำงานเหมือนกัน

ขั้นที่ 5: ออกแบบขอบเขตใหม่ถ้าเข้าร่วมไม่ได้

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

บันทึกบทบาทของแต่ละอุปกรณ์ในแผนภาพและเก็บไว้กับการกำหนดค่า RFC 7868 กำหนดการแลกเปลี่ยนโปรโตคอล และคำจำกัดความนั้นคือข้อมูลอ้างอิงว่าทำไมความสัมพันธ์แบบเพื่อนบ้านจึงจำลองด้วยการส่งต่อแบบทางผ่านไม่ได้

เมื่อความเป็นเพื่อนบ้านยังล้มเหลวหลังการตรวจทั้งห้า ผู้ต้องสงสัยที่เหลือคือคุณสมบัติของแพลตฟอร์ม เช่น การจัดการ multicast บนอินเทอร์เฟซอุโมงค์และนโยบายที่กรองโปรโตคอล 88 สิ่งเหล่านี้เป็นสาเหตุที่เฉพาะเจาะจงและทดสอบได้ และมีค่ามากกว่าการโทษเราเตอร์ตรงกลางอีกรอบ