| Time | User | Category | Event | Result |
|---|
| Time | Proto | Event | Address | Identifier | Lease |
|---|
Apply this config to a running Kea server with no restart. Apply & save updates only the scopes you changed (via the subnet_cmds hook) and writes the file — the safest option. Full replace rewrites the entire running config; use it only if per-scope apply isn't available. If the helper isn't running, copy the commands into a terminal instead.
These talk to Kea's UNIX socket, so run them on the Kea server (or over SSH). Keep that socket owned by Kea's own user, and never expose an HTTP control port to the network without TLS and authentication in front of it.
A backup of the running config is saved automatically before every apply. Restore one to roll back — restoring takes a fresh backup first, so it's undoable too. Newest first; the most recent 20 per family are kept.
Sign in to continue
© 2026 Vavefy LLC — all rights reserved.
Proprietary software. Unauthorized copying or distribution is prohibited.
Add user
"Add user" sets a starting password they must change. "Send invite" emails them a link to set their own — no password needed.
All users
Canonicalize an address — the full form with every group, and the shortest :: form.
Interface identifier from a MAC — U/L bit flipped and ff:fe inserted. Add a /64 to see the full address.
A random fd00::/8 unique-local /48 for private addressing.
Plan a delegated prefix into subnets, then tap any result to delegate it further — down to /64.
Split a block into equal subnets — pick the size, or say how many you need.
Relay DHCPv4 & DHCPv6 from your edge router to this Kea server. Pick your platform and drop the config on the sub-interface facing your subscribers.
IOS XR binds a relay profile to the sub-interface. The interface's own address becomes the giaddr (v4) / link-address (v6) that Kea keys on.
interface Bundle-Ether100.10 encapsulation dot1q 10 ipv4 address 10.20.30.1 255.255.255.0 ipv6 address 2001:db8:0:1::1/64 ipv6 nd managed-config-flag ipv6 nd other-config-flag !
dhcp ipv4 profile KEA-RELAY relay helper-address vrf default 198.51.100.10 ! interface Bundle-Ether100.10 relay profile KEA-RELAY !
dhcp ipv6 profile KEA-RELAY6 relay helper-address 2001:db8:0:1::10 ! interface Bundle-Ether100.10 relay profile KEA-RELAY6 !
IOS XE keeps it all on the interface: ip helper-address for v4 and ipv6 dhcp relay destination for v6. The interface address is the giaddr / link-address Kea keys on.
interface GigabitEthernet0/0/1.10 encapsulation dot1Q 10 ip address 10.20.30.1 255.255.255.0 ip helper-address 198.51.100.10 ipv6 address 2001:db8:0:1::1/64 ipv6 nd managed-config-flag ipv6 nd other-config-flag ipv6 dhcp relay destination 2001:db8:0:1::10 !
! insert relay-agent info (option 82) on relayed requests ip dhcp relay information option
A plain-language guide to running ISC Kea through Kea-Ora. Written for network engineers, not coders. No command line after setup — it's all buttons.
Kea-Ora is a web UI for ISC Kea. Kea is the DHCP server doing the real work; Kea-Ora is the friendly face on top of it. There are two moving parts:
127.0.0.1 only, on purpose, so it's never exposed to the network.The mental model that makes everything else click: you build your intended config in the page, then push it to Kea in one action. Nothing you type is live until you apply it. That "draft, then apply" rhythm is the heart of the tool.
Two facts that save confusion later:
http://<server-ip>:8765, or http://127.0.0.1:8765 through your SSH tunnel).admin with the one-time password the installer printed.If you ever lock yourself out, there's an emergency reset-kea-password.py on the server for exactly that.
A quick tour so the rest of the guide has names to point at:
Before the buttons, a principle: start with a plan, not a scope. The quickest way to a messy network is to open Add Scope and improvise pool boundaries on the spot. Five minutes in the planner first — deciding how your address space is actually carved up — saves you from overlapping pools, dead-end subnets, and the renumbering that eats a weekend later. Kea-Ora ships the planners precisely so "do it right" is the easy path, not the tedious one. Plan first, and the rest of the tool is just transcription.
So the real loop has four beats: plan → build → validate → apply.
That's it. Plan → build → Validate → Apply & save. A few supporting buttons:
Habit worth forming: Validate before every Apply. It's free, it's instant, and it turns "why did that break" into "oh, it told me."
A scope is one subnet (v4) or prefix (v6) that Kea hands addresses from. Click Add scope to open the editor. Ideally you're not inventing numbers here — you're transcribing the boundaries and pool sizes you already worked out in the planner (§10). The planner is where you make the plan; the scope editor is where you commit it; Apply is what makes it live. Keep those three roles distinct in your head and the tool stays simple.
203.0.113.0/24 (v4) or a /64 (v6). Required.69.163.69.163, 1.1.1.1) for v4 and Cloudflare (the 2606:4700:4700:: pair) for v6. The Preset… menu beside the field fills in a known resolver — Cloudflare, Google, Quad9, OpenDNS, Cloudflare Families, AdGuard, or CentraCom (IPv4 only) — with the right addresses for whichever family (v4/v6) you're in. It's just a shortcut; the field stays fully editable, so type your own whenever you like.giaddr Kea keys on — not the server's IP. You only need this when the relay's address sits outside this scope. (This is exactly what the Router relay setup tool helps you configure on the router side — see §10.)These don't change how Kea behaves — they're for you, so a scope isn't an anonymous subnet six months later. Location, Router name, Router interface, VLAN, and Service type. They show on the scope row and in properties, so you can tell at a glance that 203.0.113.0/25 is core-rtr-01 · vlan 200 at a given site. For an ISP juggling hundreds of subnets, this is the difference between a tool you trust and a spreadsheet you dread.
In v6 mode the editor adds a PD group: PD prefix, PD length, and delegated length. This is how you hand prefixes (not just addresses) down to customer routers — e.g. delegate a /60 out of a /50 pool. New v6 scopes pre-fill sensible defaults so the group is ready when you need it.
You can restrict a scope to known clients by MAC (v4) or DUID (v6). Kea-Ora compiles your allowlist into Kea client-classes under the hood, so only listed devices get a lease from that scope.
A scope's pool can also be paused (the ⏸ toggle in the scope editor, or the ⏸ shortcut on its row) — useful when draining customers to another pool. A paused pool issues no new leases and refuses renewals, so clients re-DISCOVER into other pools as their leases come up for renewal; the pool, its config and existing leases stay intact until you resume. Under the hood it's a never-matching guard class (KO-PAUSED) required on the pool. Pausing also mutes that scope's pool-exhaustion alert (and resuming unmutes it). Tip: shorten the lease time before pausing so clients converge quickly.
Be honest with yourself about what this is: it's soft control, convenient for keeping a scope tidy — not a security boundary. A determined device can spoof a MAC/DUID. Real lockdown lives in the network: firewall/ACL rules on UDP 67/68 (v4) and 547/546 (v6), or port security. Use allowlisting for hygiene, not as your only defense.
When the scope looks right: Validate, then Apply & save.
Beyond a single subnet, Kea-Ora gives you two ways to structure address space:
A shared network tells Kea that several subnets sit on the same physical link — the same L2 segment, reached through the same relay interface. Normally Kea answers from the single subnet that matches where a request arrived. Group the subnets into a shared network and Kea treats them as interchangeable on that link: if it can't pin a request to one specific subnet, or the matching subnet's pool is exhausted, it can lease from any member subnet in the group.
That's the whole point of the feature. It's how you: - add capacity to a segment that outgrew its original subnet (bolt a second subnet onto the same link instead of renumbering), - run secondary addressing on a segment, or - sit several subnets behind one relay interface without clients caring which one they land in.
A super scope is a named grouping with no CIDR of its own — it's just the label that ties member subnets together. Member scopes point at it. You can also give the group its own shared-network DNS and lease time that apply across every member, so common options are set once for the whole link rather than repeated per subnet.
Create one from the Add menu in the Assignments view (Super scope), or edit a scope and name the super scope it belongs to. Then Validate and Apply like anything else.
Here's where the tool does the thinking for you. Scopes that share a VLAN are grouped into a shared network automatically, and the group is named by router + VLAN — e.g. sntq-core-r1-42.
That naming convention isn't cosmetic, and it's the detail that prevents a real-world mistake: the same VLAN ID on two different routers is two different L2 segments — so Kea-Ora deliberately makes them two separate shared networks instead of wrongly merging them into one. Grouping subnets that only look related (same VLAN number, different physical segment) is a classic way to hand a client an address that doesn't belong on its link. Here, the safe outcome is the default.
You stay in control of the grouping: - Keep separate — when scopes happen to share a VLAN but you don't want them treated as one link, split them back out. - Group / regroup — put a VLAN back together as a shared network. - Fix / conform nudge — if a group's name drifts from the router-VLAN convention, the tool offers to rename it (or split it by router) in one click.
As always, nothing is live until you Apply to Kea — you can group, split, and rename freely first, then push once you're happy.
Locations are the backbone of the metadata that keeps your scopes legible. From the menu, Add location lets you name a site and attach the routers that live there. Once a location and its routers exist, they show up as dropdowns in the scope editor, so tagging a scope is a pick, not a re-type.
Create your locations from the Location panel first, then they're ready to pick in the scope editor's Location dropdown — tagging a scope stays a quick selection rather than a detour into another form mid-scope.
Renaming a location or router that's already in use (admins only). Open a location's edit dialog from the Location panel (the pencil). If you're an admin, the location name and any in-use router names become editable — rename them right there. The new name is pushed everywhere at once: live scopes, both Assignment views, the location list, and the shared-network names derived from router + VLAN. Names that are already taken are blocked, so you can't accidentally merge two locations or two routers. Because a rename lives inside the Kea config (it's stored on each subnet, and shared-network names are built from the router name), if any live scopes are affected the tool sends you straight to the Apply dialog — push it with Full replace, which rewrites the config in one atomic, backed-up step. If the name only existed in the Assignments (not on a live scope), nothing needs applying.
One thing worth knowing: Kea runs IPv4 and IPv6 as separate servers with separate control sockets, so an Apply only ever pushes the family you're currently in. If a site has both IPv4 and IPv6 scopes, a rename touches both — and the tool handles it in two steps: it applies the family you're in, then shows a note in the Apply dialog with a one-click Switch to IPv6/IPv4 button so you can Full-replace the other side too. Until you do, the second family shows its normal needs-apply indicator, so nothing gets silently left behind. In the edit dialog, each in-use router is also tagged live (on a real Kea scope) or record (Assignments only), so you can see at a glance which renames will reach the running config.
Deleting a location. The × on a location removes it. Any live scopes still tagged to it are moved to Unassigned (recoverable — nothing is lost, and you Apply afterward to push that to Kea). But if the location still has subnets tied to its router(s) in the IPv4 or IPv6 Assignments, the delete is blocked: those records live outside the Kea config, and removing the location would strand them. Clear or reassign them in the Assignments first, then the location will delete cleanly.
The Assignments view (IPv4 and IPv6 each have their own) is your gap-free record of every address handed out, renewed, and released. It's built on Kea's own forensic logging hook, so nothing is polled or sampled — Kea writes each event the instant it happens. This is the part that's suitable for audits and data-retention obligations.
The Dashboard / stats view is your at-a-glance health check: active leases and pool utilization so you can see which scopes are filling up before they run dry. If you've turned on email alerts (§12), this is the visual companion to the "pool getting full" warnings that land in your inbox.
These live in the menu and open as draggable windows you can park beside your work. The two planners aren't afterthoughts — they're step zero of the core loop (§4). Park one next to the scope editor and work left-to-right: plan, then build.
/60s fit in a /50, etc.) before you build the scope, so the delegated ranges you apply are ones you actually reasoned through — not a napkin guess you'll be renumbering later.ipv6 nd managed-config-flag / other-config-flag that actually make clients use DHCPv6 (without the managed flag they SLAAC an address and never reach Kea), and the reminder that the interface's giaddr / link-address must fall inside a scope you've defined here — or Kea won't know which pool to answer from.Here's the reassuring part you don't have to think about: Kea-Ora backs up before it ever changes anything. Every time you apply, save, or reload, the helper first snapshots the current running config — automatically, every time. You never have to remember to do it; the safety net is already under you before the change lands.
/opt/kea-helper/backups/ on the server, named like kea-v4-20260707-143012.json. IPv4 and IPv6 are kept as separate families, so each side has its own history.So the whole safety story is: you're covered automatically before every change, every snapshot is a full config you can inspect, and even a restore can be walked back. Take a manual look at Backups before a big change if you like — but the automatic snapshot means a bad apply is never a dead end.
From the menu:
Worth understanding so you work with the grain:
127.0.0.1 only. Never change it to 0.0.0.0 or expose port 8765. Reach it over SSH (ssh -L 8765:127.0.0.1:8765 you@server). The helper can rewrite Kea's entire config — that power is exactly why it stays local.control-sockets block is missing, or Kea wasn't restarted after it was added, or the helper is looking in the wrong place. On Kea 3.0 the socket must live in Kea's own dir (/run/kea)._kea). Match it to whoever owns /run/kea.Sign in and set your password. Confirm Helper connected. Pick IPv4 or IPv6. Plan your space in the planner first — blocks, boundaries, pool sizes — then Add scope, transcribe those numbers, and tag it with location/router so future-you knows what it is. Validate, then Apply & save — now it's live and saved. Turn on Assignments logging for an audit trail, watch pool utilization on the Dashboard, take a Backup before big changes, and use Router relay setup to point your edge gear at Kea. That's Kea-Ora: plan the space, build the intent, apply it in one click, and get on with your day.
The interface and default lease apply server-wide. Each scope can override the lease time.
Lifetimes are in seconds and apply server-wide. IPv6 clients learn their gateway from Router Advertisements, so there's no gateway field.
For Gmail, use an app password (Google Account → Security → 2-Step Verification → App passwords), not your normal password.
How Kea-Ora reaches each Kea daemon. Local uses the on-box UNIX socket (most secure, no network exposure). Remote talks to a Kea 3.x HTTP/HTTPS control socket across the network. Saved changes take effect immediately — no restart.
One key serves both families; it can only run a single read-only interface listing on the Kea server (enforced by the pasted command= restriction). The private key never leaves this box.
Read a router's live ARP table over SSH. Pick a saved SSH connection (Settings → the terminal's saved connections), the platform, and the bridge interface number. Key-based connections just work; for a password connection you'll be asked for the password (used once, never stored). Admin, LAN/VPN only.