Kiểm thử ACL ở quy mô lớn: rule order, tài nguyên và atomic update

Trước hết, xác định “đúng” theo ý định: nguồn nào được tới đích nào, bằng giao thức/cổng nào, theo chiều nào và trong trạng thái kết nối nào. Một test chỉ xác nhận cấu hình đã commit chưa đủ; packet hợp lệ phải đi qua, packet không hợp lệ phải bị chặn và counter/log phải quy về đúng rule.

Ở quy mô lớn, thêm ba câu hỏi: rule set có còn đúng khi số rule và số object tăng; thiết bị mất bao lâu để đưa thay đổi vào data plane; trong cửa sổ cập nhật có packet nào bị xử lý theo trạng thái trung gian hay không. “Atomic update” trong bài này là mục tiêu quan sát được: traffic thấy trạng thái cũ hoặc mới, không thấy tổ hợp ngoài ý định.

Lab tối thiểu gồm generator hai phía, DUT/SUT thực thi ACL, điểm capture trước và sau DUT, cùng kênh quản trị riêng. Nếu ACL áp trên nhiều vị trí—ingress, egress, SVI, sub-interface hoặc VRF—phải biểu diễn từng attachment point trong topology và tạo traffic đi đúng mỗi đường.

Tạo ba nhóm flow: positive allow, negative deny và near-miss chỉ khác một trường như prefix length, protocol, port, DSCP, TCP flag hoặc IP version. Với hệ thống stateful, thêm chiều return và session đã tồn tại; với ACL stateless, không dùng hành vi state table để giải thích kết quả.

Khóa version phần mềm, loại interface, vị trí áp ACL, IPv4/IPv6, hướng ingress/egress, fragment handling, default action, logging, counter mode và các tính năng cùng chia sẻ tài nguyên thực thi. Không giả định “TCAM utilization” có cùng ý nghĩa giữa các nền tảng; hãy ghi đúng chỉ số và đơn vị mà thiết bị cung cấp.

Traffic profile cần nêu số flow, packet size, pps, connection rate, tỷ lệ allow/deny, phân bố địa chỉ/cổng và offered load. Rule set phải có seed/version, số rule, số object, thứ tự, độ rộng match và phương thức cập nhật. Nếu so sánh hai lần chạy, giữ nguyên traffic corpus và mapping expected-result.

KPI chức năng gồm tỷ lệ quyết định đúng, false allow, false deny, counter accuracy và log completeness. KPI thay đổi gồm thời gian từ commit đến data plane hiệu lực, packet loss, longest loss burst, duplicate, latency/jitter và số packet quan sát được theo chính sách trung gian. KPI hệ thống gồm CPU, memory, queue control plane và chỉ báo tài nguyên ACL do thiết bị công bố.

Mốc · Định nghĩa · Bằng chứng T0 · Gửi lệnh commit · Log orchestrator có timestamp T1 · Control plane nhận cấu hình · Audit/config event T2 · Rule mới có hiệu lực · Packet probe đổi kết quả T3 · Toàn bộ flow ổn định · Capture và generator T4 · Counter/log đối soát xong · Snapshot telemetry/log

Pass/fail phải ưu tiên false allow bằng không trong tập test đã định nghĩa. Với throughput hay update time, chỉ công bố cùng version, topology, scale, traffic profile và logging state; bật logging theo từng packet có thể làm thay đổi kết quả.

Tình huống · Kỳ vọng · Rủi ro cần bắt Exact match · Allow/deny đúng rule · Sai attachment hoặc sai chiều Prefix chồng lấn · Theo rule order/chính sách · Rule shadowing Port range biên · Đúng hai đầu khoảng · Off-by-one IPv4 fragment/IPv6 extension · Theo chính sách đã ghi · Bypass hoặc drop ngoài ý định Rule set gần ngưỡng · Không sai quyết định · Resource fallback/commit fail Insert/delete giữa bảng · Chuyển trạng thái có kiểm soát · Cửa sổ chính sách trung gian Rollback · Trở lại baseline · Counter/state stale

