
Mục lục bài viết 9 phần
Một Diameter peer có thể ở trạng thái open nhưng vẫn trả lời chậm, route sai realm hoặc tạo duplicate khi failover. Test plan cần đo từ transaction nghiệp vụ đến transport/peer state, thay vì dùng watchdog success làm bằng chứng dịch vụ khỏe.
Bài viết giúp bạn
- Diameter cần được kiểm ở những lớp nào?
- Topology và điều kiện đo
- Biến số phải kiểm soát
Diameter cần được kiểm ở những lớp nào?
#RFC 6733 định nghĩa Diameter base protocol, peer connection, watchdog, routing và error handling. Ứng dụng Diameter cụ thể bổ sung command/AVP và semantics riêng; vì vậy base protocol pass không chứng minh subscriber/session transaction đúng. Bài đo phải ghi application ID, command code và expected result code.
Ba lớp cần tách là transport, peer state và application transaction. TCP/SCTP connect có thể ổn trong khi DWR/DWA chậm; watchdog có thể ổn nhưng agent route sai realm; answer success có thể đến sau client timeout và trở thành late/duplicate effect.
Topology và điều kiện đo
#Topology tối thiểu gồm Diameter client emulator, relay/proxy/agent nếu production có, hai server peer, network emulator trên từng path và capture/log correlation. Dùng primary/secondary khác failure domain; nếu cả hai đi chung switch hoặc load balancer, test failover sẽ bỏ sót shared failure.
Khóa Origin-Host, Origin-Realm, Destination-Realm/Host, application ID, vendor ID, peer table, routing rule, transport TCP/SCTP, TLS/IPsec nếu dùng và watchdog timers. Đồng bộ thời gian hoặc dùng request identifier để nối generator, agent và server log.

