
Mục lục bài viết 10 phần
SCTP có thể duy trì một association qua nhiều địa chỉ, nhưng “multihoming đã bật” chưa chứng minh lỗi đường truyền được phát hiện đúng, traffic chuyển sang alternate path trong ngân sách hay bản tin không mất, lặp và sai thứ tự. Bài đo cần nối transport state với packet sequence và giao dịch ứng dụng.
Bài viết giúp bạn
- SCTP multihoming cần chứng minh điều gì
- Topology và failure domain
- Biến số transport phải kiểm soát
SCTP multihoming cần chứng minh điều gì
#Một SCTP endpoint có thể quảng bá nhiều transport address trong association. RFC 9260 mô tả cơ chế path management, heartbeat, retransmission và lựa chọn đích; cách ứng dụng dùng multihoming vẫn phụ thuộc implementation và cấu hình. Association ở trạng thái ESTABLISHED chỉ cho biết transport chưa đóng, không cho biết message mới đã đi qua đường dự phòng.
Tách bốn câu hỏi: địa chỉ/path có được học đúng; failure được phát hiện bằng tín hiệu nào; dữ liệu chưa xác nhận được retransmit thế nào; và ứng dụng phục hồi khi nào. Nếu chỉ ping hai địa chỉ hoặc xem counter association, bài đo bỏ sót semantic message, head-of-line theo stream và thời gian giao dịch thực.
Topology và failure domain
#Topology tối thiểu gồm hai endpoint SCTP, mỗi bên có hai địa chỉ đi qua hai switch/router và hai failure domain độc lập. Nếu hai địa chỉ cùng phụ thuộc một NIC, một switch, một VRF hoặc một uplink, kết quả không chứng minh khả năng chịu lỗi end-to-end. Thu capture gần hai endpoint và trên từng path; đồng thời lưu routing, ARP/ND, interface, firewall/NAT state.
Đặt application generator/sink có message ID, stream ID và transaction timestamp. Với SIGTRAN, telecom control hoặc ứng dụng riêng, lưu thêm application acknowledgment và state machine. Đồng bộ clock để nối thời điểm fault, heartbeat timeout, retransmission, path state change và message hợp lệ đầu tiên.

Biến số transport phải kiểm soát
#Ghi implementation/version, địa chỉ local/peer, primary path, heartbeat interval, path max retransmission, association max retransmission, RTO min/initial/max, delayed SACK, congestion control, PMTU và stream count. Không thay timer để có số đẹp mà không ghi lại; timer quá ngắn có thể tạo false failover khi jitter hoặc CPU spike.
Traffic profile phải gồm message nhỏ/lớn, ordered/unordered, nhiều stream, steady rate, burst và idle association. Khóa MTU, fragmentation, packet loss nền, latency/jitter và tải CPU. SCTP message boundary khác TCP byte stream; sink phải kiểm tra nguyên vẹn message, không chỉ tổng byte.
- Path timer — Giá trị cần lưu: heartbeat, RTO, retransmit limit; Sai lệch nếu bỏ sót: Failover nhanh/chậm không giải thích được
- Traffic — Giá trị cần lưu: rate, size, stream, ordering; Sai lệch nếu bỏ sót: Bỏ sót loss hoặc HOL theo stream
- Network — Giá trị cần lưu: MTU, latency, loss, route; Sai lệch nếu bỏ sót: Nhầm network impairment với SCTP lỗi
- Endpoint — Giá trị cần lưu: stack, OS, CPU, buffer; Sai lệch nếu bỏ sót: Kết luận sai về DUT
- Fault — Giá trị cần lưu: link, route, drop một chiều; Sai lệch nếu bỏ sót: Các cơ chế detection khác nhau
KPI và chuỗi bằng chứng
#KPI gồm path detection time, service interruption, retransmission count, message loss/duplicate/out-of-order, goodput, latency p50/p95/p99, association survival và thời gian trở về steady state. Đo riêng traffic đã gửi trước fault, đang in-flight và gửi sau fault. Với nhiều stream, báo kết quả theo stream thay vì chỉ cộng toàn association.
Chuỗi bằng chứng cần cùng run ID: cấu hình timer; packet cuối trên path cũ; marker fault; heartbeat/retransmission; thay đổi path state; packet đầu trên alternate; SACK; application acknowledgment. Pass/fail nên quy định tối đa số message không hoàn tất và thời gian service restoration, không chỉ “association không reset”.
Ma trận kịch bản quyết định
#- Baseline — Fault: Không lỗi; Điều cần chứng minh: Message đúng và timer ổn định; Bằng chứng: sequence, SACK, latency
- Link down — Fault: Mất vật lý primary; Điều cần chứng minh: Chuyển path trong budget; Bằng chứng: event + pcap hai path
- Silent drop — Fault: Drop hai chiều; Điều cần chứng minh: Heartbeat/RTO phát hiện; Bằng chứng: retry và path state
- Asymmetric — Fault: Drop một chiều; Điều cần chứng minh: Không loop hoặc stall kéo dài; Bằng chứng: capture hai hướng
- Route withdraw — Fault: Mất next hop; Điều cần chứng minh: Network và SCTP hội tụ; Bằng chứng: RIB/FIB + message
- Alternate degraded — Fault: Thêm loss/jitter; Điều cần chứng minh: Service giữ trong SLO; Bằng chứng: tail latency, retransmit
- Endpoint restart — Fault: Mất peer; Điều cần chứng minh: Association xử lý đúng; Bằng chứng: INIT/ABORT/reconnect
- Lỗi kép — Fault: Mất cả hai path; Điều cần chứng minh: Fail closed và báo lỗi rõ; Bằng chứng: alarm + app timeout
Test plan path failover
#Bắt đầu bằng single-path baseline cho từng đường, sau đó association dual-homed ở tải thấp. Xác nhận địa chỉ và primary path từ cả packet trace lẫn endpoint state. Ramp traffic tới các mức đã định, giữ steady state, rồi gây từng fault riêng: physical link, ACL blackhole, route withdrawal và impairment có kiểm soát.
Lặp ở ba thời điểm: association idle, giữa steady traffic và đúng lúc burst. Thử ordered/unordered cùng nhiều stream để thấy phạm vi ảnh hưởng. Mỗi lượt cần reset counter, dùng seed/profile giống nhau và chạy đủ lâu sau recovery để phát hiện retransmission muộn hoặc path flapping.

