Láng giềng EIGRP hay trung chuyển DMVPN? Hãy kiểm tra vai trò trước

Quan hệ láng giềng bị thiếu, và router ở giữa trông như nghi phạm hiển nhiên. Nó có thể vô tội. Chuyển tiếp các gói tunnel bên ngoài và tham gia giao thức định tuyến overlay là hai công việc khác nhau, và một thiết bị có thể làm việc đầu mà không làm việc sau. Hãy thực hiện năm bước kiểm tra dưới đây theo thứ tự và dừng ở bước đầu tiên thất bại.

Bước 1: vẽ hai vai trò

Vẽ quan hệ láng giềng EIGRP dự kiến như một kết nối logic giữa hai router, sau đó vẽ các router underlay mang các gói tunnel của nó. Cùng một thiết bị không nhất thiết phải xuất hiện trong cả hai danh sách, và nhầm lẫn hai danh sách là lý do phổ biến nhất khiến một router trung chuyển khỏe mạnh bị buộc tội làm hỏng láng giềng.

Router trung chuyển chuyển tiếp các gói bên ngoài bằng định tuyến IP và chính sách thông thường của nó. Nó không cần chạy giao thức được mang bên trong tunnel được bảo vệ, và không cần tiến trình EIGRP để chuyển tiếp các gói đó.

Bước 2: kiểm tra thiết bị ở giữa kết thúc cái gì

Nếu router ở giữa kết thúc tunnel và phải tạo quan hệ láng giềng EIGRP với spoke, câu trả lời thay đổi hoàn toàn. Thiết bị đó cần hành vi định tuyến overlay được hỗ trợ, và gọi nó là trung chuyển không xóa bỏ yêu cầu láng giềng. Hãy đọc cấu hình tunnel trước cấu hình định tuyến. Câu trả lời đó quyết định mọi bước kiểm tra tiếp theo.

Vì vậy câu hỏi thực sự đầu tiên không phải là điều chỉnh giao thức nào. Mà là hộp đó là hub, spoke, một bước nhảy underlay thuần túy hay một dịch vụ Layer 2 mang khung giữa các đầu cuối.

Bước 3: xác minh mặt phẳng điều khiển của láng giềng

Trên mỗi thiết bị cần trở thành láng giềng, hãy xác nhận bốn điều: thực thể EIGRP và số hệ thống tự trị, các tham số xác thực, giao diện tham gia tiến trình, và câu lệnh mạng bao phủ giao diện đó. Sự không khớp ở bất kỳ điều nào khiến láng giềng ở trạng thái xuống trong khi giao diện vẫn lên và ping vẫn hoạt động.

RFC 7868 mô tả EIGRP là giao thức IP có trao đổi điều khiển multicast, vì thế quan hệ láng giềng không phải là thứ mà router trung gian có thể thay thế bằng cách định tuyến gói tin tới đích. Hoặc trao đổi điều khiển đến được đối tác, hoặc láng giềng không hình thành.

Bước 4: xác minh rằng giao vận phân phối trao đổi điều khiển

Tiếp theo, hãy kiểm tra xem overlay có thực sự mang lưu lượng điều khiển giữa các đầu cuối dự kiến hay không. Kiểm tra ánh xạ NHRP cho đối tác và tuyến bên ngoài đi tới nó, rồi xác nhận giao diện tunnel đang lên và cho lưu lượng đi qua. Ping underlay thành công chứng minh đường đi bên ngoài tồn tại; nó không chứng minh trao đổi điều khiển của overlay đã được phân phối.

Dịch vụ Layer 2 trong suốt, tunnel điểm-tới-điểm và đám mây DMVPN đa điểm phân phối multicast theo các cách khác nhau. Hãy theo mô hình giao diện, NHRP và multicast được hỗ trợ cho những gì thực sự được triển khai thay vì giả định cả ba hành xử giống nhau.

Bước 5: thiết kế lại ranh giới nếu nó không thể tham gia

Nếu thiết bị overlay cần thiết không thể chạy giao thức, hãy thay đổi thiết kế một cách rõ ràng. Dùng giao thức hoặc mô hình trao đổi được hỗ trợ ở ranh giới đó, hoặc bố trí tunnel đầu-cuối phù hợp để các láng giềng là những đầu cuối thực sự nói chuyện với nhau. Đừng giả định rằng một tuyến tĩnh biến thiết bị không tham gia thành bộ chuyển tiếp cho mọi gói điều khiển.

Ghi lại vai trò của từng thiết bị trên sơ đồ và lưu cùng cấu hình. RFC 7868 định nghĩa trao đổi giao thức, và định nghĩa đó là căn cứ cho việc vì sao không thể mô phỏng quan hệ láng giềng bằng chuyển tiếp trung chuyển.

Khi láng giềng vẫn thất bại sau cả năm bước kiểm tra, các nghi phạm còn lại là tính năng nền tảng như xử lý multicast trên giao diện tunnel và chính sách lọc giao thức 88. Đây là những nguyên nhân cụ thể, có thể kiểm chứng, và chúng đáng giá hơn một vòng đổ lỗi nữa cho router ở giữa.