Automation

Automation runs scheduled rules that find suspicious DHCP behaviour and act on it — either by handing the device off to the LLM for analysis, or by applying enforcement directly.

You manage rules from the Automation page at /actions/automation. A rule says, in plain terms: every N minutes, look at this aggregated traffic table for the last M seconds, find devices that match these filters and exceed these thresholds, and apply this action to each. The system ships with a curated set of seed rules and you can add your own.

This is the appliance’s primary anomaly-response surface. The Anomaly Detection (chapter 24) page describes the LLM side of the loop; this chapter is the rules side.

How Rules Run

The scheduler wakes up every rule on its own interval, queries one source table for the lookback window, applies filters and thresholds, and acts.

The lifecycle of a single rule:

ASCII fallback

       every check_interval_seconds
                |
                v
       +--------+--------+
       |  query source   |   one of:
       |     table       |   - llm_dhcp_activity_5min  (fast)
       |                 |   - llm_dhcp_activity_1h    (fast)
       +--------+--------+   - llm_dhcp_activity_24h   (fast)
                |             - llm_dhcp_activity_7d    (fast)
                v             - dhcp_events             (raw, slower, every field)
       +--------+--------+
       |  apply filters  |   protocol, vendor, DUID type,
       |   (optional)    |   hostname, relay, message_type...
       +--------+--------+
                |
                v
       +--------+--------+   "any device with > N requests OR > M unique IPs"
       |  thresholds     |   logic: OR (default) or AND
       +--------+--------+
                |
                v
       +--------+--------+   per matched device:
       |  apply action   |   - analyze (queue for LLM)
       +--------+--------+   - block / throttle / deny / monitor / allow
                              - duration (or rule's default)

When two rules would both fire on the same device in the same cycle, the higher-priority rule wins and the lower one is skipped for that device.

The Rules Table

The main table lists every rule, sortable and filterable, with a row of action buttons per rule.

Filters (collapsible)

Filter	Options
Status	All / Enabled / Disabled
Action Type	All / Analyze / Block / Throttle / Monitor / Allow / Deny
Source Table	All / 5 Minutes / 1 Hour / 24 Hours / 7 Days / Raw Events

Columns

Column	Description
Status	Green “Active” badge if enabled, gray “Disabled” if paused
Name	Rule name and short description
Priority	1–255; higher fires first when rules collide
Frequency	How often the rule runs (`check_interval`)
Next Run	Time until the next scheduled execution (“3m”, “Due now”)
Source	The aggregation table the rule queries
Lookback	How far back the rule queries on each run
Condition	The threshold expression: `Req>1000`, `IPs>50`, or `Req>500 AND IPs>10`
Caught	”last-run / total-recent” devices detected — quick health check
Action	Action type to apply (Analyze / Block / Throttle / Monitor / Allow / Deny)
Actions	Per-row buttons

Per-Row Buttons

Run Now (lightning) — execute the rule immediately, ignoring the schedule. Results open in a modal.
Test (test tube) — dry-run the rule. Same evaluation, but no actions are applied.
Enable / Disable (play / pause) — flip the rule’s enabled state.
Edit — open the rule editor.
Delete — permanent. You are asked to confirm.

Click sort arrows on Status, Name, Priority, or Frequency to reorder. Pagination is shown at the top and bottom.

Test Console — “Which Rules Apply?”

A collapsible panel above the rules table that tests a single device against every enabled rule and shows the verdict per rule.

You arrive at the same evaluator from the Which Rules Apply? section on Device Details (chapter 14).

How to use it:

Expand the panel.
Either type a MAC into the input, or start typing into Search devices to pull results from the device search.
Pick a device from the dropdown (or stick with the typed MAC).
Click Test Rules.

You get back:

A header: how many rules were evaluated, how many would trigger, and the total execution time.
A winning rule badge — the one that would actually run, by priority.
A Device Information card with MAC, hostname, vendor class, and 30-day event count.
An active actions warning if the device already has enforcement applied.
One Rule Evaluation card per rule, sorted by priority.

Each rule card shows whether the filter passed, whether the threshold passed, and the device’s current metrics inside the lookback window. Expanding the card adds source table, lookback, the exact filter conditions, the threshold requirements, and a note on whether evaluation stopped at that rule.

Tip. Use the test console after editing a threshold to confirm the new value catches the device you expected, without waiting for the schedule.

Creating and Editing Rules

Click Create Rule or the edit icon on a rule to open the editor modal. The same form covers both.

Basic Info

Name (required) — a short label used in dashboards, logs, alarms, and the action-history Details column.
Description — free text, shown under the name in the table.

Source Table and Lookback

Source Table	When to use
5 Minutes	Catching bursts; cheap to query. Lookback 300–900 seconds.
1 Hour	Sustained behaviour over the last hour.
24 Hours	Daily patterns; broad-stroke catches.
7 Days	Long-running offenders.
Raw Events	When you need to filter on a field that the aggregations don’t carry (e.g. message type, hostname substring). Slower; use sparingly.

Lookback (seconds) is how far back from “now” the rule queries when it runs. A 5-minute source with a 300-second lookback queries one bucket; with 3600 it queries the last twelve.

Choosing Raw Events unlocks fields like message_type and hostname, but the filter list grows long and the query covers many more rows. Prefer an aggregated source unless you need a raw-only field.

Filter Conditions

A visual filter builder. Each row is field operator value; rows are joined with ALL (AND) or ANY (OR). The available fields depend on the source table — aggregated tables offer protocol, DUID type, vendor class, and a few more; raw events offer the full set including per-packet fields.

Operators are string-aware:

String fields: = (eq), != (ne), ~ (contains), ^ (starts-with), $ (ends-with), rx (regular expression).
Number fields: =, !=, >, >=, <, <=.

Special fields render as dropdowns: protocol offers dhcpv4 / dhcpv6 (with IPv6 hidden when the license excludes it), duid_type offers the four DUID types.

If you leave the filter empty the rule evaluates every client in the source table.

Thresholds

A rule fires for a device when one or both of these thresholds is exceeded inside the lookback window.

Field	Meaning
Min Requests	Trigger if a device sent at least this many DHCP requests
Min Unique IPs	Trigger if a device requested at least this many distinct IPs
Logic	OR (any threshold) or AND (all thresholds)

A typical “flood detector” sets a high Min Requests and Min Unique IPs of 0 with OR. A typical “scanner detector” sets a moderate Min Requests with a high Min Unique IPs and AND.

Action

The action applied to every device that triggers the rule.

Action	What happens
Analyze	Queue the device for LLM analysis using the chosen prompt. No enforcement is applied directly; the LLM decides what to do.
Block	Apply a Block enforcement action (drops DHCP packets in kernel). Duration from this rule’s setting, or the catalog default.
Throttle	Apply a Throttle (rate-limit to ~10 pps).
Monitor	Tag the device for verbose logging but do not enforce.
Allow	Mark the device as trusted; bypass enforcement chains.
Deny	Permanent block + event suppression. Strongest action.

Duration (seconds) — 0 means “use the catalog default” (2 hours for Block, 1 day for Throttle, 7 days for Monitor, 30 days for Allow). Set a custom value if you want the rule to override.
Analysis Prompt — only shown when Action is Analyze. Selects the analysis profile the optional AI backend uses; the profiles ship with the install package.

Scheduling

Check Interval (seconds) — how often the rule fires. 300 (5 minutes) is the default. Don’t run a rule more often than its source table’s bucket size — there’s nothing new to find.
Priority (1–255, higher = first) — used to break ties when multiple rules match the same device in the same cycle.

Enabled

A checkbox. When unchecked, the rule is skipped by the scheduler. The Run Now and Test buttons still work for an examination of “what would happen if I turned this on?”.

Conflict Resolution

Highest priority wins.

When the scheduler runs a cycle, it sorts every active rule by priority descending. As it processes each rule, any device that already matched a higher-priority rule in the same cycle is skipped — even if it would also have matched the current rule.

Practical consequences:

A Block rule at priority 95 will always take a device away from an Analyze rule at priority 55, in the same cycle.
If you want a strong, certain action (Critical Volume → Block) to be unaffected by a softer rule, give it a clearly higher priority.
“Analyze for context” rules typically sit at priorities 50–60; direct-enforcement rules at 70–95.

The seed rules ship with deliberately spaced priorities (40–95) to make it easy to slot new rules between them.

Default Seed Rules

Fresh installs ship with around a dozen pre-configured rules. They are enabled by default.

The seeds cover a few categories:

Category	Examples	Action
DHCPv6 acceptance	DUID-Only Clients (no extractable MAC)	Allow
IPv4 volume tiers	Critical (>5000 req / 5 min), High (>2000), Elevated (>500)	Block / Throttle / Analyze
IPv6 volume tiers	Critical (>10000 req / 5 min), High (>5000), Elevated (>1000)	Block / Throttle / Analyze
Behavioural	IP Scanning Pattern, Unknown Device Analysis, Enterprise DUID Monitoring	Analyze / Monitor
IPv4 attack patterns	Broadcast Storm (DISCOVER flood), Lease Hoarder, Resource Exhauster (REQUEST flood)	Block / Throttle

Priorities are picked so that the strongest actions (Critical Volume → Block) sit above the analysis rules. The seeds are flagged as system-created, which means they still belong to you — you can edit, disable, or delete them like any other rule. They are just shipped that way to give the appliance a useful baseline on day one.

Reinstalling the appliance does not overwrite existing rules — the seed pass only adds rules that are missing. There is no rule export/import in the GUI yet, so preserving tuned rules across a full database wipe requires a database backup.

Execution History

Click History in the page header to toggle a panel showing the 50 most recent rule executions.

Columns:

Column	Meaning
Time	When the rule ran
Rule	Rule name
Status	Success or Error
Detected	How many devices the rule matched in that run
Actions	How many actions were applied (usually equal to Detected, but conflict-resolution can lower it)
Time (ms)	Execution time in milliseconds

Use this to spot rules that are silently mis-firing (Detected = 0 every run) or running slowly (Time (ms) climbing). Slow rules are usually pointed at Raw Events with a wide lookback — switch to an aggregated source or tighten the lookback.

Run Now vs Test

Run Now executes the rule and applies actions; Test does the same query without applying anything.

Behaviour	Run Now	Test
Queries source table	Yes	Yes
Applies filters and thresholds	Yes	Yes
Writes actions to the audit log	Yes	No
Updates nftables sets	Yes	No
Resets the scheduler’s last-run timestamp	Yes	No
Modal shows detected devices	Yes	Yes

The result modal lists up to 20 detected clients with their protocol, request count, and unique-IP count. For Test mode the heading is “would be detected”; for Run Now it is “detected and actioned”.

Caution. Run Now bypasses the cooldown and conflict-resolution between rules — it just runs this rule against the current data and applies the action to every match. Use Test first if you are not sure how many devices the rule will catch.

What Gets Written When a Rule Fires

For each detected device the system:

Adds a row to the action audit table (visible in Actions History (chapter 15)) with automation as the executor and the rule name in Details.
For Block / Throttle / Monitor / Allow / Deny: updates the matching nftables set (llm_blocked_marks, llm_throttled_marks, etc.) with the configured duration.
For Analyze: enqueues the device for LLM analysis using the rule’s chosen prompt. The result lands on Device Analysis (chapter 17) and may itself trigger an Automated Action (chapter 25) based on the risk score.
For matching alarm channels, a action:automation:<rule-name> alarm may be raised — see Alarms (chapter 11).

Actions (chapter 15) — the audit log for every action automation writes.
Device Analysis (chapter 17) — the LLM verdicts produced by Analyze rules.
Automated Actions (chapter 25) — the risk-score-to-action policy that runs after Analyze.
Anomaly Detection (chapter 24) — the analyser side of the loop.
Firewall Manager (chapter 20) — set sizes and per-action defaults the rules ride on.
Device Details — Which Rules Apply? (chapter 14) — the same evaluator pivoted around one MAC.

Troubleshooting

A rule says “Caught: -” but I know the traffic is there. Check the source table and lookback. A 5-minute table needs traffic in the last 5 minutes for the corresponding bucket to populate. Try Test with the rule still disabled — if Test says zero, narrow the filter or lower the threshold. If Test says non-zero but live runs say zero, look at the conflict-resolution: a higher-priority rule may be claiming the devices first.

A rule fired but I see no nftables set entries. If the action is Analyze, that is expected — Analyze does not write to enforcement sets directly. The LLM verdict on Device Analysis (chapter 17) is what may then trigger an action. For direct-enforcement actions, check the action audit log: a write to the audit table without a corresponding kernel-set update usually means the appliance couldn’t reach the nftables tables (look at Alarms (chapter 11)).

My new rule is correct but never runs. Confirm the rule is Enabled and that its Next Run in the table shows a real countdown rather than -. If Next Run is -, the rule is disabled or the scheduler hasn’t picked it up yet — refresh the page.

Two rules keep stepping on each other. Use the Which Rules Apply? test console: type a problem MAC and look at the priority badges and the “winning rule” marker. Adjust priorities so the rule you want to win sits clearly above the others.