Kiểm thử SD-WAN path steering và failover: từ SLA probe đến trải nghiệm ứng dụng

Cần trả lời ít nhất bốn câu hỏi: SD-WAN phát hiện vi phạm SLA khi nào; application flow hiện hữu có được chuyển hay chỉ flow mới; bao nhiêu packet bị mất trong quá trình; và hệ thống có quay lại đường ưu tiên một cách ổn định khi chất lượng hồi phục. Phải phân biệt hard failure với brownout, vì mất link thường dễ phát hiện hơn latency hoặc loss tăng dần.

Phạm vi phải ghi rõ overlay, loại underlay, cơ chế probe, chính sách theo application class, encryption overhead và vai trò của controller. Không dùng trạng thái “tunnel up” như bằng chứng duy nhất cho chất lượng ứng dụng.

Topology khuyến nghị gồm hai SD-WAN edge, tối thiểu hai underlay độc lập, bộ network emulator trên từng đường, client/server ứng dụng và hệ thống capture hai phía. Nếu dịch vụ đi qua cloud security hoặc hub, thêm đúng hop đó thay vì mô phỏng bằng một đường trực tiếp.

Chèn latency, jitter, packet loss, reorder và bandwidth limit riêng trên từng hướng. Đo một chiều nếu đồng hồ đủ chính xác; nếu không, công bố dùng round-trip measurement. MEF 105 mô tả performance monitoring và service readiness cho SD-WAN, nhưng ngưỡng pass/fail vẫn phải ánh xạ tới SLA và ứng dụng cụ thể.

Tạo tối thiểu ba class: real-time UDP nhạy jitter/loss, transactional TCP hoặc HTTPS nhạy latency, và bulk transfer nhạy throughput. Ghi rõ packet size, session rate, concurrency, DSCP, duration và tỷ lệ flow dài/ngắn. Probe traffic phải được đo riêng để tránh nó bị ưu tiên khác data traffic.

Khóa firmware, policy version, routing, NAT, MTU, encryption, QoS queue, bandwidth và background load. Với dynamic path selection, seed hoặc thứ tự sự kiện cần lặp được. Đừng thay loss và latency cùng lúc trong ca dùng để xác định ngưỡng.

Chuỗi thời gian nên có: thời điểm impairment bắt đầu, SLA probe vượt ngưỡng, edge đổi trạng thái, route/policy được chọn, packet đầu tiên qua path mới và ứng dụng ổn định. Từ đó tính detection time, decision time, switchover time, stabilization time và tổng service interruption.

KPI end-to-end gồm packet loss, latency, jitter/IPDV, reorder, throughput goodput, transaction success rate, MOS hoặc application-specific score khi thích hợp. Thu controller event, edge log, packet capture, probe telemetry và metrics ứng dụng trên cùng timeline.

Mỗi dòng cần ngưỡng trước thử nghiệm. Nếu policy chỉ áp dụng cho flow mới, tiêu chí phải phản ánh thiết kế đó và không coi flow cũ không chuyển là lỗi.

• Sự kiện: Link down · Traffic class: Tất cả · Kỳ vọng: Chuyển sang path còn sống · Bằng chứng pass: Interruption dưới ngưỡng, không loop
• Sự kiện: Latency vượt SLA · Traffic class: Transactional · Kỳ vọng: Chuyển theo policy · Bằng chứng pass: Probe và application cùng xác nhận
• Sự kiện: Jitter tăng · Traffic class: Real-time · Kỳ vọng: Chọn path phù hợp hơn · Bằng chứng pass: Loss/jitter sau chuyển đạt ngưỡng
• Sự kiện: Loss tăng dần · Traffic class: Bulk/real-time · Kỳ vọng: Không flapping · Bằng chứng pass: Hysteresis và hold-down đúng
• Sự kiện: Path hồi phục · Traffic class: Tất cả · Kỳ vọng: Failback có kiểm soát · Bằng chứng pass: Không reset phiên ngoài tiêu chí
• Sự kiện: Cả hai path xấu · Traffic class: Tất cả · Kỳ vọng: Degraded state rõ ràng · Bằng chứng pass: Alarm đúng, không báo “healthy”

Chạy baseline khi hai path tốt, sau đó đưa một metric vượt ngưỡng theo bước nhỏ. Giữ ở trạng thái xấu đủ lâu để quan sát hold timer, phục hồi về vùng giữa ngưỡng vào/ra để kiểm tra hysteresis, rồi phục hồi hoàn toàn. Lặp với sự kiện ngắn hơn detection window để xác nhận hệ thống không chuyển đường quá mức.

Đối với hard failure, thử physical link down, next-hop loss, tunnel black hole và upstream reachability loss; chúng có thể kích hoạt cơ chế khác nhau. Với failback, theo dõi session reset, packet reordering và throughput transient.

Tăng số site, tunnel, policy và concurrent flows đến quy mô mục tiêu. Brownout nên gồm microburst loss, latency theo chu kỳ và congestion theo một chiều. Kết quả ở một branch không chứng minh controller xử lý đồng thời hàng trăm branch cùng alarm.

Thử controller mất kết nối nhưng data plane còn hoạt động, controller restart và configuration push trong lúc underlay suy giảm. Ghi rõ chức năng nào autonomous tại edge và chức năng nào phụ thuộc control plane; đây là hành vi theo sản phẩm/phiên bản, không nên suy diễn.

• Chốt SLA theo từng application class.
• Xác minh topology thật, MTU, NAT và encryption overhead.
• Đồng bộ đồng hồ và gắn correlation ID cho sự kiện.
• Chạy baseline ít nhất ba lần.
• Thay một impairment mỗi ca để tìm ngưỡng.
• Thử hard failure, brownout, recovery và flapping.
• Đối chiếu probe telemetry với packet capture và application KPI.
• Thử flow mới và flow đang tồn tại.
• Lặp ở background load và quy mô mục tiêu.
• Lưu policy version, log, pcap và báo cáo pass/fail.

Kết quả phụ thuộc vào firmware, probe interval, policy, underlay, đường đi Internet và loại ứng dụng. Network emulator tạo điều kiện lặp lại nhưng không mô phỏng đầy đủ route churn hoặc congestion phân tán trên Internet. MOS tổng hợp không thay cho giao dịch thực.

Không so sánh hai giải pháp nếu topology, probe semantics hoặc traffic classification khác nhau. Một hệ thống chuyển nhanh có thể tạo reordering lớn; một hệ thống chuyển chậm hơn có thể giữ phiên tốt hơn. Kết luận phải gắn với KPI ưu tiên của dịch vụ.