Skip to content

Dashboard

The Dashboard is your home page. It shows live network health, firewall activity, anomaly detection, client behaviour, and system status through configurable widget panels.

You can keep the default dashboard, edit it, build new ones from scratch, import dashboards shared by a colleague, and cycle through several dashboards on a wall display. Every dashboard is per-user and saved automatically.


Every dashboard has two modes: View and Edit. You toggle between them with the button in the top-left of the toolbar.

In View mode you see widgets as a read-only display. Widgets refresh on their own schedule and you cannot rearrange them. This is the safe everyday mode.

In Edit mode you can add widgets, remove them, drag them to a new position, resize them, change their settings, and rename the dashboard. An unsaved-changes indicator appears next to the dashboard name. You must press Save to keep your changes, or Cancel to revert. Leaving Edit mode without saving prompts you to keep or discard.

You can create as many dashboards as you want. There is no fixed limit.

A typical setup is one dashboard per role or per task: an operator overview, an IPv6 view, a NOC wall display, a firewall-only view, a deep-dive view used during incidents. New dashboards start either empty or as a copy of an existing one.

The active dashboard is shown in the toolbar. You switch between dashboards from the dashboard selector dropdown or from the side menu.

Dashboards appear in the side menu in the order you choose. You can move them up and down at any time.

Open the dashboard list in the side menu. Each entry has small up and down arrows. Each click moves that dashboard one position in either direction. The new order is saved immediately and is preserved across logins.

Dashboards are portable. You can export one to a JSON file, share it, and import it on another installation.

  • Export writes the current dashboard’s full definition (widgets, layout, settings) to a JSON file. You can also copy the JSON straight to the clipboard.
  • Import accepts either a JSON file or pasted JSON. The import is validated before it is added. You can import as a new dashboard or overwrite an existing one.

This is useful for backing up a layout you spent time tuning, for sharing operator templates between team members, and for moving dashboards from a test installation to production.

Rotation cycles automatically through your dashboards on a configurable timer. It is intended for wall displays.

Press the rotate button in the toolbar to start. The system switches to the next dashboard every interval (30 seconds, 1 minute, 2 minutes, 5 minutes, 10 minutes — you choose). A progress bar across the top shows the time left in the current rotation. Press the button again to stop.

Rotation respects the dashboard order from the side menu, so reordering also reorders the rotation.

Kiosk mode is a full-screen presentation mode designed for wall displays and pinned monitors.

Press the maximise button in the toolbar. The browser switches to full-screen, the side menu and toolbar fade away, and the cursor hides after a few seconds of inactivity. The system also asks the browser to keep the screen awake so a dedicated NOC monitor will not blank.

Press Escape to leave kiosk mode.

Kiosk mode and Rotation work together. The typical NOC pattern is: open a dashboard, start rotation, then enter kiosk mode.

A protocol selector in the toolbar restricts every widget on the dashboard to DHCPv4, to DHCPv6, or to both.

Three options are available:

OptionWhat you see
All ProtocolsDHCPv4 and DHCPv6 combined
IPv4 OnlyDHCPv4 traffic only
IPv6 OnlyDHCPv6 traffic only

If your license does not include IPv6 support, the selector hides the IPv6 options and locks to IPv4. The setting is saved per dashboard, so you can have one dashboard pinned to IPv6 and another pinned to IPv4.

All widgets share a single time range that you control from the toolbar.

Two ways to pick a range:

  • Relative presets — Last 5 minutes, 15 minutes, 30 minutes, 1 hour, 3 hours, 6 hours, 12 hours, 24 hours, 2 days, 7 days, 30 days, 90 days.
  • Absolute range — Pick a start and end date and time from a calendar.

Next to the picker are previous and next arrows. They step the current window backward or forward by one window length, which is the fastest way to scrub through history.

A separate refresh-interval control sets how often live widgets re-fetch their data: off, 5 seconds, 10 seconds, 30 seconds, 1 minute, 5 minutes, 15 minutes. A manual refresh button forces every widget on the dashboard to reload at once.

Tip. Very wide time ranges (30+ days) can be slow because the underlying queries cover more data. If a widget is sluggish, narrow the range first.


The Add Widget picker in Edit mode groups widgets into the categories below. Every widget listed here is available out of the box.

A gauge showing the percentage of DHCP request transactions that received a successful response (REQUEST to ACK for DHCPv4, REQUEST/RENEW/REBIND to REPLY for DHCPv6). Healthy networks score above 95 percent; values below 80 percent indicate broken transactions worth investigating.

