
Mục lục bài viết 10 phần
STAMP và TWAMP có thể tạo số liệu latency và packet loss liên tục mà không cần mirror toàn bộ lưu lượng. Nhưng một biểu đồ đẹp chưa chứng minh dịch vụ tốt: phiên đo có thể đi khác đường ứng dụng, reflector có thể xử lý chậm, đồng hồ có thể lệch và chính probe có thể bị QoS ưu tiên. Test plan dưới đây biến phép đo chủ động thành bằng chứng có điều kiện, có baseline và có pass/fail.
Bài viết giúp bạn
- Câu hỏi kỹ thuật cần trả lời
- STAMP và TWAMP khác nhau ở đâu
- Topology và điều kiện đo
Câu hỏi kỹ thuật cần trả lời
#Đừng bắt đầu bằng câu hỏi “thiết bị có hỗ trợ STAMP không”. Hãy bắt đầu bằng dịch vụ nào đang được bảo vệ, hướng nào quan trọng, SLA áp dụng cho one-way hay round-trip delay, và phép đo cần phát hiện suy giảm trong bao lâu. Cùng một cặp endpoint có thể cho kết quả khác khi probe dùng DSCP khác ứng dụng hoặc băm sang ECMP member khác.
Một mục tiêu tốt có dạng: “phát hiện trong 30 giây khi p95 round-trip delay của lớp AF31 tăng hơn baseline 20 ms trong ba cửa sổ liên tiếp, đồng thời lưu route, counter và timestamp để khoanh vùng”. Mục tiêu này quy định được cadence, traffic class, aggregation và evidence.
STAMP và TWAMP khác nhau ở đâu
#TWAMP theo RFC 5357 gồm kiến trúc control và test, phù hợp khi cần thiết lập phiên và quản lý trạng thái theo mô hình chuẩn. STAMP theo RFC 8762 đơn giản hóa phép đo hai chiều, dùng Session-Sender và Session-Reflector; RFC 8972 mô tả các extension timestamp và error estimation hữu ích khi phân tích sai số.
Không nên suy “STAMP mới hơn nên luôn tốt hơn”. Khả năng thực tế phụ thuộc implementation: authentication, mode timestamp, VRF, DSCP, scale session, telemetry export và cách thiết bị xử lý reflector trong data plane hay control plane. Những điểm này phải gắn với model, phiên bản và cấu hình.
Topology và điều kiện đo
#Topology tối thiểu gồm sender, reflector, DUT/SUT và một điểm quan sát độc lập. Với mạng ECMP, chạy nhiều flow identity hoặc UDP source port có kiểm soát để biết kết quả đại diện cho một member hay cả tập đường. Với mạng bất đối xứng, thu route/telemetry hai hướng; round-trip time không cho biết nửa đường nào tăng delay.
Thiết lập ba lớp thử: direct baseline không qua DUT; service path ở tải nền ổn định; và service path khi đưa lỗi có chủ đích. Ghi MTU, DSCP, rate probe, payload length, VRF, policy routing, NAT, queue profile và thời gian warm-up.

