Load generation
POST /api/bng/demo/start read_only
POST /api/bng/demo/stop read_only
GET /api/bng/demo/status read_only
POST /api/bng/demo/reset read_only
POST /api/bng/demo/deep-reset read_only
POST /api/bng/demo/trex/start read_write
POST /api/bng/demo/trex/stop read_write
GET /api/bng/demo/trex/status read_writeThese are lab and acceptance-test surfaces, and they exist for a specific reason
that matters during evaluation: a BNG can be driven to a realistic subscriber
and traffic state through its own API, with no external test equipment.
The session generator creates synthetic subscribers through the real DORA
path — they are genuine sessions in the controller's session table, with real
plans applied and real policers programmed — and optionally emits accounting.
Rate and packet size per session are configurable and clamped to sane bounds. It
reports live progress: sessions created, connected and captive counts, packets
and bytes sent, elapsed runtime, and any error.
reset tears down the synthetic sessions by their reserved MAC prefix, leaving
real subscribers untouched. deep-reset is destructive: it snapshots the
controller's BNG configuration, issues a full persistent reset, and replays the
configuration. It exists for a wedged state machine and returns the pre-reset
snapshot in its response so nothing is lost.
The traffic generator drives external load through a remote host, supporting
a steady rate or an oscillating pattern stepping through a list of rates. It is
read_write throughout, including its status endpoint.
For a competitive evaluation the practical value is that a bake-off script can,
through one API and one credential, bring a bare box to configured state, drive
subscribers onto it, generate representative traffic, and then read the QoS
counters, the retained time series, and the health verdict that result — with no
manual step in the loop.