A gauge showing the server’s approval rate for lease decisions, independent of firewall blocking. A drop here points at server-side problems such as pool exhaustion or misconfiguration rather than at the firewall.

A gauge showing what share of DHCP traffic the firewall is blocking before it reaches the DHCP server. Use it to see how much load the firewall is actually shouldering.

An area chart of message rates broken down by type (DISCOVER, OFFER, REQUEST, ACK, NAK, DECLINE, RELEASE, INFORM). Use it to spot traffic spikes and to catch imbalances like DISCOVERs without matching OFFERs.

Unique MAC addresses observed in all DHCP requests types

Section titled “Unique MAC addresses observed in all DHCP requests types”

A bar chart of distinct client MAC addresses per 15-minute window. A sudden jump can mean rogue devices, MAC spoofing, or scanning; a gradual climb is just network growth.

Unique IP addresses observed in all DHCP requests types

Section titled “Unique IP addresses observed in all DHCP requests types”

A bar chart of distinct IP addresses handed out via DHCP ACK per 15-minute window. Compare it against your pool size to assess utilisation and catch starvation attempts.

Total DHCP messages Over Time (1 minute aggregated window)

Section titled “Total DHCP messages Over Time (1 minute aggregated window)”

A line chart of total DHCP message volume per minute across all types. It is your traffic baseline — sudden drops suggest network or upstream issues, sudden spikes suggest attacks or events.

A bar gauge showing how many lease times of each length are seen on the network. Use it to confirm your lease policy is taking effect and to spot misconfigured servers handing out unexpected lease lengths.

A bar chart of DHCP traffic volume per relay agent IP (top 20). It tells you which network segments generate the most DHCP traffic and helps you spot a failed or overloaded relay.

A line chart of the percentage of DISCOVER messages that receive an OFFER, over time. Below 90 percent for long stretches typically points at server overload or pool exhaustion.

DHCP Traffic Volume and Message Type distribution (15 minutes clusters)

Section titled “DHCP Traffic Volume and Message Type distribution (15 minutes clusters)”

A stacked bar chart of total DHCP volume broken down by message type, bucketed in 15-minute windows. Good for spotting peak hours and seeing how the type mix evolves through the day.

A line chart of the end-to-end transaction success rates: new-client rate (DISCOVER to OFFER / SOLICIT to ADVERTISE), request fulfilment (REQUEST to ACK / REPLY), and rejection rate. The single best widget for spotting service quality regressions.

A line chart of packet rates through the firewall’s DHCP inspection path — inbound, outbound, marked, and total. A growing gap between inbound and total indicates active filtering at the kernel.

A stacked area chart of all packets the firewall has dropped, broken down by DHCP message type. Shows you which message types are being rate-limited or blocked, for both DHCPv4 and DHCPv6.

A line chart of how many MAC addresses are currently being rate-limited at the kernel level. These devices have exceeded the configured rate threshold and are temporarily blocked until the limit expires.

A gauge showing the share of DHCP packets that reach userspace inspection. A full 100 percent means every packet is being inspected.

A line chart of how full the blocked-MACs set is, as a percentage of capacity. Approaching 100 percent means the oldest blocks will start being evicted; consider raising the set size or shortening block durations.

A Sankey diagram showing how DHCP traffic flows through the firewall — total seen, packets blocked, packets accepted, and the per-message-type breakdown. The clearest single view of what the firewall is doing to your traffic.

A line chart of how fast packets are being tagged with a per-MAC firewall mark. Higher values mean the firewall is tracking more clients for rate-limiting or blocking decisions.

A stacked time series of inbound DHCPv4 traffic per message type, with accepted and dropped stacked together so total bar height equals total attempted traffic.

A stacked time series of outbound DHCPv4 traffic per message type, with accepted and dropped stacked together so total bar height equals total attempted traffic.

A stacked time series of inbound DHCPv6 traffic per message type, with accepted and dropped stacked together so total bar height equals total attempted traffic.

A stacked time series of outbound DHCPv6 traffic per message type, with accepted and dropped stacked together so total bar height equals total attempted traffic.

A mirrored time series of inbound DHCPv4 traffic: accepted plotted above the axis, dropped plotted below it. Easier than a stacked view when you want to compare accept vs drop side-by-side.

A mirrored time series of outbound DHCPv4 traffic: accepted above the axis, dropped below it. Same pattern as the inbound mirror, for the server-to-client direction.

