[stork-users] Question about Stork subnet address counting and high-usage warning

[Oliver]

Hi Slawek,

Thanks for the detailed explanation. I checked my hosts database and I can
now confirm the following:

   1.

   The subnet 1XX.9.3.0/24 (id=4) currently has 57 host reservations in the
   hosts database.
   2.

   The dynamic pool contains 5 addresses (1XX.9.3.250–254).
   3.

   This matches exactly what Stork reports as total-addresses = 62.
   4.

   There are no hosts with a NULL dhcp4_subnet_id, and no additional
   reservations outside this subnet.

So it appears that Stork is correctly counting only:

   -

   the addresses in the dynamic pool, and
   -

   the explicit reservations that already exist in the hosts database for
   this subnet.

Since I only create reservations manually when they are needed, most
addresses in the /24 do not exist yet as Kea reservations. I now understand
why Stork does not include them in the statistics.

Just to confirm: is this the expected behavior in Stork — that the subnet
statistics include only pool addresses and existing reservations, and do
not consider the rest of the subnet unless those addresses are explicitly
configured?

Thanks again for your help,
Oliver



El lun, 8 dic 2025 a las 10:10, Slawek Figiel (<slawek at isc.org>) escribió:

> Hi Oliver!
>
> Stork differentiates between three types of host reservations:
>
> 1. Global reservations - the reservations defined in the top-level
> "reservations" node.
> 2. Subnet in-pool reservations - the reservations defined in the
> "subnetX" node that are included by any pool of this subnet
> 3. Subnet out-of-pool reservations - the reservations defined in the
> "subnetX" node that are not included by any pool of this subnet
>
> The subnet statistics count the addresses from all pools of this subnet
> and all reservations defined in this subnet. However, it doesn't count
> global reservations, even if the reserved address belongs to the subnet.
>
> I understand that you have a pool with 4 addresses and 251 reservations.
>
> Could you please tell me more about your setup? How did you specify the
> reservations in Kea?
>
> 1. Are they specified in the subnetX node or in the top-level node
> (global reservations)?
> 2. Did you specify them in the JSON file or in the hosts database?
> 3. Is there anything special with 58 reservations that are already
> counted in the "total-addresses" statistic?
> 4. Please use kea-shell to send the "statistic-get-all" command to Kea.
> Does the output show incorrect/unexpected values?
>
> Regards,
> Slawek Figiel
>
>
> On 12/7/25 8:40 PM, Oliver wrote:
> > Hi everyone,
> >
> > I’m running Kea DHCP4 together with Stork, and I’ve encountered
> > something I don’t fully understand regarding how Stork calculates the
> > total number of addresses in a subnet.
> >
> > I have a *1XX.9.3.0/24* subnet configured, with only a very small
> > dynamic pool:
> >
> > |pools: - pool: 1XX.9.3.250-1XX.9.3.254 |
> >
> > All other addresses in the /24 are used exclusively as *static host
> > reservations*.
> >
> > However, Stork reports the following:
> >
> >   *
> >
> >     *Total addresses:* 62
> >
> >   *
> >
> >     *Assigned:* 51
> >
> >   *
> >
> >     *Free:* 11
> >
> >   *
> >
> >     *Usage:* 82.3% (yellow warning shown)
> >
> > My question is:
> >
> >
> >       *Why does Stork calculate only 62 total usable addresses for this
> >       subnet, when the subnet is actually a full /24?*
> >
> > I understand that my dynamic pool only contains 5 addresses, but I
> > expected Stork to consider the rest of the /24 as part of the subnet,
> > since I use those addresses for reservations.
> >
> > Is this the expected behavior?
> > Does Stork count only “usable” addresses as those inside dynamic pools
> > plus explicitly configured reservations?
> > Is there a recommended way to have Stork recognize the entire /24 range
> > so it doesn’t trigger a high-usage warning?
> >
> > Operationally everything works fine — I can continue creating
> > reservations without any issue — but I’d like to confirm whether this
> > behavior is normal or whether I might be missing something in the
> > configuration.
> >
> > Thanks in advance,
> > Oliver
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/stork-users/attachments/20251209/e6308b29/attachment.htm>