Biến số phải kiểm soát
#Đồng bộ thời gian là điều kiện bắt buộc nếu kết luận one-way delay. Lưu trạng thái PTP/NTP, offset, holdover và nguồn clock cùng thời điểm đo. Nếu không chứng minh được clock quality, chỉ nên dùng round-trip metric hoặc ghi one-way là chỉ báo tương đối.
Các biến khác gồm probe rate, burst, kích thước gói, padding, DSCP rewrite, queue occupancy, CPU của reflector, hardware timestamp, packet reordering và interval tổng hợp. Thay từng biến một; nếu đồng thời tăng tải và đổi DSCP, kết quả không còn chỉ ra nguyên nhân.
- Clock offset — Rủi ro nếu không khóa: One-way delay giả; Bằng chứng cần lưu: PTP/NTP state, offset time series
- ECMP hash — Rủi ro nếu không khóa: Probe khác đường ứng dụng; Bằng chứng cần lưu: 5-tuple, route/flow telemetry
- DSCP/queue — Rủi ro nếu không khóa: Probe được ưu tiên hoặc hạ lớp; Bằng chứng cần lưu: Packet capture, queue counter
- Reflector load — Rủi ro nếu không khóa: Processing delay bị coi là network delay; Bằng chứng cần lưu: CPU, punt/drop counter
- Probe cadence — Rủi ro nếu không khóa: Bỏ lỡ microburst hoặc tự tạo tải; Bằng chứng cần lưu: Tx schedule, interface utilization
KPI và bằng chứng đầu ra
#KPI cốt lõi gồm sent/received count, loss ratio, minimum/median/p95/p99 delay, delay variation, reordering và detection time. Đối với failover, đo riêng failure detection, route convergence và service restoration; không gộp chúng thành một số “convergence”.
Mỗi kết luận cần bộ ba bằng chứng: kết quả probe thô, trạng thái đường đi và dữ liệu độc lập như packet capture hoặc interface/queue counter. Lưu cấu hình generator/reflector, phiên bản firmware và seed/flow identity để lần chạy sau tái tạo được.
Ma trận quyết định phương pháp đo
#- SLA round-trip — Phương pháp ưu tiên: STAMP hoặc TWAMP; Điều kiện: Cùng traffic class, route đã biết; Không nên kết luận: One-way bottleneck
- One-way delay — Phương pháp ưu tiên: Timestamp hai đầu; Điều kiện: Clock offset được chứng minh; Không nên kết luận: Độ trễ tuyệt đối khi clock mất lock
- ECMP coverage — Phương pháp ưu tiên: Nhiều session/flow identity; Điều kiện: Mapping member được lưu; Không nên kết luận: Toàn fabric từ một flow
- Microburst — Phương pháp ưu tiên: Probe cadence cao + queue telemetry; Điều kiện: Reflector đủ năng lực; Không nên kết luận: Không có burst chỉ vì probe không thấy
- Failover — Phương pháp ưu tiên: Probe liên tục + route event; Điều kiện: Clock và event correlation; Không nên kết luận: Control-plane convergence = service restoration
Test plan từng bước
#1. Chốt service intent, traffic class và ngưỡng pass/fail trước khi chạy. 2. Kiểm kê model, software, mode timestamp và giới hạn session của sender/reflector. 3. Đo direct baseline ở ba payload size; xác nhận loss bằng 0 trong điều kiện lab bình thường. 4. Đưa DUT vào topology, giữ nguyên traffic profile và warm-up. 5. Chạy low-rate probe để xác nhận route, DSCP và timestamp; sau đó tăng cadence theo use case. 6. Tạo cross traffic theo nhiều frame size và IMIX; ghi queue occupancy. 7. Thử impairment riêng lẻ: delay, jitter, packet loss, reordering và duplication. 8. Thử link/node failure; đo detection, convergence và restoration từ cùng trục thời gian. 9. Lặp tối thiểu ba lần, báo median và worst observed thay vì chỉ chọn lần đẹp. 10. Xuất raw result, config snapshot, route state, counter và capture vào cùng test record.

Runbook khi số liệu bất thường
#Khi latency tăng nhưng queue không tăng, kiểm tra route change, reflector CPU và clock trước. Khi chỉ một DSCP xấu, so sánh rewrite và scheduler. Khi loss xuất hiện theo chu kỳ, đối chiếu probe cadence với telemetry polling, control-plane task và microburst. Khi sender báo loss nhưng capture ở reflector thấy đủ gói, kiểm tra sequence processing và export pipeline.
Checklist xử lý: khóa lại 5-tuple; giảm probe rate; chạy reverse direction; đối chiếu hardware counter; kiểm tra clock state; lặp direct baseline; sau cùng mới thay đổi policy. Không sửa nhiều yếu tố cùng lúc.
Giới hạn kết luận
#Active probe lấy mẫu một traffic profile, không đại diện tự động cho mọi flow, payload hoặc application transaction. Round-trip delay che giấu bất đối xứng; one-way delay phụ thuộc clock; probe loss không luôn bằng user packet loss. Kết luận nên ghi rõ phạm vi topology, DSCP, interval, tải nền và thời gian quan sát.
Khái niệm cần nhớ
#- STAMP: giao thức đo chủ động hai chiều đơn giản theo RFC 8762.
- TWAMP: kiến trúc đo active two-way có control/test theo RFC 5357.
- Session-Sender/Reflector: hai vai trò phát và phản hồi gói đo.
- One-way delay: độ trễ một chiều, cần đồng bộ clock đủ tốt.
- Round-trip delay: thời gian đi và về, không chỉ ra riêng từng hướng.
- Measurement error: sai số do clock, timestamp, processing hoặc sampling.
Khái niệm cần nhớ
- Baseline
- Dải giá trị bình thường được thu đủ lâu để làm mốc so sánh và đặt ngưỡng.
- SLA
- Cam kết chất lượng dịch vụ gắn với KPI, phạm vi, thời gian và cách đo cụ thể.
- Active test
- Phép đo dùng traffic tổng hợp được tạo có chủ đích giữa các điểm kiểm tra.
TÀI LIỆU ĐỐI CHIẾUTài liệu tham khảo4 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.
