Overview
Four planes
The appliance is built around four cooperating planes. Each does one job, and each can fail without taking the others — or your DHCP service — down with it.
Architecture & data flow.
Inspect in userspace, enforce in the kernel, keep the record on the appliance. Here's how the pieces fit.
Data plane — inspection
Reads every DHCPv4 and DHCPv6 exchange in full and extracts the fields that identify a client and its intent — message type, hardware address, vendor class, client identifier, and relay-agent information. This is where deep packet inspection happens, in userspace, where the full protocol can be parsed.
Enforcement plane — verdicts
Turns an inspection result into a kernel-level decision: accept, rate-limit, or drop. Because enforcement lives in the Linux kernel rather than a userspace proxy, it keeps pace with line-rate DHCP and adds negligible latency to legitimate traffic.
Analytics plane — the record
Stores every transaction in a high-throughput, on-appliance data store, pre-aggregates it for fast historical queries, and feeds the report builder, the network map, and the scheduled automation rules. This is the plane that answers "what happened, and why" after the fact.
Streaming plane — live view
Broadcasts transactions and alarms in real time to the operator display and to downstream pipelines, so operators can watch the network as it changes and route events into the tools they already run.
Pipeline
How a DHCP packet flows
In the default inline deployment, every DHCP packet takes the same short path through the appliance before it reaches your DHCP server:
- 1
A client sends a DHCP request. It arrives at the appliance, which sits on the path between your clients (or relays) and your DHCP server.
- 2
The Linux kernel hands the DHCP packet up to the inspection engine. Non-DHCP traffic is never touched.
- 3
The engine parses the packet in full, identifies the client, and decides what should happen to it — based on your rules, the client's current state, and any active enforcement.
- 4
The engine returns a verdict. The kernel enforces it inline: the packet is accepted, rate-limited, or dropped.
- 5
Independently of the verdict, the parsed transaction is recorded to the on-appliance store, streamed live to the operator display, and made available to downstream pipelines.
- 6
Accepted packets continue to your DHCP server, which replies as normal. Scheduled automation later reviews the aggregated record and can escalate or relax enforcement on its own cadence.
The whole inspect-and-enforce step adds only a small, fixed cost per packet, and it applies only to DHCP — the protocol that needs watching, not your general network traffic.
Deployment
Deployment modes
Inline (default)
The appliance sits on the DHCP path and can enforce. This is the mode to plan for: full inspection plus the ability to block, deny, throttle, allow, or monitor live traffic. Recommended for production.
Mirrored (passive)
The appliance receives a copy of DHCP traffic from a switch mirror or SPAN port and observes only — full inspection, analytics, and detection, but no enforcement. A low-risk way to evaluate the product or monitor a network you don't want to sit in front of.
From remote sites
Lightweight agents at each remote site forward a copy of local DHCP traffic to a central appliance for inspection, giving you one pane of glass across many locations. Observation-only at the remote sites; pair it with an inline appliance at headquarters for enforcement where it counts.
Inline and observation modes can run side by side: enforce on your primary network while passively monitoring remote sites from the same appliance.
Resilience
If inspection stops, DHCP keeps flowing
The most important property of an inline appliance is what happens when it fails. DHCP Shield Pro is built to fail open: if the inspection service is unavailable for any reason, the kernel passes DHCP packets straight through. Your clients keep getting leases and your DHCP server keeps answering — the appliance simply stops inspecting until it recovers.
That means your DHCP service never depends on the appliance staying up. Enforcement is something you add on top of a network that already works, not a single point of failure you bolt into the critical path. For the full picture of how the planes degrade independently, see the reliability and resilience notes under trust.
Storage
Where data lives
| Data | Where it's stored | Retention |
|---|---|---|
| DHCP transactions | On the appliance | Configurable |
| Pre-aggregated traffic | On the appliance | Derived from transactions |
| Audit log (every change and enforcement action) | On the appliance | Indefinite by default, configurable |
| Active enforcement state | Linux kernel | Per-action defaults: Block 2 h · Deny indefinite · Throttle 24 h · Allow 30 d · Monitor 7 d |
No telemetry leaves the appliance, and there is no mandatory phone-home. Nothing crosses your network boundary unless an operator explicitly opens a support session. For the full data-flow disclosure, see trust/data-flow.
Architecture & data flow.
Inspect in userspace, enforce in the kernel, keep the record on the appliance.