Chuyển đổi dự phòng WAN trong DMVPN: chính sách tuyến hay đóng tunnel?

Một hub DMVPN với hai WAN chuyển sang dự phòng theo một trong hai cách, và khác biệt lớn hơn vẻ ngoài của nó. Một cách thay đổi hop kế tiếp mà chính sách tuyến chọn, nên gói tin vẫn chảy và chỉ lối ra của chúng thay đổi. Cách kia đóng tunnel về mặt quản trị, kéo theo mọi dịch vụ trên giao diện đó xuống. Cả hai đều có thể đúng, vì chúng trả lời những câu hỏi khác nhau.

Quyết định đến trước cấu hình

Ba điều kiện quyết định điều này thay bạn. Có thứ gì khác phụ thuộc vào việc giao diện tunnel đang hoạt động, như một hồ sơ DMVPN thứ hai hoặc một trình giám sát đọc trạng thái của nó? Liệu lưu lượng phải chuyển dự phòng có mang chính sách riêng của nó, hay dựa vào bảng định tuyến toàn cục? Và người vận hành cần một thay đổi trạng thái không thể nhầm lẫn, hay một lần chuyển đường lặng lẽ là chấp nhận được? Trả lời ba câu đó thì lựa chọn thường tự hình thành.

Nếu việc đóng tunnel sẽ kéo các dịch vụ đang chạy xuống, chính sách tuyến là hành động nhỏ hơn. Nếu yêu cầu là tunnel không được tồn tại khi WAN chính đang xuống, không mục chính sách nào diễn đạt được điều đó.

Hãy viết câu trả lời ra, vì cấu hình là phần dễ.

Chính sách tuyến thực sự thay đổi điều gì

Với định tuyến dựa trên chính sách, một đối tượng được theo dõi có thể điều khiển hop kế tiếp. Mục trong bảng tuyến nêu một hop kế tiếp ứng viên và đối tượng được theo dõi phải hoạt động để nó được dùng, và trạng thái theo dõi đó đến từ một đầu dò IP SLA. Khi đối tượng xuống, mục này ngừng khớp và gói tin được mục kế tiếp hoặc bảng định tuyến thông thường đánh giá.

Chi tiết cuối này khiến người ta ngạc nhiên: một chính sách ngừng chọn hop kế tiếp thường cho phép định tuyến bình thường thay vì chặn lưu lượng. Nếu bạn cần một lỗ đen khi hỏng, bạn phải tự viết một cái.

Cú pháp khác nhau giữa các nền tảng và phiên bản, nên hãy xem hướng dẫn cho phiên bản bạn thực sự chạy.

Đóng tunnel thay đổi điều gì

Đóng một giao diện thay đổi trạng thái quản trị. Mọi tunnel, tuyến và phiên phụ thuộc vào nó đều xuống cùng lúc, đúng là điều bạn muốn nếu tunnel là thứ phải biến mất. Một applet EEM cũng biến sự cố WAN thành một lần gián đoạn bao gồm cả những dịch vụ không liên quan theo cách đó.

Nếu chọn con đường này, hãy giới hạn applet trong một giao diện và một kích hoạt, lưu trạng thái quản trị trước đó, định nghĩa hành động khôi phục và bảo đảm các lần flap lặp lại không thể đẩy nó vào vòng lặp.

Một lệnh khôi phục được mã hóa cứng cũng có thể ghi đè một lần đóng bảo trì do người khác thực hiện.

Hãy để đầu dò đi theo con đường bạn nghĩ

Một đầu dò đi theo tuyến tốt nhất hiện tại sẽ chuyển sang WAN dự phòng cùng mọi thứ khác, rồi báo cáo tuyến chính khỏe mạnh vì nó không còn dùng tuyến đó nữa.

Ghim đầu dò vào giao diện hoặc địa chỉ nguồn của con đường bạn đang kiểm tra. Cũng hãy xem nó nhắm tới đâu, vì đến được hop kế tiếp của nhà cung cấp chứng minh ít hơn đến được dịch vụ mà tunnel tồn tại vì nó. Đặt độ trễ lên và xuống một cách có chủ đích: độ trễ xuống ngắn phản ứng nhanh và flap, còn độ trễ dài chịu được các dao động nhỏ và che giấu hỏng hóc thật. Hướng dẫn của Cisco về theo dõi và định tuyến dựa trên chính sách trong IOS XE ghi lại các tổ hợp được hỗ trợ, và bộ tính năng trên nền tảng của bạn quyết định bạn dùng được những tổ hợp nào.

Ghi cả hai giá trị độ trễ bên cạnh đối tượng được theo dõi, nếu không sẽ không ai biết vì sao nó hành xử như vậy.

Quyết định khôi phục, rồi kiểm chứng

Khôi phục xứng đáng có quyết định riêng. Một liên kết liên tục vượt ngưỡng có thể chuyển phiên thường xuyên hơn một liên kết đã hỏng rõ ràng, và mỗi lần chuyển đều tốn chi phí thương lượng lại khóa và thử lại của ứng dụng. Hãy chọn một yêu cầu ổn định và để độ trễ diễn đạt nó. Sau đó kiểm chứng trong một cửa sổ thay đổi với đường đi của đầu dò hiển thị: tuyến được chọn, đường của đối tác bên ngoài và điều ứng dụng thực sự đã làm.

Nếu chuyển dự phòng hoạt động nhưng ứng dụng vẫn hỏng, vấn đề nằm trên lớp định tuyến và không lượng theo dõi nào sửa được.

Hãy giữ bằng chứng từ cửa sổ đó, vì thay đổi tiếp theo sẽ được so với chúng.