Biến số phải kiểm soát
#Traffic profile phải mô tả session arrival, command mix, AVP size, burst, think time, outstanding window và tỷ lệ success/error mong đợi. Tách stateless request khỏi transaction có state. Một command nhẹ không đại diện cho authorization, charging hoặc mobility flow nhiều bước.
Kiểm soát connection pool, transport reconnect, watchdog interval, failover/failback policy, retry budget, duplicate suppression, routing precedence và overload algorithm. Với RFC 7683, ghi rõ overload report type, scope, validity duration và reduction percentage được xử lý thế nào; không coi mọi 3xxx/5xxx result code là cùng một loại overload.
KPI và bằng chứng đầu ra
#Đo offered/accepted/answered transaction rate, latency p50/p95/p99, timeout, result-code mix, outstanding requests, watchdog RTT, reconnect time, failover restoration, late answer, retry và duplicate. Báo server/peer utilization và queue để biết bottleneck nằm trước hay sau Diameter agent.
- KPI: Transaction success · Ý nghĩa: Request nhận answer hợp lệ đúng thời hạn · Bằng chứng: Generator + server log
- KPI: Answer latency · Ý nghĩa: End-to-end request–answer · Bằng chứng: Hop-by-Hop/End-to-End ID + clock
- KPI: Outstanding depth · Ý nghĩa: Áp lực hàng đợi · Bằng chứng: Client/agent counter
- KPI: Watchdog RTT · Ý nghĩa: Health của peer signaling · Bằng chứng: DWR/DWA timeline
- KPI: Failover restoration · Ý nghĩa: Lỗi → giao dịch ổn định trên peer dự phòng · Bằng chứng: Fault + transaction timeline
- KPI: Duplicate/late answer · Ý nghĩa: Rủi ro integrity sau retry · Bằng chứng: Session/transaction correlation
- KPI: Overload compliance · Ý nghĩa: Client giảm tải đúng report · Bằng chứng: OC-OLR/OC-Supported-Features + rate
Ma trận routing, overload và failure
#Ma trận nên thêm malformed/missing AVP trong lab an toàn, nhưng tách protocol robustness khỏi capacity benchmark. Khi kiểm realm routing, cần negative destination để chắc agent không gửi nhầm sang default peer và phát hiện vòng lặp bằng Route-Record AVP với lỗi DIAMETER_LOOP_DETECTED. Hop-by-Hop Identifier là mã ghép request–answer trên một hop, không phải bộ đếm giới hạn số hop.
- Ca thử: Baseline primary · Tác động: Tải 30–60% · Câu hỏi pass/fail: Route/AVP/result đúng, latency ổn định
- Ca thử: Realm/host mismatch · Tác động: Route không hợp lệ · Câu hỏi pass/fail: Trả lỗi đúng, không route vòng
- Ca thử: Peer hard down · Tác động: Link/process dừng · Câu hỏi pass/fail: Chuyển peer, không mất/duplicate ngoài ngưỡng
- Ca thử: Silent peer · Tác động: Kết nối còn, không answer · Câu hỏi pass/fail: Watchdog/transaction timeout tách đúng
- Ca thử: Overload report · Tác động: Peer yêu cầu giảm tải · Câu hỏi pass/fail: Scope, duration và reduction được tuân thủ
- Ca thử: Secondary overload · Tác động: Failover vào peer yếu · Câu hỏi pass/fail: Không khuếch đại retry/cascade
- Ca thử: Agent restart · Tác động: Mất state trung gian · Câu hỏi pass/fail: Reconnect, in-flight handling và recovery rõ
- Ca thử: Failback · Tác động: Primary trở lại · Câu hỏi pass/fail: Không oscillation hoặc double-send
Test plan theo từng pha
#Pha A kiểm CER/CEA, capability/application alignment và routing cơ bản. Pha B chạy baseline từng command/flow với một connection rồi mở rộng connection/transaction rate. Pha C tạo overload từ từ và burst để quan sát queue, OLR, throttling và recovery.
Pha D gây hard down, silent drop, high latency, packet loss và agent restart thành các run riêng. Pha E kết hợp failover với tải cao để phát hiện thundering herd. Pha F khôi phục primary, theo dõi failback, outstanding reconciliation và duplicate trong khoảng thời gian đủ dài.
Checklist nghiệm thu và runbook
#- Chốt application ID, command mix, AVP và transaction semantics.
- Vẽ peer/routing table, priority, realm và failure domain.
- Ghi transport, security, timer, connection pool và retry policy.
- Ghép request–answer theo từng hop bằng Hop-by-Hop Identifier; đối chiếu Origin-Host và End-to-End Identifier để phát hiện duplicate, cùng Session-Id/khóa nghiệp vụ khi ứng dụng có dùng.
- Báo latency phân vị, result code, timeout, late answer và duplicate.
- Tách peer hard down, silent peer, slow peer và application error.
- Kiểm overload scope, validity và traffic reduction theo RFC 7683.
- Giới hạn retry để tránh secondary peer bị cascade overload.
- Kiểm in-flight transaction khi agent/peer restart và khi failback.
- Lưu pcap, peer state, route snapshot, counter và raw transaction log.

Giới hạn của kết luận
#Diameter base protocol không định nghĩa toàn bộ hành vi ứng dụng. Pass cho một command/application không suy rộng sang charging, policy hoặc mobility interface khác. Vendor agent có thể có routing, throttling và duplicate handling riêng; phải gắn kết luận với release/configuration.
Watchdog chỉ cho biết khả năng trao đổi Device-Watchdog, không chứng minh database/backend đủ capacity. Tương tự, throughput cao không bù cho answer sai AVP hoặc duplicate gây thay đổi state. Ngưỡng pass/fail phải dựa trên SLA và hậu quả nghiệp vụ, không lấy một con số chung từ RFC.
Khái niệm cần nhớ
#- Diameter peer: node có kết nối trực tiếp ở tầng transport.
- DWR/DWA: Device-Watchdog-Request/Answer dùng kiểm tra liveness peer.
- CER/CEA: Capability-Exchange-Request/Answer khi thiết lập quan hệ peer.
- AVP: Attribute-Value Pair mang dữ liệu Diameter.
- Hop-by-Hop Identifier: định danh request/answer trên từng hop.
- End-to-End Identifier: kết hợp Origin-Host để hỗ trợ nhận biết duplicate request xuyên tuyến.
- OLR: overload report theo cơ chế Diameter overload indication.
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ả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.
