Task Lifecycle
The following lifecycle operations are available on the task page and in the task list:
| Operation | Purpose |
|---|---|
| Create Task | Opens the builder for assembling Data Plane, Control Plane, and Access Plane configurations |
| Start Task | Sends the configuration to the agents and starts the selected scenarios |
| Stop Task | Ends the active run and moves the task into the stopping state |
| Open Task | Shows the configuration, diagram, metrics, events, and logs |
| Delete Task | Removes the task record from the list |
| Request Capture | Requests captured traffic (PCAP) from the selected agent when traffic capture is enabled |
| Export Report (PDF / CSV / HTML) | Generates a PDF, HTML, or CSV report for the selected task; see Report Export and Task Import |
Before starting a task, verify that all agents are available, the license is active, networks and interfaces are selected correctly, and related library objects are synchronized with the agents.
Two-Phase Task Start
Before user traffic begins in a complex task, agents pass through readiness phases:
| Phase | Meaning | What is established |
|---|---|---|
| agent-ready | The agent has accepted the configuration and is ready | Traffic-engine process and interfaces |
| measurement-ready | The measurement/service plane is ready | Access sessions, CP adjacencies, and tunnels |
| start-load | The load gate opens (warmup unlock) | Data Plane plugin traffic |
There is no separate warmup field in the builder; warmup is built into the two-phase start. Before the task starts, the Metrics tab displays “Metrics will appear after the task starts.” Immediately after the task enters RUNNING, it may display Preparing metrics until the first client data points arrive.
If a task remains in the preparation phase, inspect the agent Logs and Access/Control Plane events. Common causes are no DHCP/PPPoE response, BGP negotiation failure, or unsynchronized PTI/PCAP/C2 files.
Normal Task Stop
A normal stop begins when the user clicks Stop Task or the configured duration expires. The task immediately enters Stopping, and a task_stop annotation appears on the graphs. This annotation marks the beginning of shutdown, not the moment when all resources have already been released.
The system then stops the task in stages:
| Stage | What happens |
|---|---|
| 1. Stop admitting new load | Plugins stop creating new sessions and operations. Stateless generation stops, and packets and queues already prepared for transmission are processed. |
| 2. Complete inner stateful traffic | Active TCP connections finish their exchanges and close. TLS performs a negotiated secure-session shutdown when supported by the peer. Stateful UDP releases flow state after remaining queues are processed. |
| 3. Close dependent sessions and tunnels | Negotiated network tunnels such as IPsec remain active while inner connections close. IKE/Child SA DELETE follows. VLAN, GRE, and IP-IP have no separate negotiated shutdown and stop with the traffic. |
| 4. Final measurements | Client and server agents send their final metrics and coordinate the final statistics snapshot. |
| 5. Completion | Once resources are released, the task enters Completed, and task_finish is placed on the last second of metrics. |
TCP/TLS connection shutdown is initiated at the same rate configured for connection establishment. For example, with CPS = 3,000,000, the system begins closing no more than 3,000,000 connections per second. The limiter does not delay the peer's FIN/ACK or other response packets.
The same rule applies to IPsec: IKE/Child SAs close at the tunnel opening rate. Tunnels begin to close only after inner TCP/TLS/UDP traffic has completed on all participating agents. This preserves a working protected path for the final FIN/ACK packets and prevents artificial loss at the end of the measurement.
If a client flow has no corresponding server side in the task, Peresvet ST cannot wait indefinitely for responses from an external node. After initiating shutdown at the configured rate, the system waits up to 10 seconds for responses. If the external node does not complete the exchange, the user receives a warning, after which the task immediately releases local resources and completes.
Forced Stop
Force Stop Task is available in the expanded portion of the stop button, including while a normal stop is already in progress. Use it when the task or an external peer is unresponsive and graceful completion cannot be awaited.
A forced stop immediately terminates generation processes and releases local resources without waiting for:
- TCP/TLS/UDP exchange completion;
- FIN/ACK, TLS shutdown, or other responses from the external node;
- IKE/Child SA DELETE;
- a coordinated final metric snapshot across agents.
Metrics collected up to that point are retained, but the final second and comparison of transmitted and received data may be incomplete. Use a normal stop for measurement runs and a forced stop only as an emergency exit.
Startup Priority, Load Balancing, and Shutdown
Scenarios that use a network tunnel follow a direct order during startup and the reverse order during shutdown:
Startup: network and remote side → ready tunnel → inner flow/session
Shutdown: new flows blocked → inner sessions closed → tunnel closed → final metrics
Traffic is sent only through ready tunnels. As new IPsec tunnels open, they join the available pool:
- Stateless packets are distributed among ready tunnels as evenly as possible in round-robin order.
- A stateful TCP, TLS, or UDP flow is assigned to one ready tunnel when created. Subsequent packets in the flow use the same tunnel to preserve packet order and session state.
- A new tunnel participates in distribution of subsequent packets and new flows; existing stateful flows are not migrated between tunnels.
For example, consider 1,000 configured IPsec tunnels, an opening rate of 100 tunnels/s, and a stateless load of 1,000,000 packets/s. When the first 100 tunnels are ready, the entire load is distributed evenly among them—approximately 10,000 packets/s per tunnel. At 200 ready tunnels, subsequent packets are distributed at approximately 5,000 packets/s per tunnel. Once all 1,000 are ready, each tunnel carries approximately 1,000 packets/s.
During shutdown, the order is reversed: the system first stops creating new flows, then closes existing stateful sessions at the configured CPS, and only then closes IPsec tunnels at the configured tunnel opening rate.