IPsec

The IPsec layer in a Library → Network Tunnels object protects plugin traffic (HTTP, PCAP Replay, Flood, and more) with IKE and ESP. Create a profile with the required layers—VLAN, VXLAN, GRE, or IP-IP plus IPsec when needed—and select it in the client or server plugin's Network Tunnels group.

Basic Parameters

Table — IPsec Profile Parameters

Name	Description
Tunnel type	Select IPsec.
Source IP or pool	Outer source IP for IKE/ESP. Supports one IPv4 address, one CIDR, or one contiguous range.
Tunnel endpoint addresses	Required outer IP addresses of remote peers. CIDRs, ranges, and comma-separated lists are supported.
Authentication method	PSK or RSA certificate.
Pre-Shared Key	Shared secret when PSK is selected.
Certificate and key	Certificate and private-key objects when RSA is selected.
IKE and ESP algorithms	Encryption, DH, PRF, and authentication suite negotiated with the remote device.
Traffic Selectors	Protected inner Source and Destination ranges.
SA Lifetime and Rekey Time	SA lifetime and renegotiation interval. 0 disables the corresponding limit.
DPD	Dead Peer Detection interval and timeout.
Multi P2 over P1	Number of Child SAs per IKE SA.
NAT-T	Carry ESP in UDP/4500 when traversing NAT.
PFS	Separate DH key agreement for a Child SA when required.

The Outer Address and TSi Are Different Parameters

Source IP or pool is the outer address of IKE/ESP packets. Source TSi is the inner address of protected traffic negotiated as a Traffic Selector. The outer pool does not replace the TSi range, nor does the TSi range replace the outer pool.

Bulk Tunnel Creation

After you select an IPsec profile in the task builder, bulk-scenario parameters become available.

Table — Bulk Scenario Parameters

Name	Description
Number of IPsec tunnels	Number of independent tunnels created from the selected profile: 1 to 2,000,000.
Opening rate	Overall IKE negotiation start rate across the task, not a per-core rate. 0 removes the user-defined limit.
Unique TSi for each tunnel	Assigns a separate Source TSi /32 from the specified range to every tunnel. Disabled by default.
First Source TSi / Last Source TSi	Bounds of the inner-address range. It must contain at least as many addresses as the number of tunnels.

For multiple tunnels, enter enough outer addresses in Source IP or pool. Addresses are assigned to tunnels sequentially. In a regular CIDR, the network and broadcast addresses are excluded; all addresses are used in a /31 or /32. A contiguous range includes both endpoints. For example, 192.168.200.0/21 contains 2,046 usable addresses and therefore supports at most 2,046 tunnels.

The outer source-IP pool must contain at least as many usable addresses as the configured tunnel count. The DUT must accept IKE/ESP and provide return routing for the entire outer pool.

If all tunnels terminate at one gateway, enter a single address in Tunnel endpoint addresses. It becomes the common remote endpoint, while the tunnels receive different addresses from the outer source pool.

When to Enable a Unique TSi

Enable Unique TSi for each tunnel when the DUT:

• treats Child SAs with identical Traffic Selectors as duplicates and removes the previous SA on collision;
• requires a separate policy or protected address for every tunnel;
• must map each tunnel unambiguously to an inner source.

Each tunnel receives a separate Source TSi /32, while the Destination TSi remains as specified in the profile. The Source TSi range must match the inner-address plan and the policies on the remote device. If the device permits multiple SAs with identical selectors, leave this toggle disabled.

Load Distribution

Inner traffic is sent only through established SAs.

• For stateful traffic, the session count and establishment rate are distributed proportionally among processing threads. Each TCP, TLS, or stateful UDP session remains assigned to one ready tunnel for its entire lifetime.
• For stateless traffic, the overall PPS load is distributed among processing threads, and packets are alternated evenly among ready tunnels.

Inner traffic generation begins as soon as the first tunnels are ready. During IKE ramp-up, the established subset of SAs therefore carries the temporary load. Measure sustained throughput only after Established tunnels reaches the configured value.

Achieving Maximum Performance

Tunnel and CPU Count

IPsec tunnels are distributed among agent cores. The number of cores used concurrently cannot exceed the number of tunnels: for example, 10 tunnels cannot load more than 10 cores, even when the agent has additional CPU cores assigned. To scale ESP processing, increase the number of independent tunnels together with the number of available cores.

Recommended configuration sequence:

1. Configure enough tunnels to use the required number of cores. Leave headroom in the tunnel and CPU counts when testing maximum throughput.
2. Set Opening rate below the measured testbed capacity when you need a steady IKE negotiation plateau. A value of 0 opens tunnels without a user-defined limit and can produce brief bursts.
3. Wait until all tunnels are established before evaluating RPS, PPS, and L1 throughput.

HTTP: RPS and Session Count

For HTTP, the target rate is the product:

total RPS = session count × RPS per session

Copy code to clipboard

In HTTP/1.1, the next operation in a session depends on completion of the previous response. If a complete response takes longer than the 1 / RPS per session interval, the configured total RPS cannot be reached even when the loss counters remain at zero. To preserve the same total RPS, increase the number of concurrent sessions and reduce RPS per session. For example, use 2,000 sessions × 50 RPS instead of 1,000 sessions × 100 RPS.

HTTP Response Size and Target L1 Throughput

Do not calculate the HTTP response-body size simply by dividing the target rate by RPS. Ethernet/IP/TCP, HTTP, ESP, and, when present, UDP NAT-T/VLAN headers are also transmitted on the wire. With an MTU of 1500, a large response is split into multiple packets, and protocol overhead is added to every packet.

First calculate the on-wire budget per response:

on-wire bytes per response = target L1 bps / (8 × target RPS)
body size ≈ on-wire bytes per response − protocol-stack overhead

Copy code to clipboard

At 100,000 RPS and 90 Gbps L1, the budget is 112,500 on-wire bytes per response. For a typical IPv4 + TCP + HTTP/1.1 + ESP stack with an MTU of 1500, start with a 102,400-byte (100 KiB) body and adjust it from the observed graphs. The exact result depends on the header set, MSS, ESP algorithm, NAT-T, and VLAN.

Once RPS is stable, estimate the actual overhead from measurements:

actual on-wire bytes per response = measured L1 bps / (8 × measured RPS)
protocol overhead ≈ actual on-wire bytes per response − current HTTP body size

Copy code to clipboard

Verifying Results

Before recording a result, check that:

• Requested, Slots, and Established tunnels match the expected tunnel count;
• Failed and IKE timeouts are not increasing;
• RPS/PPS and L1 throughput are evaluated after IKE ramp-up completes;
• there are no TCP drops/retransmissions, ESP no-SA/oversize/PMTU errors, or network-interface errors/loss;
• the load is distributed reasonably evenly among cores and RX queues.

If RPS and Gbps fluctuate together below the target while error counters remain at zero, this usually indicates a concurrency limit rather than packet loss: too few tunnels, sessions, or active cores, or uneven RSS. Anomaly counters confirm correct processing but do not by themselves prove that the target performance was achieved.

Stopping a Task

During a normal stop of a stateful task, the system first stops creating new sessions and closes established inner sessions on all agents. It then sends IKE/Child SA DELETE messages at the configured tunnel opening rate. In a stateless task, packet generation stops immediately, and tunnel removal begins after the queues drain. The detailed sequence and its difference from a forced stop are described under Task Lifecycle.

Published performance results are available under Benchmarks.