Kiểm thử anycast service: route shift, site withdrawal và stateful traffic

RFC 4786 mô tả vận hành dịch vụ anycast và nhấn mạnh rằng thay đổi định tuyến có thể đưa các packet liên tiếp tới node khác nhau. Vì vậy cần hỏi: client nào được site nào phục vụ; thay đổi route ảnh hưởng flow đang tồn tại ra sao; và cơ chế health có rút route kịp thời khi site không còn đủ điều kiện phục vụ hay không.

Mục tiêu của phép thử là đánh giá anycast ở cấp dịch vụ, không chỉ xác nhận route tồn tại. Site được chọn theo chính sách và topology định tuyến, không nhất thiết gần client nhất về địa lý hoặc có độ trễ thấp nhất. Kết quả phải chỉ ra topology, vantage point, routing policy, workload và state model; không dùng một phép đo từ một ISP để đại diện cho toàn bộ Internet.

Lab tối thiểu có ba site cùng quảng bá một prefix anycast tới route emulator hoặc hai upstream độc lập. Mỗi site có service instance, load balancer nếu dùng và collector gắn site ID vào response. Nhiều client/vantage point phát probe từ các ASN hoặc policy domain khác nhau; route collector ghi best path và update.

Đồng bộ clock và gắn request ID end-to-end. Baseline cần lưu catchment map, AS path, RTT, packet loss, response site ID, capacity từng site và health state. Với production measurement, giữ probe rate an toàn và không gây route churn ngoài phạm vi được phép.

Khóa prefix length, origin ASN, BGP community, local preference/MED, prepending, upstream, RPKI state, health threshold, withdrawal delay và dampening. Ghi rõ DDoS mitigation hoặc traffic engineering có can thiệp route. Nếu prefix dài hơn bị lọc ở một số mạng, kết quả có thể khác theo vantage point.

Ở lớp ứng dụng, kiểm soát protocol, keepalive, retry, session affinity, token/state store, TLS resumption và connection lifetime. UDP request-response thường dễ chuyển site hơn TCP dài; QUIC connection ID có thể hỗ trợ mobility trong một số kiến trúc nhưng không tự bảo đảm state tồn tại ở site mới.

KPI định tuyến gồm withdrawal propagation, catchment shift time, path change và tỷ lệ vantage point chuyển đúng site. KPI dịch vụ gồm success rate, outage duration, latency percentile, packet loss, connection reset, duplicate transaction, state error và retry amplification. Capacity headroom của site nhận tải sau failover là điều kiện đo, không phải chú thích.

Bằng chứng tối thiểu: BGP updates/RIB snapshot, traceroute hoặc path telemetry, response site ID, health log, load-balancer/backend log và traffic-generator result. Ghép các nguồn trên cùng timeline để biết route đã đổi nhưng dịch vụ chưa sẵn sàng, hay health đã fail nhưng route chưa rút.

Pass/fail phải tách flow hiện hữu và flow mới. Một thiết kế có thể chấp nhận reset flow dài nhưng không chấp nhận giao dịch trùng; tiêu chí cần bám SLO và semantics của ứng dụng.

• Workload: DNS/UDP request ngắn · Rủi ro khi route shift: response từ site khác, cache · Phép đo chính: success, RTT, site ID · Kỳ vọng: request mới phục vụ đúng
• Workload: TCP API ngắn · Rủi ro khi route shift: reset và retry · Phép đo chính: success, retry, duplicate · Kỳ vọng: phục hồi trong budget
• Workload: TCP phiên dài · Rủi ro khi route shift: state không có ở site mới · Phép đo chính: reset, byte continuity · Kỳ vọng: hành vi được định nghĩa rõ
• Workload: QUIC · Rủi ro khi route shift: path/state phụ thuộc thiết kế · Phép đo chính: connection ID, retry · Kỳ vọng: không suy từ protocol alone
• Workload: Giao dịch stateful · Rủi ro khi route shift: duplicate hoặc lost commit · Phép đo chính: transaction ID, backend log · Kỳ vọng: idempotency được chứng minh
• Workload: Site quá tải sau failover · Rủi ro khi route shift: latency/tail loss · Phép đo chính: utilization, p95/p99 · Kỳ vọng: còn capacity headroom

Đo baseline từ mọi vantage point, sau đó thay đổi có kiểm soát một policy: prepend, community hoặc upstream preference. Ghi thời điểm BGP update, path change, site ID và ứng dụng phục hồi. Lặp lại theo direction vì forward và return path có thể bất đối xứng.

• Xác nhận cùng IP nhưng response mang site ID phân biệt được.
• Lưu best path và RTT baseline từng vantage point.
• Thay đổi một policy tại một thời điểm.
• Đo catchment shift và số vantage point không chuyển như dự kiến.
• Kiểm route leak, RPKI invalid và prefix filter trong lab.
• So sánh flow mới, flow dài và retry của client.

Gây health failure ở ứng dụng trong khi router còn sống để kiểm coupling health-to-route. Tiếp theo rút route chủ động, mất upstream, mất site và phục hồi site. Mỗi case phải đo khoảng “unhealthy nhưng còn quảng bá” và “khỏe nhưng chưa quảng bá”. Failback cần warm-up capacity trước khi nhận lại catchment.

Với stateful workload, tạo transaction ID và kiểm database/log ở cả hai site. Test sticky state, replicated state, stateless token và không chia sẻ state như bốn mode khác nhau. Thử route shift giữa request/response hoặc giữa các packet của một flow chỉ trong lab an toàn.

Tăng vantage point, route count, request rate và session duration theo bậc. Soak test route churn trong giới hạn để phát hiện flap hoặc dampening không mong muốn. Capacity test phải chứng minh site còn lại chịu được tải chuyển đến mà không làm tail latency vượt SLO.

Runbook cần điều kiện withdraw thủ công, quyền thay đổi route, OOB access, xác nhận route collector, canary vantage point và tiêu chí quảng bá lại. Rollback không chỉ “announce route”: phải xác nhận backend, state store, certificate, time sync và capacity trước failback.

Kết quả lab không đại diện toàn bộ chính sách Internet. Catchment thay đổi theo ASN, peering, time, route policy và DDoS state. Kết luận phải nêu rõ vantage point, thời gian, prefix và upstream đã quan sát.

Anycast không tự cung cấp session replication, idempotency hoặc health correctness. Nếu observation chỉ có route data mà không có site ID và transaction evidence, không thể kết luận dịch vụ end-to-end đã failover đúng.

• Anycast: nhiều node cùng quảng bá/nhận traffic cho một địa chỉ.
• Catchment: tập client hoặc nguồn traffic được định tuyến tới một site.
• Route withdrawal: rút quảng bá prefix khỏi routing domain.
• Vantage point: vị trí quan sát hoặc phát probe độc lập.
• Stateful flow: phiên phụ thuộc trạng thái được giữ tại endpoint/middlebox.
• Failback: đưa traffic về site đã phục hồi.
• Health-to-route coupling: logic nối trạng thái ứng dụng với quảng bá route.