IPsec 처리량이 예상보다 낮습니까? 먼저 활성 SA를 확인하십시오
긴 변환 목록은 전송을 보호하는 세션이 아닙니다. 암호화를 탓하기 전에 협상된 SA, 페이로드 크기, 실제로 전달된 속도를 기록하십시오.
구성에는 여덟 가지 변환이 나열되어 있고, 누군가 가장 강한 것을 읽고 처리량 수치를 그것에 붙입니다. 터널은 아마 그 변환을 선택하지 않았을 것이며, 누군가 상상한 작업 부하를 실행하지도 않았습니다. 협상된 것은 그 목록의 한 항목으로, 하나의 패킷 크기, 하나의 방향, 하나의 빌드에 불과합니다. 그것을 측정하면 알고리즘에 대한 논쟁은 대개 시작하기도 전에 끝납니다.
증상: 구성이 약속한 것보다 낮은 수치
긴 변환 목록은 가능성을 설명하며, 각 가능성은 이 하드웨어가 아니라 종이 위에서 평가됩니다. 협상된 결과는 양쪽이 수용한 단일 조합이며, 호환성을 위해 어느 한쪽이 여전히 허용하는 가장 약한 조합일 수 있습니다. 그 조합이 무엇을 달성하는지는 오프로드 상태, 패킷 크기, 큐 동작에 달려 있으므로 동일한 정책 파일을 가진 두 장비가 크게 다르게 나올 수 있습니다. 목록은 메뉴이고, 연결은 돌아온 주문입니다.
목록을 읽으면 무엇이 선택될 수 있었는지 알 수 있습니다. 연결을 읽으면 무엇이 실제로 전송을 나르는지 알 수 있고, 처리량 수치는 오직 그것만 설명합니다. 목록에서 시작하는 모든 튜닝 단계는 서류 작업이 더 붙은 추측입니다.
이 전송을 나르는 연결을 기록하십시오
ASA에서는 show crypto ipsec sa 활성 연결을 변환 및 방향별 카운터와 함께 나열하며, 명령 참조 가 그 출력을 문서화합니다. 중요한 피어와 방향을 선택하고, 키 재협상이 연결을 교체하고 카운터를 초기화한다는 점에 유의하십시오—그것은 아직 신뢰하던 기준선을 조용히 무효로 만듭니다. 출력을 테스트 노트 옆에 저장해 다음 실행이 비교할 거리를 갖게 하십시오. 실행 사이에 연결 식별자가 흔들리면 이후의 모든 비교가 무의미해집니다.
| 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" |
다섯 행이면 측정이 재현 가능해지고, 각 행은 빠졌을 때 특정 설명을 배제합니다. 어느 것도 제안 목록의 항목이 아닙니다—목록은 지금 무엇이 당신의 바이트를 보호하는지 말할 수 없기 때문입니다. 표를 한 번 채우면 다음 사고는 새로운 알고리즘 논쟁이 아니라 데이터에서 시작됩니다.
액세스 링크 행은 사람들이 건너뛰는 행입니다—그리고 암호처럼 보이는 차이를 가장 자주 설명하는 것도 그 행입니다. 포화된 언더레이 또는 경로상의 폴리서는 느린 엔진과 같은 모양의 증상을 만듭니다.
제어된 부하로 한 방향을 측정하십시오
테스트는 게이트웨이 자체가 아니라 애플리케이션을 대표하는 LAN 종단점에서 실행하십시오—게이트웨이가 생성한 프로브는 다른 로컬 정책을 따를 수 있기 때문입니다. 두 번째 스트림을 추가하기 전에 한 방향을 측정하고, 제공한 속도와 수신자가 실제로 받은 양을 모두 기록하십시오. 속도 제한 UDP 실행은 제공 부하와 TCP의 혼잡 응답을 분리하지만, 무제한 UDP 송신은 중립적인 진단이 아닙니다. 페이로드 길이도 기록하십시오—더 큰 데이터그램은 패킷 속도와 캡슐화 오버헤드를 모두 바꿉니다.
show crypto ipsec sa peer 203.0.113.9
iperf3 -c 10.20.0.10 -u -b 200M -l 1200 -t 30같은 페이로드 길이와 시간으로 같은 테스트를 두 번 실행하십시오—한 번의 실행으로는 상한과 나쁜 일 분을 구분할 수 없습니다. 수신자가 송신자가 보낸 것보다 적은 패킷을 보고하면 그 손실이 당신의 발견이며, 암호 엔진은 여러 후보 중 하나일 뿐입니다.
무엇이든 조정하기 전에 차이를 설명하십시오
포워딩 정책, 큐 드롭, 인터페이스 오류, 자원 한도를 암호화 경로와 함께 확인하십시오—속도 부족만으로는 CPU를 특정할 수 없습니다. 회계 계층도 명시적으로 유지하십시오—외부 터널 바이트에는 캡슐화가 포함되고, 재전송은 내부와 외부 카운터의 관계를 움직입니다. 무관한 카운터를 바이트 단위로 비교하면 존재한 적 없는 차이를 만들어냅니다.
패킷 크기는 오래된 예제에서 복사한 숫자가 아니라 자체적인 제어 비교를 받을 자격이 있습니다. TCP MSS는 TCP를 조정하며 임의의 UDP 데이터그램에는 아무 영향이 없으므로, 오래된 문서에서 가져온 고정 1350은 아무것도 측정하지 못합니다. 페이로드 길이를 의도적으로 바꾸고 수신자가 무엇을 보고하는지 보십시오.
변수를 하나만 바꾸고 작업 부하는 유지하십시오
기준선이 좁은 대역 안에서 반복되면, 지원되는 변수 하나를 바꾸고 원래 애플리케이션 작업을 다시 실행하십시오. 바로 그 단계가 숫자를 원인으로 바꾸며, 설정을 건드릴 명분을 주는 유일한 단계입니다. 더 편한 부하가 아니라 같은 작업 부하를 반복하십시오.
합성 수치를 키우려고 제안을 철회하거나 인증을 약화하거나 보호를 끄지 마십시오. 그런 조치는 보안 태세를 바꾸고 나서 그 변화의 결과를 측정할 뿐, 터널의 용량을 측정하는 것이 아닙니다.