DMVPN giai đoạn 3: đọc đường tắt theo cả hai chiều

Bạn thấy một ping đi từ spoke sang spoke, nó đi đường dài qua hub, và cái thứ hai đi trực tiếp. Thật dễ xiêu lòng khi tuyên bố đường tắt đã hoạt động tại thời điểm đó. Kết luận đó chỉ đúng một nửa. Đường đi có thể là đường tắt trong khi đường về vẫn đi qua hub, và trạng thái chứng minh mỗi chiều là trạng thái khác nhau. Đi qua cả hai chiều và đọc ba bảng trước khi chấp nhận thiết kế là khỏe mạnh.

Bắt đầu từ đường đi của gói tin mà bạn thực sự thấy

Bắt đầu tại một spoke với đích đến lẽ ra phải trực tiếp. Theo dõi gói tin đầu tiên: nó đi theo tuyến của spoke về phía hub, vì chưa có đường tắt nào. Hub chuyển tiếp gói tin và, trong thiết kế giai đoạn 3, còn gửi một chuyển hướng tới nguồn rằng có đường tốt hơn.

Chuyển hướng đó là yếu tố kích hoạt, không phải bằng chứng. Nó nói rằng hub đã thấy lưu lượng có thể tối ưu. Nó không nói rằng nguồn đã dựng đường tắt, rằng đích đã trả lời phân giải, hay rằng đường phản hồi có dùng nó.

Vì vậy quan sát hữu ích đầu tiên là trước và sau: luồng đầu tiên qua hub, luồng sau đó đi trực tiếp.

Ba trạng thái trông như một đường hầm

Đường tắt phụ thuộc vào ba phần trạng thái, và mỗi phần có thời gian sống và lệnh riêng.

Một mục trong bộ nhớ đệm NHRP ánh xạ địa chỉ overlay sang địa chỉ vận chuyển NBMA. Tuyến hoặc đường tắt quyết định một đích nội bộ được chuyển tiếp đi đâu. Một liên kết IPsec bảo vệ bất kỳ lưu lượng nào phát sinh. Một phản hồi thiếu có thể đến từ bất kỳ cái nào trong ba, và các lệnh cho bạn biết cái nào thiếu.

Hãy đọc chúng theo thứ tự đó, vì ánh xạ thiếu khiến hai cái còn lại không đáng quan tâm.

Đi qua yêu cầu và phản hồi riêng rẽ

Từ spoke A, yêu cầu phân giải và xem cái gì trả về. Yêu cầu đi qua đường chuyển tiếp NHRP được hỗ trợ, và đích có thể trả lời trực tiếp thay vì qua hub. Sự bất đối xứng đó là bình thường, và đó là lý do phản hồi là nửa thú vị của cuộc trao đổi.

Giờ đảo vai. Gửi từ B sang A và lặp lại ba lần đọc như cũ. Một thiết kế tạo đường tắt cho một chiều mà không cho chiều kia là không đối xứng, và sự bất đối xứng thường đến từ một tiền tố thiếu ở một bên hoặc từ một phân giải không bao giờ nhận được phản hồi.

Phản hồi của đối tác không nhất thiết phải đi qua hub chỉ vì yêu cầu đã đi qua đó. Đừng đọc đó là lỗi và đừng bắt đầu truy tìm một sự cố định tuyến không tồn tại.

Đọc chuyển hướng của hub, không chỉ tuyến của nó

Bảng tuyến của hub cho bạn biết hub sẽ gửi gói tin đi đâu. Chuyển hướng cho bạn biết hub đã yêu cầu nguồn làm gì về việc đó. Đó là những sự thật khác nhau, và một hub có tuyến đúng nhưng không gửi chuyển hướng sẽ giữ mọi luồng trên đường dài vô thời hạn. Kiểm tra các sự kiện NHRP của hub và xác nhận rằng chuyển hướng được tạo cho lưu lượng bạn quan tâm.

Giai đoạn 3 cũng thay đổi ý nghĩa của việc tổng hợp tuyến. Với hành vi đường tắt, các spoke không cần toàn bộ tập tuyến từ xa cụ thể mà thiết kế giai đoạn 2 từng mong đợi, nên một tuyến đã tổng hợp tại spoke không tự động là một mạng bị thiếu. Xác nhận giai đoạn và chính sách định tuyến trước khi đọc bản tổng hợp là lỗi.

Chính một hiểu lầm này tạo ra nhiều phiếu DMVPN hơn bất cứ điều gì khác.

Ghi lại kết luận như một đối tượng bị thiếu

Kết thúc bằng một luồng ứng dụng được cấp phép và phản hồi của nó, và ghi chú cho từng chiều xem nó có dùng đường trực tiếp không. Sau đó viết kết luận như đối tượng đã thiếu: một ánh xạ, một đường tắt chuyển tiếp, một liên kết bảo vệ hoặc một phản hồi ứng dụng.

Quan hệ láng giềng định tuyến và một liên kết bảo mật chia sẻ là bằng chứng về sức khỏe, không phải bằng chứng về đường đi. Cả hai có thể hoàn hảo trong khi mọi gói tin vẫn đi vòng đường dài. Kiểm tra quyết định chuyển tiếp trước, rồi đến liên kết mang nó. Thứ tự quan trọng, vì liên kết vẫn hình thành dù thế nào.

Thói quen đó trả công ở phiếu tiếp theo. «Đường hầm đã lên nhưng chậm» trở thành «B không có đường tắt tới máy chủ của A», và câu thứ hai là một sửa chữa năm phút. Giữ đầu ra của lệnh cùng với kết luận, và để hướng dẫn giai đoạn 3 của nhà cung cấp bên cạnh.