Có những lúc troubleshoot WAN, chỉ cần thấy một dòng Tunnel UP là cảm giác nhẹ đi khá nhiều. Nhưng trong môi trường multi-site, đó thường mới chỉ là bước đầu tiên.
Tunnel có thể UP trong khi route chưa học đúng. OSPF có thể đã có neighbor nhưng return path lại đi sai. Và kể cả ping được, application phía sau vẫn có thể chưa dùng được.
Vì vậy khi xử lý DMVPN, mình thường tách câu chuyện thành từng lớp: underlay, overlay, routing, reachability và service. Làm như vậy giúp mình biết nên kiểm tra ở đâu trước thay vì đổi config theo cảm giác.
Hub-and-Spoke nhìn đơn giản hơn lúc vận hành thật
Trong mô hình mình từng vận hành, Head Office đóng vai trò Hub, còn các factory site kết nối về bằng DMVPN. Các site có nhiều hơn một WAN path để duy trì kết nối khi một circuit gặp vấn đề, còn OSPF phụ trách việc học và chọn route.
Trên diagram chỉ có vài đường nối. Nhưng mỗi đường lại có những kiểu lỗi khác nhau: ISP mất kết nối, IPsec/NHRP chưa đúng, OSPF không Full, route không được quảng bá, hoặc traffic đi được một chiều nhưng return path sai.
Underlay, Overlay và Routing là ba chuyện khác nhau
Underlay trả lời ISP và đường truyền có 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 rất chặt, nhưng không thể dùng trạng thái của lớp này để kết luận lớp kia chắc chắn ổn.
Mình từng gặp case tunnel DMVPN từ factory về Head Office vẫn hiện lên nhưng OSPF không hoạt động đúng như mong đợi. Khi đó nếu chỉ nhìn IPsec status thì rất dễ đi sai hướng. Phải quay lại transform-set, tunnel parameter, OSPF neighbor và routing table rồi mới đi tiếp.
Một vài câu lệnh quen thuộc vẫn là thứ mình dùng đầu tiên
Khi cần xác nhận nhanh một site đang ở trạng thái nào, mình thường bắt đầu từ CLI. Không có command nào đặc biệt, nhưng thứ tự kiểm tra giúp dựng lại khá nhanh câu chuyện đang xảy ra.
show dmvpnshow crypto ipsec sashow ip ospf neighborshow ip route ospfping / traceroute <đích kiểm tra>Giá trị không nằm ở bản thân năm câu lệnh này mà ở thứ tự đọ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 không nên dừng ở chữ Established
Trong network change, mình không muốn checklist kết thúc ở việc tunnel đã established. Sau đó vẫn cần nhìn OSPF route, reachability giữa các site và cuối cùng là application hoặc service mà người dùng thực sự cần.
Điểm này 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 là cả một chuỗi chứ không phải một khoảnh khắc
Khi một WAN path mất, mình không chỉ nhìn backup tunnel có lên hay không. Mình còn muốn biết OSPF converge mất bao lâu, route mới có thực sự được sử dụng không, return traffic có hợp lý không và các service quan trọng có tiếp tục hoạt động không.
Nếu đây là một change có maintenance window, rollback trigger cũng nên được chốt từ trước. Khi routing convergence hoặc service validation vượt ngưỡng chấp nhận được, quyết định quay lại trạng thái cũ nên dựa trên tiêu chí đã thống nhất, không phải cảm giác “thử thêm chút nữa”.
Dual WAN chưa chắc đã là dự phòng thật
Có hai circuit không tự động tạo ra khả năng chịu lỗi. Nếu hai path vẫn đi qua cùng một điểm vật lý, cùng thiết bị trung gian, hoặc routing policy khiến backup path không được dùng khi cần, redundancy trên sơ đồ chưa nói lên nhiều.
Khi mở rộng WAN thứ hai cho các factory site, phần mình quan tâm không chỉ là circuit mới đã lên. Tunnel thứ hai, routing, failover và dependency phía sau đều cần được kiểm tra bằng traffic thực tế.
Khi troubleshoot, mình cố đi theo evidence
Với DMVPN, mình thường đi từ dưới lên. Underlay chưa thông thì chưa cần phân tích OSPF. IPsec/NHRP chưa đúng thì chưa nên sửa application route. OSPF đã học route đúng mà service vẫn lỗi thì mới chuyển sang forward path, return path, firewall policy hoặc dependency phía application.
Cách này có vẻ chậm hơn việc đổi vài dòng config để thử, nhưng trong production thường lại nhanh hơn vì mỗi thay đổi đều có lý do rõ ràng và dễ quay lại hơn nếu giả thuyết sai.
Điều mình nhớ nhất không phải cú pháp DMVPN
Cú pháp có thể tra lại. Thứ mình giữ lâu hơn là cách đặt câu hỏi theo từng lớp:
Đường truyền đang UP, nhưng traffic có đi đúng đường? Tunnel đang UP, nhưng route có đúng? Route đúng, nhưng service có thực sự dùng được?
Những câu hỏi đó giúp mình tránh kết luận quá sớm chỉ vì một status trên thiết bị đang xanh.
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 · Một vài dấu mốc Infrastructure 2023–2026