A mirrored time series of inbound DHCPv6 traffic: accepted above the axis, dropped below it. Useful when DHCPv6 drop volumes need to be visually weighed against accepts.

A mirrored time series of outbound DHCPv6 traffic: accepted above the axis, dropped below it. The DHCPv6 counterpart to the v4 outbound mirror view.

A line chart showing how many MAC addresses are currently in each LLM-driven action set: blocked, denied, throttled, allowed, monitored. A growing blocked set signals active threat response.

A single number showing the total count of anomalies the LLM detected during the selected time range. A rising trend can mean an ongoing attack; zero during real traffic suggests a clean network.

A single number showing how many alerts in the time range had a risk score of 0.7 or higher. Any non-zero value is worth opening the alerts table and reviewing.

A single number showing how many alerts the LLM has flagged for manual review because it could not auto-remediate them. These are your priority items to triage.

A single number showing the mean risk score across all alerts in the window, on a 0-to-1 scale. Below 0.4 is normal, 0.4-0.7 is elevated, above 0.7 is critical.

A line chart of average LLM risk score over time. Sustained elevation correlates with ongoing issues; sharp spikes correlate with specific attacks.

A pie chart breaking down detected anomalies by category: MAC spoofing, DHCP starvation, coordinated attack, suspicious pattern, normal. Helps you prioritise which response playbook applies.

A table of recent anomaly alerts with MAC, anomaly type, risk score, and recommended action. Click a row to see the full evidence. This is the primary interface for investigating threats.

A table of the MAC addresses with the highest maximum risk score and alert count. Use it to spot repeat offenders that may need a permanent block rather than another temporary action.

A scrolling real-time feed of anomaly alerts, colour-coded by severity. Designed for NOC wall displays where compact at-a-glance status matters more than detailed interaction.

A single number showing how many suspicious activities are queued for LLM analysis but not yet processed. A high count means analysis is backed up; zero means everything suspicious has been looked at.

A table of the suspicious activities waiting for analysis, with MAC, vendor, request count, unique IPs requested, and suspicion reasons. Use it to triage manually when the LLM queue is deep.

A table of events that the LLM has flagged as requiring operator action. It is a focused queue of “needs a human” alerts; an empty table means everything has been addressed.

A single number showing how many automation alarms are currently in the firing state — rules have detected a threshold violation and the alarm has not yet been acknowledged or resolved. Zero is the normal state.

A single number showing how many alarms an operator has acknowledged but not yet resolved. Acknowledging pauses escalation; a high count means people are aware but remediation is still pending.

A single number showing how many alarms have been resolved in the time range. Compare it against the firing count to gauge how effective your response is.

A single number summing firing, acknowledged, and resolved alarms in the time range. Use it as an overall automation-activity indicator across all states.

A bar chart of how many actions each automation rule has triggered in the time range. The tallest bars are your most active rules; the empty ones may be too narrow or obsolete.

A table of the clients with the most DHCP requests in the time range, with MAC, hostname, vendor class, and last-seen time. Normal clients sit at 1-4 requests per lease cycle; anything in the hundreds is worth a look.

A treemap visualisation of the same top-clients data, sized by request count. Single-click for a details popup, double-click to jump to that device’s history page.

A pie chart breaking your client fleet down by vendor class (DHCP Option 60). Helpful for inventory and for spotting unexpected device types.

A horizontal bar chart showing the same vendor breakdown, top 20. Easier than the pie chart when you need to compare many vendors precisely.

A histogram bucketing clients by request count. Most clients should fall in the 1-9 bucket; clients in the 100-999 range are typically misconfigured, and anything above 1000 warrants investigating for loops or attacks.

A bar gauge of utilisation per network pool, colour-coded green (under 70 percent), yellow (70-90 percent), red (over 90 percent). The quickest way to spot a pool about to run out of addresses.

A table of the same pool-utilisation data with the underlying numbers: network, subnet mask, unique IPs, total assignments, IP range, pool size, utilisation percentage. Use it when you need the exact figures and not just the colour.

A bar gauge showing the count of unique IP addresses observed per pool, for both IPv4 and IPv6 pools. A direct view of how much of each pool has actually been used.

A table of the top 100 vendor classes with counts and percentages. Use it for compliance auditing and for spotting unauthorised device types you did not expect on the network.

A pie chart showing how DHCP traffic is distributed across your matching rules. Helps you confirm rules are firing as expected and spot rules that handle most of the traffic.

