Network Testing (Load Test)

Network Testing drives synthetic signalling load at a live core so you can measure how it behaves under stress. It is not one generator but a fleet of them: standalone load generators register themselves with OmniWeb and appear here, and you drive them — set a rate, ramp up gradually, pause, drain, stop — from one console, per generator or across the whole pool at once.

← Operations Guide

Network Testing covers three kinds of load, each on its own sub-tab under Network Testing in the sidebar:

Sub-tab	Generator	Stresses	Measured as
Diameter Load Test	Seagull	The DRA + HSS (Diameter signalling)	Requests per second (rps)
SIP Load Test	SIPp	The CSCFs + HSS — IMS registrations, with IPsec	New registrations/sec, held (registered) UEs
RAN Load Test / RAN Simulator	RAN Simulator	The full radio→core path (S1AP/NAS, GTP-U, IMS)	See RAN Simulator

The Diameter and SIP tabs are the self-registering generator console described on this page. The RAN tabs are the RAN Simulator — virtual eNodeBs and UEs — documented separately.

How generators appear

You do not launch generators from OmniWeb. Each load generator (Seagull for Diameter, SIPp for SIP) is started on a load-injection host and pointed at OmniWeb; from then on it self-registers, heartbeating to the controller every couple of seconds with "I exist, here is my control address, and here are my live counters." Within a couple of seconds it shows up in the matching sub-tab.

If a tab is empty, it tells you exactly how to start one — copy the flag it shows (it derives the URL from the address you are browsing, so it is always correct for this deployment) and start the generator with it.

The registry is live telemetry only — it is not persisted. A generator that stops heartbeating past its TTL is shown offline (and, being offline, not running); it reappears the moment it heartbeats again.

Reading a generator

Each generator is a row in the left list (green dot = online, RUN/IDLE/OFF). Select one to see its detail:

• A status line — running (with the active scenario) or stopped/offline, the Diameter link state (up, and the peer) for Seagull, or the count of active IPsec SAs for SIPp.
• Live metrics, tailored to the tool:
  • Diameter: offered rate, successful, failed (timeout), average response time, current open calls.
  • SIP: offered rate, held (UEs currently registered), registered OK (200s), IPsec SAs, created/attempted, peak concurrent, failed, IPsec failed.
• Peer CPU gauges — when the selected site has a Monitoring (Prometheus) role, OmniWeb reads per-node CPU straight from Prometheus and shows a gauge per DRA/HSS/CSCF the traffic hits, plus (Diameter) DRA request/answer rates and the DRA→peer response delay. This lets you watch the effect of the load on the core, not just the generator's own numbers.
• Scenario messages (SIPp) — a per-step table of the REGISTER flow: how many of each message were sent/received, and any timeouts, unexpected messages, or retransmissions, so you can see exactly where a flow is failing under load.

MAXED

A SIPp process that is holding its full "Max UEs" cap can open no new calls, so it stops pushing traffic even though you have asked for more. OmniWeb flags this as MAXED (on the row, the detail header, and the Held metric). The fix is to raise the Max UEs cap — see below.

Driving traffic

For the selected generator (Traffic control card):

• Scenario — switch the running scenario live (Seagull), or see the scenario fixed at launch (SIPp).
• Rate — set the offered rate with a slider, presets, or a number box (rps for Diameter, new registrations/sec for SIP). 0 = idle/hold.
• Ramp (Seagull) — instead of a step change, climb to the target rate over N seconds.
• Max UEs (SIPp) — the ceiling on concurrent held (registered) UEs, applied live with no restart. Raise it to push a MAXED process harder.
• Pause / Resume / Drain (SIPp) — hold and release traffic, or drain (let held calls end without opening new ones).
• Inject call (SIPp) — fire a single call, for spot checks.
• Reset stats — clear the cumulative counters and the per-message table.
• Stop traffic — stop the generator pushing load.

Commands are sent from OmniWeb to the generator's control endpoint (a UDP socket for SIPp, a control port for Seagull); the buttons that appear depend on what the tool supports.

Driving the whole pool at once

When more than one generator is registered, a Pool control card appears above the list. It fans the same actions out across every online generator in parallel, so you drive "all 30" from one place:

• Scope — all generators, or one host group (generators supervised on the same host, e.g. sipp-bsc01-01/-02/-03, collapse into one group).
• Fleet totals — offered rate, held/successful, created, IPsec SAs, peak, failed, and fail-rate summed across the scope, so you see the aggregate load the pool is offering, not per-process figures.
• Set a steady rate — apply one per-process rate to every generator (the card shows the resulting pool total: N instances × rate).
• Max UEs (SIPp) — set the held cap on every process at once; the card flags how many are currently MAXED.
• Ramp up gradually — climb every instance from 0 to a target over a duration in steps. The ramp runs in your browser — leaving the page stops it.
• Bulk lifecycle — Pause / Resume / Drain / Stop all, and Reset stats.

Typical use

1. Start one or more Seagull (Diameter) or SIPp (SIP) generators on your load hosts, pointed at OmniWeb; confirm they appear online.
2. Pick a modest steady rate on one generator and confirm the core answers (watch Successful / Registered OK and the peer CPU gauges).
3. Ramp the pool up gradually toward the target and watch the fleet totals, the fail rate, and the peer CPU/response-delay gauges for the point where the core starts to degrade.
4. For SIP soak tests, set a Max UEs cap and let the fleet hold a large registered population; raise the cap if processes go MAXED.
5. Drain/Stop when done.

Related

• RAN Simulator — the RAN sub-tabs: virtual eNodeBs/UEs for functional and load testing across the whole radio→core path.
• Grafana Dashboards & Statistics — the peer CPU gauges here read the same Prometheus the dashboards do; use Grafana for the full picture during a test.