Kiểm thử DHCP ở quy mô lớn: lease churn, exhaustion và failover

Tách bốn mục tiêu: đúng giao thức; đúng dữ liệu cấp phát; đủ capacity; và phục hồi đúng khi có lỗi. Một đồ thị lease/s cao không chứng minh không có duplicate address, sai option, nhầm scope hay lease bị rò sau khi client rời mạng.

Với DHCPv4, quy trình thường bắt đầu từ Discover–Offer–Request–ACK. DHCPv6 có message, identity và cơ chế riêng; Stateless DHCPv6, stateful IA_NA/IA_PD và SLAAC không nên gộp thành một bài. Ghi rõ mục tiêu là address assignment, prefix delegation hay option delivery.

Topology tối thiểu gồm client emulator, access switch, một hoặc nhiều DHCP relay, cặp DHCP server và hệ thống lease database. Tạo nhiều VLAN/scope để phát hiện mapping sai. Capture ở client-facing link, relay uplink và server; thu relay/server counter, lease table, CPU, memory, database latency và log.

Nếu dùng Option 82, khóa circuit-ID/remote-ID và policy. Với DHCPv6 relay, ghi link-address/peer-address và relay option. Đồng bộ clock để nối Discover/Solicit với ACK/Reply và database commit.

Profile phải có số client, client arrival rate, MAC/DUID distribution, VLAN/scope, lease time, renew/rebind timing, option set và retry/backoff. “10.000 client” chưa đủ nếu tất cả xuất hiện một lần trong 30 phút; boot storm 10.000 client trong 60 giây tạo áp lực khác.

Khóa server version, HA mode, database/storage, relay model/firmware, MTU, rate limit, snooping/security policy và response delay. Tách first lease, renew, rebind và release. Nhiều client emulator có hành vi retry đơn giản hơn thiết bị thật; cần lưu tool profile.

• Profile: Cold start · Biến chính: New clients/s · Câu hỏi: Cấp mới nhanh tới đâu?
• Profile: Renew steady · Biến chính: T1 distribution · Câu hỏi: Server duy trì lease ổn định?
• Profile: Rebind storm · Biến chính: Server/relay interruption · Câu hỏi: Client phục hồi thế nào?
• Profile: Short lease churn · Biến chính: Lease time nhỏ · Câu hỏi: Database/CPU có bão hòa?
• Profile: Multi-scope · Biến chính: VLAN/Option 82 · Câu hỏi: Có cấp đúng subnet/option?
• Profile: Mixed v4/v6 · Biến chính: DORA và Solicit/Reply · Câu hỏi: Hai stack ảnh hưởng nhau?

KPI gồm successful lease ratio; offer/reply latency p50/p95/p99; lease/s; timeout/retry; duplicate/conflict; wrong-scope/wrong-option; active/free lease; server/relay drops; CPU/memory/database latency và recovery time. Đo từ packet timestamp thay vì chỉ dashboard server.

Bằng chứng tối thiểu: pcap có transaction ID, client identity, lease table trước/sau, config scope/relay, log HA, counter và danh sách expected–actual option. Với DHCPv6 PD, kiểm tra prefix uniqueness, prefix length và route/forwarding sau cấp.

Đo latency theo từng pha thay vì một số tổng: thời gian từ Discover/Solicit đầu tiên tới Offer/Advertise, từ Request tới ACK/Reply, và tổng thời gian client có thể dùng địa chỉ. Nếu client retry, báo cả first-attempt success và eventual success. Hai hệ thống có eventual success giống nhau nhưng một hệ thống cần ba lần retry sẽ tạo trải nghiệm boot khác hẳn.

Theo dõi fairness giữa scope và relay. Một VLAN nhỏ không nên bị đói lease khi VLAN khác tạo storm, trừ khi policy ưu tiên đã được thiết kế như vậy. Báo kết quả theo scope/relay/client class để không che hotspot bằng số trung bình toàn hệ thống.

