Create and run scenarios in the GUI

•Select a lab and open Scenarios. Click New Scenario, enter its name and duration in milliseconds, then add actions. One second is 1000 ms.

•For each action, choose its time and action type. Agent actions select target agents; Send trap / INFORM opens a Trap Sender-style form for destination settings and editable trap content. Supported types are Start agents, Stop agents, Apply recorded-value overrides, Clear overrides, Apply fault, Clear fault and Send trap. Targets are shown by name and endpoint. When an agent has multiple recordings, choose the recording to change.

•Use the parameter forms to enter typed OID values, configure delay, loss, SNMP error, outage or reboot faults, or select the notification content from a trap recording. Outage template supplies a six-second scenario that starts agents at 0 ms and interrupts responses at 2000 ms for one second.

•Optional Checks verify observed requests, SET values and other traffic evidence. Choose an agent for agent checks, or a notification action for notification counts, plus a time window and expected counts or values. An external SNMP manager must generate requests; the simulator does not generate manager traffic for these checks.

•Actions and checks save automatically after Add, Edit, Duplicate or Remove. Name, duration and seed changes save automatically after typing. Import JSON and Outage template also save automatically. The editor shows Saving or Saved; invalid fields must be corrected before they can be saved. Stop the lab, then click Run in the editor or select the saved scenario and click Run in the Scenarios tab. Changes saved during a run apply to later runs.

•Open Scenarios and its lower Run results section to see active scenario elapsed/total time and paused state above the displayed run’s outcome, check results and events. Active progress remains visible when a historical run is selected. Run history contains all runs for this lab; Recent lab events also includes manual agent activity. Successful runs select the newly started run. Adjust the divider between scenarios and results, or use its collapse/expand controls. The result text can be selected and copied with Ctrl/Cmd+A and Ctrl/Cmd+C, or the right-click Select All and Copy menu. Live refresh preserves the scroll position and text selection. The vertical scrollbar stays visible. Run events belong to the selected run and are saved with its report, including agent notifications and requests. Completed or cancelled run histories remain available after restarting and in JSON and lab archive exports. Each run retains its latest 10,000 events; any omitted earlier events are counted in the results. Older reports created before event history was saved explain that the missing events cannot be recovered. Recent lab events shows separate activity from the current application session. Use Cancel Run to end the active run. Export a selected result as JSON or JUnit XML.

Pause freezes simulation time; Resume continues it. Reset returns a stopped lab to its initial recording state. The scenario editor also supports JSON import/export for advanced automation. The seed is available under Advanced for repeatable fault behavior.

In Send trap / INFORM, configure the destination IP/port, protocol, community or SNMPv3 security, notification identifier and uptime in seconds. The Community field is visible and defaults to public. Retries and timeout apply to INFORMs. Add, modify or delete typed variable bindings; Suffix appends numeric arcs to all binding OIDs. Octet strings accept text or hexadecimal bytes. SNMPv3 Settings… offers security level, USM user, authentication/privacy algorithms and passwords, context, and an optional Engine ID. Blank uses an automatic identity; INFORMs discover the receiver engine.

Load Recorded Trap… imports a lab recording or another file. Choose an entry by position, identifier and recorded time, then edit its copied content. Destination, type and security settings stay as configured. The saved action is independent of agents and recording files. OK adds the scheduled action; it does not send immediately. Cancel discards the draft. Versions 1 and 2 scenarios must be recreated as version 3.

Scenario notification actions send once at their scheduled time (INFORMs may retry while awaiting acknowledgement).
Agents started by a scenario also send their normal trap recordings and threshold/script/SET notifications.
These agent notifications are independent of the one-time scenario actions. Notification checks select an action
and count only its events.

Checks tab

The optional Checks tab defines what a scenario must observe to pass. Checks monitor events while the scenario runs; they do not send SNMP requests or schedule actions. Use Add to create a check, Edit to change the selected check, and Remove to delete it. Confirmed changes save automatically. Changes made during a run apply to later runs.

At normal completion, all checks must meet their minimum and maximum counts for the run to be SUCCEEDED. A count outside its range makes the run FAILED. Runtime errors or cancellation have their own outcomes. With no checks configured, success means the actions completed; it does not verify that an external manager received a trap or that a device responded correctly.

Available checks

