Kea DHPC4 Configuration - Leases at Scale, Logs in Motion

Kea DHPC4 Configuration - Leases at Scale, Logs in Motion
Kea DHCP Log Snip

Here’s the current live configuration for the Kea DHCPv4 server running in the lab. This config is purpose-built for the 10.1.0.0/16 simulated residential user segment, which is being hammered by thousands of synthetic clients and eventually by more intelligent, state-aware agents.

We’re not just handing out IPs—we’re capturing every lease event, routing that data into syslog, and forwarding it downstream to build a forensic, real-time observability pipeline.

Let’s walk through it.

Interfaces and Lease Database

"interfaces-config": {
  "interfaces": [ "enp6s19" ]
},
"lease-database": {
  "type": "memfile",
  "persist": true,
  "name": "/var/lib/kea/kea-leases4.csv"
}
  • interfaces: Kea listens only on enp6s19, which maps directly to VyOS’s eth4—the 10.1.0.0/16 user segment.
  • lease-database: We're using a memory-backed lease DB with persistent CSV output. It’s fast enough for heavy churn and gives us a file-based source of truth that can be parsed directly or tailed live if needed.

Subnet and Pool

"subnet4": [
  {
    "subnet": "10.1.0.0/16",
    "interface": "enp6s19",
    "valid-lifetime": 120,
    "pools": [
      { "pool": "10.1.0.100 - 10.1.255.254" }
    ],
    "option-data": [
      {
        "name": "routers",
        "data": "10.1.0.1"
      },
      {
        "name": "domain-name-servers",
        "data": "10.0.1.10"
      }
    ]
  }
]
  • subnet: Defines the full /16 block used for simulated residential clients.
  • valid-lifetime: Leases last 120 seconds—short enough to simulate churn, renewal drift, and bucket collisions. Perfect for log analytics.
  • pools: The range starts at .100 to leave room for static assignments or test harnesses, and ends at .255.254, utilizing nearly the full subnet.
  • option-data:
    • Router is set to 10.1.0.1, which is the VyOS gateway.
    • DNS points to 10.0.1.10, presumably a service VM running BIND or Unbound inside the management network.

Logging Configuration

"loggers": [
  {
    "name": "kea-dhcp4",
    "output_options": [
      { "output": "syslog" },
      { "output": "/var/log/kea/kea-dhcp4.log" }
    ],
    "severity": "INFO",
    "debuglevel": 0
  }
]

This block sends logs in two directions:

  • To local log files (/var/log/kea/kea-dhcp4.log) for immediate inspection.
  • And more importantly, to syslog, which in this environment is configured to forward logs to the central logging server at 10.0.1.100.

That server, in turn, forwards a copy to the GoatSearch dev box, where the log processor is actively being developed. This is the root of the observability pipeline. Every lease, renewal, expiration, and reject will eventually feed into FerroSearch, parsed by Gorok, and bucketed for time-aligned forensic visibility.


Full Config

{
  "Dhcp4": {
    "interfaces-config": {
 "interfaces": [ "enp6s19" ]
    },
    "lease-database": {
      "type": "memfile",
      "persist": true,
      "name": "/var/lib/kea/kea-leases4.csv"
    },
    "subnet4": [
      {
        "subnet": "10.1.0.0/16",
        "interface": "enp6s19",
        "valid-lifetime": 120,
        "pools": [
{ "pool": "10.1.0.100 - 10.1.255.254" }
        ],
        "option-data": [
          {
            "name": "routers",
            "data": "10.1.0.1"
          },
          {
            "name": "domain-name-servers",
            "data": "10.0.1.10"
          }
        ]
      }
    ],
    "loggers": [
      {
        "name": "kea-dhcp4",
        "output_options": [
      { "output": "syslog" },
      { "output": "/var/log/kea/kea-dhcp4.log" }
        ],
        "severity": "INFO",
        "debuglevel": 0
      }
    ]
  }
}

Summary

This DHCP configuration is more than a service—it’s a data source, a simulator, and a test engine. It hands out addresses, yes—but more critically, it:

  • Exercises log pipelines
  • Enables performance testing for GoatWatch
  • Seeds real-world churn scenarios for metric extraction and session mapping
  • Validates that users can get online and be observed before services are layered on top

It’s lean, intentional, and tuned for insight, not just functionality.

-Lots of Config
--Bryan