• Test: Baseline · Thao tác: Một client/scope · Kỳ vọng: Đúng address/options · Bằng chứng: Pcap + lease
• Test: Ramp · Thao tác: Tăng client arrival · Kỳ vọng: Knee point đo được · Bằng chứng: Latency/error trend
• Test: Boot storm · Thao tác: Burst đồng thời · Kỳ vọng: Trong SLA đã chốt · Bằng chứng: Success/p99
• Test: Multi-relay · Thao tác: Nhiều VLAN · Kỳ vọng: Đúng scope · Bằng chứng: GIADDR/relay option
• Test: Renew · Thao tác: T1/T2 · Kỳ vọng: Không mất lease · Bằng chứng: Timeline
• Test: Pool near-full · Thao tác: 90–100% có kiểm soát · Kỳ vọng: Cảnh báo/behavior đúng · Bằng chứng: Pool metric/log
• Test: Server fail · Thao tác: Stop primary · Kỳ vọng: Secondary phục vụ theo policy · Bằng chứng: Loss/recovery
• Test: Relay fail · Thao tác: Đổi đường · Kỳ vọng: Không cấp sai subnet · Bằng chứng: Packet/route

Pool exhaustion phải thực hiện trong lab hoặc scope riêng. Tăng client tới ngưỡng, xác minh server không cấp trùng, cảnh báo đúng và lease được giải phóng theo policy. Không rút ngắn lease production chỉ để “test nhanh”.

Negative test gồm request sai scope, duplicate identity, malformed option ở mức an toàn, unauthorized server và rogue offer detection nếu DHCP snooping thuộc phạm vi. Không phát malformed/flood trên mạng người dùng. Churn test cần theo dõi database growth, stale lease và cleanup.

Thêm bài kiểm tra address reuse: client release hoặc lease hết hạn, địa chỉ được tái cấp sau khoảng an toàn và không còn ARP/ND conflict. Với thiết bị dùng conflict detection, đo tác động của ping/ARP probe tới lease latency. Nếu server đánh dấu địa chỉ abandoned, xác nhận cơ chế phục hồi pool và cảnh báo.

Trong mạng access có DHCP snooping, kiểm tra trusted/untrusted port, binding table scale và persistence sau switch reboot. Snooping drop có thể bị hiểu nhầm là server chậm; capture hai phía relay/access giúp phân biệt request chưa bao giờ tới server với request đã tới nhưng không được xử lý.

Thử process stop, node power loss, database/link interruption và relay path failure riêng biệt. Đặt fault marker, đo transaction đang bay, client mới, renew của lease cũ và thời gian state đồng bộ sau khi node trở lại.

Pass/fail phải theo HA mode và vendor guidance. Không giả định active-active luôn không mất transaction. Kiểm tra split-brain, duplicate allocation, stale partner state và behavior khi communications interrupted. Sau failback, xác minh pool/lease ownership hội tụ.

Ngưỡng mẫu phải ghi số client, arrival rate, lease time, option, topology và duration. “99,9% success” không có ý nghĩa nếu không định nghĩa timeout và retry budget.

Chạy tối thiểu ba lần ở mỗi mức tải và reset trạng thái theo quy trình đã định. Một lần dùng lease database sạch, một lần dùng database đã có tải nền và một lần sau failover/failback giúp bộc lộ khác biệt do cache, index hoặc state đồng bộ. Báo median và worst run thay vì chỉ chọn kết quả đẹp nhất.

Khi nghiệm thu end-to-end, sau ACK/Reply hãy tạo ARP/ND, DNS lookup và transaction nhỏ tới gateway/service. Bước này chứng minh lease không chỉ tồn tại trong database mà client thực sự có thể sử dụng thông tin được cấp.

• 1. Ghi version, HA mode, scope, lease timer và relay config.
• 2. Xác minh clock và baseline một client.
• 3. Chạy multi-scope/option correctness.
• 4. Ramp new clients theo bậc.
• 5. Chạy boot storm, renew và short-lease churn.
• 6. Tiến gần pool exhaustion trong scope cô lập.
• 7. Lỗi từng server/relay/link theo ma trận.
• 8. Đo failback và state resync.
• 9. Đối chiếu pcap, lease DB, log và counter.
• 10. Cleanup lease/test scope và lưu evidence.

Kết quả phụ thuộc server/relay implementation, HA mode, database, network security và client retry. Emulator không đại diện mọi OS, phone, IoT hoặc PXE client. Chạy một tập client thật để kiểm tra interoperability sau capacity test.

DHCP success chưa chứng minh user có dịch vụ: cần ARP/ND, gateway, DNS và application smoke test sau lease nếu mục tiêu là onboarding end-to-end.