• Requests received: counts decoded, authorized requests received by the selected agent. An external SNMP manager, such as MIB Browser, must generate the traffic.

• SET value received: counts SET requests containing the configured object identifier, data type and expected value. This verifies receipt of that value, not successful application of the SET. Use Expected SET value > Configure... to enter the OID, type and value.

• SNMP errors returned: counts transmitted responses containing an SNMP error. Leave Error status blank to count any nonzero status, or enter a particular numeric status, such as 5 for genErr.

• Notifications attempted: counts attempts by the selected scenario Send trap / INFORM action.

• Notifications sent: counts local transmissions by that selected action. A successful UDP transmission does not prove that the receiver received the notification.

• INFORM acknowledgements: counts successful acknowledgements received for the selected scenario notification action. Use this check with an INFORM action.

• Requests during outage: counts packets received while the selected agent is unavailable because of an outage or reboot. These packets are discarded before decoding; leave OID, recording and PDU filters blank.

Agent checks select an Agent. Notification checks select a Notification action already present in the Actions tab. They count only that action's events. Automatic traps from agent recordings, thresholds, scripts or SET behavior are independent and do not contribute to a notification action's check.

Configure a check

• Window start (ms) and Window end (ms, exclusive) define the observation window relative to the start of the scenario. The start is included and the end is excluded: a window from 3000 to 4000 counts events at 3000 ms through just before 4000 ms. Use a window within the scenario duration. Pausing the lab freezes simulation time.
• Minimum count and Maximum count define the acceptable range, including both limits. A blank maximum means unlimited. Set both to 1 to require exactly one event; set minimum to 1 and leave maximum blank to require at least one; set both to 0 to require none. The default minimum is 1.

• OID filter (optional) matches an exact object identifier in a decoded request, rather than an OID subtree. Leave it blank to accept any OID.

• Recording selects a recording/context or All recordings. This is useful when an agent serves several recordings through community/context indexing.

• PDU type (optional) accepts a numeric SNMP command code, such as 0 for GET, 1 for GETNEXT, 3 for SET, or 5 for GETBULK. Leave it blank to accept any request type.

• Error status (optional) applies to SNMP errors returned. Expected SET value applies to SET value received. Notification checks do not use the agent-specific filters.

Give actions enough time to complete when choosing a window. An action scheduled at 3000 ms can transmit slightly later, and an INFORM acknowledgement can arrive later still. Requests and responses are separate events and can fall into different windows.

Check examples

Send exactly one trap: add a Send trap / INFORM action at 3000 ms. Add a Notifications sent check, select that action, set the window to 3000 through 10000 ms, and set minimum and maximum to 1. Use a scenario duration of at least 10000 ms. Agent-generated traps do not affect this count.
Confirm an INFORM acknowledgement: configure an INFORM action and a reachable receiver. Add an INFORM acknowledgements check for that action, use a window that includes the configured retry/timeout period, set minimum to 1, and leave maximum blank.
Observe manager requests: start an agent at 0 ms. Add a Requests received check for that agent with a window from 0 to 10000 ms, minimum 3, and maximum blank. During the run, send at least three authorized requests from MIB Browser. If no manager sends requests, the check fails.

The Run results panel shows PASS or NOT PASSED and the observed count for each check. Check results are retained in the saved report and available in JSON and JUnit exports.

Advanced tab

The Advanced tab currently contains Repeatable random seed, which defaults to 0. Enter a whole number using 1 to 30 decimal digits, with an optional leading minus sign. The seed saves automatically and is included in the run report.

The seed controls the simulator's random sequences, including probabilistic packet loss, probabilistic fault selection, variable delays and modeled random values. It does not change action times, scenario duration, notification destinations or SNMP credentials.

For a repeatable test, keep the seed, agent identities, fault rule identities, recordings, configuration and ordered request traffic the same. For example, use seed 42 with a packet-loss fault to repeat the same modeled sequence of decisions for the same traffic. Change the seed to 43 to exercise a different sequence; this does not change the configured loss probability or delay range.

Repeatable random decisions do not guarantee identical wall-clock timings or packet traces. Operating-system scheduling, external manager traffic, retries and scripts with their own clocks or random generators can still change the observations. Keep the default seed when you do not need to choose a different test sequence. See Simulate faults and notifications for fault configuration.