Có những lúc khi troubleshoot WAN, một dòng trạng thái Tunnel UP tạo cảm giác mọi thứ đã ổn. Nhưng trong môi trường multi-site, đó thường mới chỉ là điểm bắt đầu.
Một tunnel có thể UP trong khi route chưa học đúng. OSPF có thể đã hình thành neighbor nhưng return path lại đi sai. Và ngay cả khi ping được, business application vẫn có thể chưa usable.
Đó là lý do mình ngày càng nhìn DMVPN không phải như một feature của router, mà như một chuỗi phụ thuộc giữa underlay, overlay, routing, reachability và service.
Hub-and-Spoke chỉ là hình học. Vận hành mới là phần khó.
Trong mô hình mình từng vận hành, Head Office đóng vai trò trung tâm, còn các factory site kết nối về bằng DMVPN. Các site không chỉ có một WAN path. Mục tiêu là có khả năng duy trì kết nối khi một circuit gặp sự cố, đồng thời để dynamic routing quyết định đường đi phù hợp.
Nhìn trên diagram thì khá gọn: Hub ở trung tâm, Spoke ở các site. Nhưng khi bước vào production, mỗi đường nét trên sơ đồ lại là một nhóm failure mode khác nhau.
Underlay, Overlay và Routing không phải một thứ
Underlay trả lời câu hỏi đường truyền vật lý và ISP có đang reachable hay không. Overlay trả lời DMVPN/IPsec có hình thành được hay không. Routing trả lời network nào được học, metric nào đang được chọn, và traffic sẽ đi qua next-hop nào.
Ba lớp đó liên quan chặt chẽ, nhưng không đồng nghĩa với nhau.
Mình từng gặp case kết nối DMVPN từ factory về Head Office có tunnel nhưng OSPF không hoạt động đúng như mong đợi. Khi đó, việc nhìn duy nhất vào trạng thái IPsec sẽ dễ dẫn đến kết luận sai. Phải quay lại kiểm tra transform-set, tunnel parameter, OSPF neighbor và routing table trước khi chạm vào phần còn lại.
Vận hành thực tế bắt đầu từ vài câu lệnh rất bình thường
Những lúc cần xác nhận nhanh một site đang ở trạng thái nào, mình thường không bắt đầu bằng dashboard. Một vài câu lệnh quen thuộc đủ để dựng lại câu chuyện: tunnel có thật sự hình thành, IPsec SA có đang chuyển traffic, OSPF có Full với Hub, route từ Head Office và các site khác có được học, rồi cuối cùng traffic end-to-end có đi đến nơi hay không.
show dmvpnshow crypto ipsec sashow ip ospf neighborshow ip route ospfping / traceroute <đích kiểm tra>Điều thú vị là năm câu lệnh trên không có gì đặc biệt. Giá trị nằm ở thứ tự mình đọc chúng. Nếu tunnel chưa đúng thì chưa cần tranh luận về OSPF. Nếu OSPF đã Full nhưng route thiếu, câu hỏi chuyển sang advertisement và policy. Nếu route đã đúng mà service vẫn lỗi, lúc đó mới đi tiếp đến forward path, return path, firewall và dependency phía application.
UAT phải kiểm tra cả control plane và data plane
Trong các đợt migration và network change, checklist mình dùng không dừng ở việc thấy tunnel established. Mình kiểm tra OSPF route, khả năng reach tới router/site, rồi kéo validation đi tiếp xuống application và service thực tế.
Đây là một nguyên tắc khá giống với Firewall HA: role đã chuyển chưa có nghĩa service đã sẵn sàng. Với WAN cũng vậy, tunnel UP chưa có nghĩa user đã làm việc được.
Failover không phải là khoảnh khắc. Nó là một chuỗi chuyển trạng thái.
Khi một WAN path mất, điều mình quan tâm không chỉ là backup tunnel có lên hay không. Quan trọng hơn là routing có converge đúng thời gian chấp nhận được không, route mới có được sử dụng không, return traffic có đối xứng hợp lý không, và các service quan trọng có tiếp tục hoạt động không.
Vì vậy rollback trigger nên được xác định trước maintenance window. Nếu routing convergence hoặc service validation vượt ngưỡng chấp nhận, quyết định quay lại trạng thái an toàn phải dựa trên tiêu chí đã thống nhất, không dựa trên cảm giác “thử thêm chút nữa”.
Dual WAN chỉ có giá trị nếu failure behavior đã được hiểu
Có hai circuit không tự động tạo ra resilience. Nếu cả hai path phụ thuộc cùng một lỗi vật lý, cùng một thiết bị trung gian, hoặc routing policy khiến backup path không thực sự được sử dụng khi cần, redundancy trên sơ đồ chỉ là redundancy về số lượng.
Trong quá trình mở rộng WAN thứ hai cho các factory site, phần đáng chú ý không phải chỉ là kéo thêm circuit. Nó là việc xác nhận tunnel thứ hai, routing, failover và các dependency phía sau vẫn hoạt động như thiết kế.
Troubleshooting nên đi theo evidence, không đi theo trực giác
Với DMVPN, mình thường đi từ dưới lên. Nếu underlay không thông thì chưa có lý do để phân tích OSPF. Nếu IPsec/NHRP chưa đúng thì việc sửa application route là quá sớm. Nếu OSPF đã học route đúng mà service vẫn lỗi, lúc đó mới chuyển sang forward path, return path, firewall policy hoặc dependency phía application.
Cách này nghe có vẻ chậm hơn việc đổi vài dòng config để thử. Nhưng trong production, nó thường nhanh hơn vì mỗi thay đổi đều có giả thuyết kỹ thuật rõ ràng và blast radius được kiểm soát.
Điều mình nhớ nhất không phải DMVPN
Nhìn lại, thứ mình giữ lại từ những lần vận hành WAN multi-site không phải cú pháp cấu hình. Cú pháp có thể tra lại. Điều khó hơn là học cách đặt đúng câu hỏi:
Đường truyền đang UP, nhưng traffic có đang đi đúng đường? Tunnel đang UP, nhưng route có đúng? Route đúng, nhưng service có thực sự usable?
Đó cũng là điểm WAN Engineering gặp Resilience: không chỉ thiết kế một path hoạt động, mà phải hiểu hệ thống sẽ cư xử thế nào khi một path biến mất.
Ghi lại từ những trải nghiệm thực tế của mình trong quá trình làm Infrastructure — những câu chuyện vẫn còn tiếp tục.
Đọc tiếp theo chủ đề: High Availability không bắt đầu từ thiết bị thứ hai · Resilience không chỉ là Uptime · Selected Engineering Chapters 2023–2026