@if (subnet) {
Subnet {{ subnet.subnet }} @if (subnet.sharedNetwork) { in }

Multiple DHCP servers can share a subnet when they run in High Availability (HA) mode or when they are connected to a shared lease database. In this case, the servers typically have the same subnet configuration (i.e. the same pools, DHCP options, and other DHCP-specific parameters). However, there are valid cases when the subnet configurations differ on individual servers. For example, the interfaces used for subnet selection may have different names; servers may use distinct pools within the subnet for the address assignment; or the subnet configurations may even use different subnet identifiers for the same subnet.

The Kea Subnet ID column below lists the subnet identifiers used to identify each subnet on different servers.

If the configured pools differ on the servers, they are displayed individually for each server. Otherwise, they are combined in a single box.

Each server maintains its own lease utilization statistics. The first pie charts show the total address and/or prefix utilizations, and the other pie charts show the utilizations reported by the individual servers. The individual statistics are not displayed if there is only one server serving leases in this subnet.

The detailed address utilization statistics use the following naming conventions:

  • total - the number of addresses in a subnet.
  • assigned - the number of allocated leases, including declined leases.
  • used - the number of allocated leases, excluding declined leases.
  • declined - the number of declined leases.
  • uncertain - optional statistics, only presented when the number of declined leases is greater than the number assigned (see below).

There are rare cases when a Kea server can return inconsistent statistics, with the number of declined leases greater than the number of assigned leases. It may happen when some DHCP clients decline leases that are already released or expired; these leases are not counted as assigned, but the declined statistics are affected. Stork deals with such cases via the "uncertain leases" count, which holds the estimated number of leases for which it is unclear whether they are allocated, declined, or free. This statistic is only computed and presented when the number of declined leases is greater than the number assigned.

The DHCP parameters can be specified at different configuration levels, and the subnet configuration can inherit them from the global and/or shared-network level. The list below contains all parameters configured for all servers sharing the subnet, and at all configuration levels, with an effective value displayed next to the parameter name. Click the button to the left of the parameter name to view the values specified at the different levels for each server. The subnet-level value takes precedence over the shared network-level and global values.

When a subnet belongs to a shared network, it is not allowed to change the assignments of the subnet to servers in the subnet form. In this case, these assignments can only be controlled in the shared network form, for the entire shared network.

The location where the edited subnet information is saved depends on the loaded Kea hooks. If libdhcp_cb_cmds is loaded, Stork updates the Config Backend database. If libdhcp_subnet_cmds is loaded, Stork updates subnet data in the Kea JSON configuration file.

If both libdhcp_subnet_cmds and libdhcp_cb_cmds hooks are loaded, Stork updates the subnet configuration in the Config Backend database, and leaves the JSON configuration unchanged. It conforms to the Kea behavior that prioritizes configuration specified in the Config Backend over the configuration sourced from the JSON file.

Using libdhcp_subnet_cmds and libdhcp_cb_cmds hooks together is not recommended as described in [Kea ARM section about incompatible software](https://kea.readthedocs.io/en/stable/arm/config.html#incompatible-software) and [Kea ARM section about config conflicts](https://kea.readthedocs.io/en/stable/arm/config.html#config-conflicts). If a user decides to use such a configuration, it is important to understand some implications. If a subnet is specified in both the Config Backend and the JSON configuration file, deleting this subnet will merely remove it from the Config Backend. As a result, the subnet defined in the configuration file will appear in the Kea server after the server is restarted or its configuration reloaded. Such a subnet cannot be deleted from Kea using Stork. It must be deleted manually.

@if (subnet.localSubnets?.length > 0) { }
Server Kea Subnet ID {{ l.id }}
@for (localSubnet of subnet.localSubnets; track localSubnet; let i = $index) {
@if (i === 0 || !allDaemonsHaveEqualPools()) { Pools /  @if (!allDaemonsHaveEqualPools()) { } @else { All Servers } @if ( (!localSubnet.pools || localSubnet.pools.length === 0) && (!localSubnet.prefixDelegationPools || localSubnet.prefixDelegationPools.length === 0) ) {
No pools configured.
} @else { } }
} @if ( subnet.addrUtilization || subnet.pdUtilization || (subnet.stats && (subnetHasAddressPools() || subnetHasPrefixPools())) ) {
} @for (localSubnet of subnet.localSubnets; track localSubnet; let i = $index) {
@if (i === 0 || !allDaemonsHaveEqualUserContext()) { User Context /  @if (!allDaemonsHaveEqualUserContext()) { } @else { All Servers } @if (!localSubnet.userContext) {
No user context configured.
} @else { } }
} @if (subnet.localSubnets?.length > 0) {
@for (localSubnet of subnet.localSubnets; track localSubnet; let i = $index) {
@if (i === 0 || !allDaemonsHaveEqualDhcpOptions()) { DHCP Options /  @if (!allDaemonsHaveEqualDhcpOptions()) { } @else { All Servers } }
} }
}