Thông lượng IPsec thấp hơn mong đợi? Hãy kiểm tra SA đang hoạt động trước
Danh sách chuyển đổi dài không phải là phiên đang bảo vệ quá trình truyền của bạn. Hãy ghi lại SA đã thương lượng, kích thước tải trọng và tốc độ thực sự được giao trước khi đổ lỗi cho mã hóa.
Cấu hình đưa ra tám chuyển đổi, ai đó đọc cái mạnh nhất và con số thông lượng bị gán cho nó. Đường hầm có lẽ đã không chọn chuyển đổi đó, và cũng không chạy khối lượng công việc mà ai đó hình dung. Thứ được thương lượng là một mục từ danh sách đó, với một kích thước gói, theo một hướng, trên một bản dựng. Hãy đo điều đó và cuộc tranh luận về thuật toán thường kết thúc trước khi bắt đầu.
Triệu chứng: một con số thấp hơn những gì cấu hình hứa
Danh sách chuyển đổi dài mô tả các khả năng, và mỗi khả năng được chấm điểm trên giấy thay vì trên phần cứng này. Kết quả thương lượng là một tổ hợp duy nhất mà cả hai bên chấp nhận, và nó có thể là tổ hợp yếu nhất mà mỗi bên vẫn cho phép vì lý do tương thích. Tổ hợp đó đạt được gì phụ thuộc vào trạng thái offload, kích thước gói và hành vi hàng đợi, nên hai thiết bị có cùng tệp chính sách có thể đi rất xa khác nhau. Danh sách là thực đơn; liên kết là đơn hàng đã quay về.
Đọc danh sách cho bạn biết điều gì có thể đã được chọn. Đọc liên kết cho bạn biết điều gì thực sự đang mang quá trình truyền, và chỉ điều đó mới được con số thông lượng mô tả. Mỗi bước tinh chỉnh bắt đầu từ danh sách là một phỏng đoán kèm thêm giấy tờ.
Ghi lại liên kết đang mang quá trình truyền này
Trên một ASA show crypto ipsec sa liệt kê các liên kết đang hoạt động cùng chuyển đổi và bộ đếm theo từng hướng, và tài liệu tham chiếu lệnh của Cisco ghi lại kết quả đó. Chọn peer và hướng quan trọng, và lưu ý rằng việc thương lượng lại khóa sẽ thay thế liên kết và đặt lại bộ đếm của nó, điều này âm thầm vô hiệu hóa một đường cơ sở mà bạn vẫn còn tin. Lưu kết quả bên cạnh ghi chú kiểm thử để lần chạy sau có thứ để so sánh. Một định danh liên kết trôi giữa các lần chạy khiến mọi so sánh sau đó trở nên vô nghĩa.
| What to record | Where to read it | What it rules out |
|---|---|---|
| Negotiated transform and SA identifiers | show crypto ipsec sa for that peer and direction | "the configuration picked the wrong algorithm" |
| Offload or accelerator state for that build | platform show commands and interface statistics | "the crypto engine is the ceiling" |
| Payload size and offered rate | the test tool's own settings and summary | "packets per second versus bytes per second" |
| Delivered rate and loss at the receiver | the receiving endpoint, not the sender's counters | "the sender transmitted, so it arrived" |
| Access-link load and drops | underlay interface counters along the path | "the bottleneck lives inside the tunnel" |
Năm hàng là đủ để một phép đo có thể tái lập, và mỗi hàng loại trừ một lời giải thích cụ thể khi nó vắng mặt. Không hàng nào là mục trong danh sách đề xuất, vì danh sách không thể nói điều gì đang bảo vệ các byte của bạn ngay lúc này. Hãy điền bảng một lần và sự cố tiếp theo sẽ bắt đầu bằng dữ liệu thay vì một cuộc tranh luận mới về thuật toán.
Hàng liên kết truy cập là hàng mà người ta bỏ qua, và chính nó thường giải thích một khoảng cách trông có vẻ mật mã. Một lớp nền bão hòa hoặc một policer dọc đường tạo ra cùng hình dạng triệu chứng như một cỗ máy chậm.
Đo một hướng với tải được kiểm soát
Chạy thử nghiệm từ một điểm cuối trong LAN đại diện cho ứng dụng thay vì từ chính cổng, vì một đầu dò do cổng tạo ra có thể tuân theo chính sách cục bộ khác. Đo một hướng trước khi thêm luồng thứ hai, và ghi lại cả tốc độ đề nghị lẫn những gì bên nhận thực sự nhận được. Một lần chạy UDP giới hạn tốc độ tách tải đề nghị khỏi phản ứng tắc nghẽn của TCP, trong khi một bên gửi UDP không giới hạn không phải là chẩn đoán trung tính. Ghi cả độ dài tải trọng, vì datagram lớn hơn thay đổi cả tốc độ gói lẫn chi phí đóng gói.
show crypto ipsec sa peer 203.0.113.9
iperf3 -c 10.20.0.10 -u -b 200M -l 1200 -t 30Chạy cùng thử nghiệm hai lần với cùng độ dài tải trọng và thời lượng, vì một lần chạy không thể tách trần khỏi một phút tồi tệ. Nếu bên nhận báo ít gói hơn số bên gửi đã gửi, mất mát đó là phát hiện của bạn, và công cụ mật mã chỉ là một trong số vài ứng viên.
Giải thích khoảng cách trước khi tinh chỉnh bất cứ thứ gì
Kiểm tra chính sách chuyển tiếp, việc rơi hàng đợi, lỗi giao diện và giới hạn tài nguyên cùng với đường mã hóa, vì chỉ riêng sự thiếu hụt tốc độ không bao giờ xác định được CPU. Giữ các lớp kế toán cũng rõ ràng: byte của đường hầm ngoài bao gồm đóng gói, và việc truyền lại dịch chuyển mối quan hệ giữa bộ đếm trong và ngoài. So sánh từng byte các bộ đếm không liên quan sẽ tạo ra một sai lệch chưa từng tồn tại.
Kích thước gói xứng đáng có phép so sánh được kiểm soát riêng thay vì một con số sao chép từ ví dụ cũ. TCP MSS điều chỉnh TCP và không có tác dụng gì với các datagram UDP tùy ý, nên một giá trị cố định 1350 lấy từ tài liệu cũ không đo được gì cả. Hãy cố ý thay đổi độ dài tải trọng và quan sát những gì bên nhận báo cáo.
Thay đổi một biến và giữ nguyên khối lượng công việc
Khi đường cơ sở lặp lại trong một dải hẹp, hãy thay đổi một biến được hỗ trợ và chạy lại tác vụ ứng dụng ban đầu. Chính bước đó biến một con số thành nguyên nhân, và chỉ nó mới biện minh cho việc chạm vào cấu hình. Hãy lặp lại cùng khối lượng công việc chứ không phải một khối lượng dễ chịu hơn.
Đừng rút đề xuất, làm yếu xác thực hay tắt bảo vệ để làm một con số tổng hợp lớn hơn. Những động thái đó thay đổi tư thế bảo mật rồi đo kết quả của thay đổi ấy, không phải dung lượng của đường hầm.