Mỗi dòng cần positive và negative control. Nếu phát hiện sai lệch, lưu packet mẫu nhỏ nhất tái hiện được, rule ID, counter, log, trạng thái tài nguyên và cấu hình đã redaction; không chỉ lưu ảnh chụp màn hình trạng thái “success”.

Pha 1 kiểm tra functional với rule set nhỏ, mỗi rule có ít nhất một flow hit và một near-miss. Pha 2 tăng số rule/object theo bậc, vẫn chạy corpus cố định để phát hiện điểm mà hành vi hoặc cơ chế cài đặt thay đổi. Pha 3 tăng pps/connection rate và tỷ lệ denied traffic để đo under-load behavior.

Pha 4 cập nhật rule khi traffic liên tục; pha 5 rollback và restart control plane có kiểm soát; pha 6 chạy soak test để bắt counter wrap, log loss hoặc drift. Sau mỗi pha, đối chiếu kết quả dự kiến từ policy compiler độc lập với capture thực tế và counter DUT.

Phát đồng thời canary flow phải luôn allow, canary flow phải luôn deny và flow có chính sách thay đổi. Chèn, sửa, xóa rule ở đầu, giữa và cuối bảng; thử thay object được nhiều rule tham chiếu. Timestamp packet ở hai phía cho biết thời điểm data plane thực sự chuyển trạng thái, thay vì suy ra từ thông báo commit.

Không gọi cập nhật là atomic chỉ vì CLI/API trả về thành công. Nếu thiết bị dùng cơ chế staging/commit, xác minh cả lỗi giữa quá trình và rollback. Khi có cluster hoặc HA, lặp test khi member failover và kiểm tra hai node có cùng policy generation trước khi kết luận.

• [ ] Chốt ý định chính sách và default action.
• [ ] Gắn expected-result cho từng flow trong corpus.
• [ ] Ghi version, attachment point, IPv4/IPv6 và logging state.
• [ ] Đồng bộ clock giữa orchestrator, generator, DUT và collector.
• [ ] Chạy baseline nhỏ; đối soát capture, counter và log.
• [ ] Tăng rule/object và offered load từng bậc.
• [ ] Thực hiện insert/update/delete/rollback dưới canary traffic.
• [ ] Kiểm tra fragment, extension header và các giá trị biên.
• [ ] Lặp khi HA failover nếu nằm trong phạm vi.
• [ ] Xuất raw result, config hash và sai số timestamp.

Kết quả chỉ áp dụng cho nền tảng, version, loại interface, vị trí áp, rule structure và traffic profile đã thử. Số rule tối đa theo tài liệu không tương đương số rule có thể cài trong mọi tổ hợp match/action, và utilization nội bộ không phải chuẩn so sánh xuyên hãng.

Test corpus không thể chứng minh không tồn tại mọi đường bypass. Các cơ chế phân mảnh, tunnel, service chaining hoặc stateful inspection ngoài phạm vi phải được ghi rõ. Kết luận “không gián đoạn” chỉ có giá trị trong độ phân giải và độ phủ traffic của phép đo.

• ACL: Tập rule quyết định allow/deny theo trường gói tin.
• Rule shadowing: Rule đứng trước làm rule sau không bao giờ được hit.
• Attachment point: Vị trí và hướng ACL được áp.
• Atomic update: Chuyển từ policy cũ sang mới mà không lộ trạng thái trung gian ngoài ý định.
• False allow/deny: Cho phép nhầm hoặc chặn nhầm so với policy oracle.
• Traffic corpus: Tập flow có đầu vào và kết quả kỳ vọng đã kiểm soát.
• TCAM: Một loại tài nguyên phần cứng thường dùng cho tra cứu; cách phân bổ tùy nền tảng.