A bar chart of the same per-rule trigger counts, which is easier to read than the pie when several rules have similar share. Useful for rule optimisation work.

A status indicator showing overall system health: Healthy, Warning, or Error. If it is not Healthy, open the status panel for a per-component breakdown.

A single number showing current packet processing throughput in packets per second. Drops below your baseline can point at CPU saturation or a queue bottleneck.

A single number showing how many firewall actions (blocks, throttles, denies) are currently active. Expected to be high during an attack; persistently high in quiet times may indicate stale entries.

A line chart of packet-processing latency in milliseconds. Stable, low values (under 10 ms) are healthy; sustained spikes correlate with traffic surges or system load.

A bar chart comparing DHCPv4 vs DHCPv6 traffic side-by-side — message counts, unique clients, and success rates. Use it to confirm both protocols are healthy in a dual-stack network.

A pie chart of the DHCPv6 client DUID types observed (DUID-LLT, DUID-EN, DUID-LL, DUID-UUID, and unknown). Unusual distributions can flag misbehaving clients.

A bar chart of DHCPv6 prefix-delegation activity by prefix length (/48, /56, /64, and so on). Use it to understand how IPv6 address space is being allocated and to plan future capacity.


Tip. If a widget shows no data on a fresh installation, give the system some traffic time, or run a load generator. Most widgets need a few minutes of real DHCP activity before they have anything to display.

Tip. Build a small set of role-specific dashboards instead of one giant one. A focused 6-widget operator view is much more useful in an incident than a 30-widget overview that takes a full screen-scroll to read.


When you Deny a device, it disappears from most traffic and behaviour widgets. That is intended, not a fault. This section names every widget and says exactly how a Deny affects it, so a quiet chart is never mistaken for a broken one.

A Deny does two things at once:

  1. It drops all of the device’s DHCP packets at the firewall.
  2. It stops recording the device in the DHCP event log.

Most widgets are built from the DHCP event log, so the denied device falls out of them. The firewall is still doing its job — you can confirm that in the firewall drop and set-size widgets, which rise.

Deny is not the same as Block. A Block also drops the device’s packets, but it keeps recording the device. A blocked device therefore stays visible in the behaviour widgets while its packets are dropped. Only Deny makes a device go silent.

All effects below apply to data recorded after the Deny takes effect. If your time range still covers the period before the Deny, the device’s earlier activity is shown unchanged.

A widget’s data source decides how a Deny affects it. Every widget is fed by one of these:

  • DHCP event log — the record of every DHCP message seen. Denied devices are not written here, so they fall out of any widget built from it.
  • Firewall packet counters — kernel counts of accepted and dropped packets per message type. Denied packets are counted as drops, so drop widgets rise.
  • Firewall set sizes — how many devices are currently held in each firewall set. The Denied set grows.
  • LLM analysis records — anomaly findings already produced by the analyzer. A Deny does not add or remove these.
  • Automation history — the record of automation rules firing and the actions they took.
  • Active actions list — the enforcement actions currently in force.
  • Live inspection engine — real-time counters from the inspection engine. Denied packets are still inspected, so these do not drop.