Recovery, failback và lỗi kép
#Sau khi primary trở lại, xác nhận path được probing, đánh dấu active và xử lý theo policy; không mặc định traffic sẽ failback ngay. Failback quá sớm có thể gây oscillation nếu link chập chờn. Thử flap theo chu kỳ và kiểm tra route/neighbor cache, congestion window, PMTU cùng counter không bị stale.
Với lỗi kép, tiêu chí tốt không phải “giữ association vô hạn”. Ứng dụng phải nhận timeout/alarm có giới hạn, dừng gửi không kiểm soát và reconnect theo backoff. Nếu thay địa chỉ động thuộc phạm vi, kiểm tra RFC 5061 theo đúng support và security policy; không suy từ SCTP base protocol rằng mọi stack hỗ trợ ASCONF.
Checklist nghiệm thu
#- Xác nhận hai path không chung failure domain ngoài phạm vi chấp nhận.
- Ghi stack/OS/version, địa chỉ, timer, stream và buffer.
- Baseline từng path trước khi thử multihoming.
- Dùng message ID và application acknowledgment.
- Đồng bộ clock, đặt fault marker và capture hai hướng.
- Thử link down, silent drop, asymmetric loss và route withdrawal.
- Đo detection, service restoration, loss, duplicate và ordering.
- Lặp với idle, steady, burst và alternate path suy giảm.
- Thử recovery, flap, failback policy và lỗi kép.
- Lưu raw pcap, state dump, config và verdict theo run.
Giới hạn của kết luận
#Kết quả chỉ áp dụng cho SCTP stack, timer, topology, routing, firewall và workload đã đo. Multihoming không tự tạo hai failure domain và không thay thế HA ở application/state layer. Một association sống qua lỗi link không chứng minh database hoặc peer service vẫn đúng.
Không so sánh “failover time” giữa hai hệ thống nếu fault trigger, heartbeat/RTO, tải và mốc service restoration khác nhau. Lab packet loss sạch cũng không đại diện WAN có reordering, congestion và impairment đồng thời.
Khái niệm cần nhớ
#- Association: Quan hệ transport SCTP giữa hai endpoint.
- Transport address: Cặp địa chỉ IP/port thuộc endpoint.
- Primary path: Đích ưu tiên để gửi dữ liệu theo policy/implementation.
- Heartbeat: Probe quản lý reachability của path.
- SACK: Selective Acknowledgment của SCTP.
- TSN: Transmission Sequence Number dùng theo dõi DATA chunk.
- Service restoration: Thời điểm message/giao dịch hợp lệ hoạt động lại.
Khái niệm cần nhớ
- DUT / SUT
- Thiết bị hoặc toàn bộ hệ thống đang là đối tượng của bài kiểm thử.
- Steady state
- Giai đoạn tải đã ổn định và đủ điều kiện để lấy số liệu đại diện.
- Pass / fail
- Kết luận dựa trên ngưỡng đã thống nhất, luôn đi cùng topology, cấu hình và điều kiện đo.
TÀI LIỆU ĐỐI CHIẾUTài liệu tham khảo3 nguồn +
Nội dung được biên soạn độc lập, theo hướng vendor-neutral và đối chiếu các tài liệu gốc dưới đây. Tính năng sản phẩm cần được kiểm tra lại theo phiên bản đang sử dụng.
NetVali ưu tiên nguồn tiêu chuẩn và tài liệu chính thức; phân biệt khuyến nghị triển khai với yêu cầu của tiêu chuẩn; không công bố thông số sản phẩm chưa gắn với phiên bản và điều kiện đo.