WidgetWhat feeds itEffect of a Deny
DHCP Service Health ScoreDHCP event logUsually improves — the denied device’s failed requests are no longer counted
Server Decision RateDHCP event logSmall change — denied requests drop out of the calculation
Firewall Load ReliefFirewall packet countersRises — denied packets count as load removed from the server
DHCP Messages Per Second by Message TypeDHCP event logFalls — the denied device’s messages stop appearing
Unique MAC addresses observed in all DHCP requests typesDHCP event logFalls — the denied MAC is no longer counted
Unique IP addresses observed in all DHCP requests typesDHCP event logFalls
Total DHCP messages Over Time (1 minute aggregated window)DHCP event logFalls
Lease Duration DistributionDHCP event logSmall fall — denied devices get no lease and stop appearing
Relay Agent TrafficDHCP event logFalls for any relay that carried the denied device
DISCOVER to OFFERDHCP event logFalls — denied DISCOVERs stop appearing
DHCP Traffic Volume and Message Type distribution (15 minutes clusters)DHCP event logFalls
Transaction Fulfillment RatesDHCP event logChanges — denied transactions drop out of the rate
WidgetWhat feeds itEffect of a Deny
DHCP Traffic Inspection Flow (packets/s)Firewall packet countersNo change — denied packets are still inspected and counted as incoming
Dropped Packets by Message TypeFirewall packet countersRises — denied packets are counted here as drops
Rate-limited MACsFirewall set sizesNo change — Deny uses a different set from rate-limiting
Packets to UserspaceFirewall packet countersNo change — denied packets still reach the inspector
Blocked MACs Set %Firewall set sizesNo change — Deny uses a different set from rate-limiting
Traffic FlowFirewall packet countersRises — more traffic is shown as filtered before the server
Traffic Marked Over TimeFirewall packet countersNo change — denied devices are still marked
DHCPv4 Inbound Traffic (Stacked)Firewall packet countersRises — the dropped portion grows while accepted shrinks
DHCPv4 Outbound Traffic (Stacked)Firewall packet countersIndirect, smaller fall — the server answers fewer requests
DHCPv6 Inbound Traffic (Stacked)Firewall packet countersRises — dropped grows while accepted shrinks
DHCPv6 Outbound Traffic (Stacked)Firewall packet countersIndirect, smaller fall — the server answers fewer requests
DHCPv4 Inbound Traffic (Mirror)Firewall packet countersRises — dropped grows while accepted shrinks
DHCPv4 Outbound Traffic (Mirror)Firewall packet countersIndirect, smaller fall
DHCPv6 Inbound Traffic (Mirror)Firewall packet countersRises — dropped grows while accepted shrinks
DHCPv6 Outbound Traffic (Mirror)Firewall packet countersIndirect, smaller fall
WidgetWhat feeds itEffect of a Deny
LLM Action SetsFirewall set sizesRises — the Denied series grows. This is the widget that shows your Deny.
Total LLM AlertsLLM analysis recordsNo change — reflects past analysis, not live traffic
High Risk AlertsLLM analysis recordsNo change
Action RequiredLLM analysis recordsNo change
Average Risk ScoreLLM analysis recordsNo change
Risk Score TrendsLLM analysis recordsNo change
Anomaly Types DistributionLLM analysis recordsNo change
Recent Anomaly AlertsLLM analysis recordsNo change
Top Risky MAC AddressesLLM analysis recordsNo change — a denied MAC can still appear from earlier findings
Alert FeedLLM analysis recordsNo change
Pending AnalysisLLM analysis recordsNo change
Pending Analysis QueueLLM analysis recordsNo change
Suspicious ActivityLLM analysis recordsNo change

A denied device stops generating traffic, so over time it produces no new alerts. Existing alert counts stay as they were.

WidgetWhat feeds itEffect of a Deny
Firing AlarmsAutomation historyRises if the Deny was raised by an automation rule
Acknowledged AlarmsAutomation historyChanges as you acknowledge alarms
Resolved AlarmsAutomation historyChanges as alarms are resolved
Total AlarmsAutomation historyRises if an automation rule’s Deny raised an alarm
Actions by RuleAutomation historyRises — the Deny is recorded against the rule that issued it

These react only to automation activity. A Deny you apply by hand is not an automation event — it appears under Active Actions (System Status) instead.

Every Client Behavior widget is built from the DHCP event log, so a denied device leaves all of them.

WidgetWhat feeds itEffect of a Deny
Top Active ClientsDHCP event logDrops off the list
Top Active Clients (Treemap)DHCP event logDrops off
Vendor DistributionDHCP event logFalls for the denied device’s vendor
Vendor Distribution (Bar)DHCP event logFalls for the denied device’s vendor
Request Frequency DistributionDHCP event logFalls
DHCP Pool UtilizationDHCP event logSmall fall — denied devices hold no leases
DHCP Pool Utilization (Table)DHCP event logSmall fall
IP Addresses per PoolDHCP event logSmall fall
Device Analysis by VendorDHCP event logFalls
WidgetWhat feeds itEffect of a Deny
Rules Triggered (Pie)DHCP event logFalls — the denied device’s rule matches stop being logged
Rules Triggered (Bar)DHCP event logFalls — the denied device’s rule matches stop being logged
WidgetWhat feeds itEffect of a Deny
System StatusLive inspection engineNo change — denied packets are still inspected
Processing RateLive inspection engineNo change — the engine still processes the traffic
Active ActionsActive actions listRises — a Deny adds an active action
Processing Time TrendsLive inspection engineNo change
WidgetWhat feeds itEffect of a Deny
Protocol ComparisonDHCP event logFalls
DUID Type DistributionDHCP event logFalls
Prefix Delegation RateDHCP event logFalls