mirror of
https://gitlab.isc.org/isc-projects/kea
synced 2025-08-31 05:55:28 +00:00
[5132] Comments converted in reservations examples
This commit is contained in:
Tomek
@@ -1,59 +1,59 @@
|
||||
# This is an example configuration file for the DHCPv4 server in Kea.
|
||||
# It contains one subnet in which there are two static address reservations
|
||||
# for the clients identified by the MAC addresses.
|
||||
// This is an example configuration file for the DHCPv4 server in Kea.
|
||||
// It contains one subnet in which there are two static address reservations
|
||||
// for the clients identified by the MAC addresses.
|
||||
{ "Dhcp4":
|
||||
|
||||
{
|
||||
# Kea is told to listen on ethX interface only.
|
||||
// Kea is told to listen on ethX interface only.
|
||||
"interfaces-config": {
|
||||
"interfaces": [ "ethX" ]
|
||||
},
|
||||
|
||||
# We need to specify the the database used to store leases. As of
|
||||
# September 2016, four database backends are supported: MySQL,
|
||||
# PostgreSQL, Cassandra, and the in-memory database, Memfile.
|
||||
# We'll use memfile because it doesn't require any prior set up.
|
||||
// We need to specify the the database used to store leases. As of
|
||||
// September 2016, four database backends are supported: MySQL,
|
||||
// PostgreSQL, Cassandra, and the in-memory database, Memfile.
|
||||
// We'll use memfile because it doesn't require any prior set up.
|
||||
"lease-database": {
|
||||
"type": "memfile",
|
||||
"lfc-interval": 3600
|
||||
},
|
||||
|
||||
# Addresses will be assigned with a lifetime of 4000 seconds.
|
||||
// Addresses will be assigned with a lifetime of 4000 seconds.
|
||||
"valid-lifetime": 4000,
|
||||
|
||||
# Renew and rebind timers are commented out. This implies that options
|
||||
# 58 and 59 will not be sent to the client. In this case it is up to
|
||||
# the client to pick the timer values according to RFC2131. Uncomment the
|
||||
# timers to send these options to the client.
|
||||
# "renew-timer": 1000,
|
||||
# "rebind-timer": 2000,
|
||||
// Renew and rebind timers are commented out. This implies that options
|
||||
// 58 and 59 will not be sent to the client. In this case it is up to
|
||||
// the client to pick the timer values according to RFC2131. Uncomment the
|
||||
// timers to send these options to the client.
|
||||
// "renew-timer": 1000,
|
||||
// "rebind-timer": 2000,
|
||||
|
||||
|
||||
# Kea supports reservations by several different types of identifiers:
|
||||
# hw-address (hardware/MAC address of the client), duid (DUID inserted by the
|
||||
# client), client-id (client identifier inserted by the client) and circuit-id
|
||||
# (circuit identifier inserted by the relay agent). When told to do so, Kea can
|
||||
# check for all of those identifier types, but it takes a costly database lookup
|
||||
# to do so. It is therefore useful from a performance perspective to use only
|
||||
# the reservation types that are actually used in a given network.
|
||||
// Kea supports reservations by several different types of identifiers:
|
||||
// hw-address (hardware/MAC address of the client), duid (DUID inserted by the
|
||||
// client), client-id (client identifier inserted by the client) and circuit-id
|
||||
// (circuit identifier inserted by the relay agent). When told to do so, Kea can
|
||||
// check for all of those identifier types, but it takes a costly database lookup
|
||||
// to do so. It is therefore useful from a performance perspective to use only
|
||||
// the reservation types that are actually used in a given network.
|
||||
|
||||
# The example below is not optimal from a performance perspective, but it
|
||||
# nicely showcases the host reservation capabilities. Please use the minimum
|
||||
# set of identifier types used in your network.
|
||||
// The example below is not optimal from a performance perspective, but it
|
||||
// nicely showcases the host reservation capabilities. Please use the minimum
|
||||
// set of identifier types used in your network.
|
||||
"host-reservation-identifiers": [ "circuit-id", "hw-address", "duid", "client-id" ],
|
||||
|
||||
# Define a subnet with four reservations. Some of the reservations belong
|
||||
# to the dynamic pool. Kea is able to handle this case, but it is not
|
||||
# recommended from a performance perspective, as Kea would not only need to
|
||||
# check if a given address is free, but also whether it is reserved.
|
||||
# To avoid this check, one can change reservation-mode to out-of-pool, rather
|
||||
# than 'all'. If a subnet does not have reservations at all, the reservation
|
||||
# lookup can be skipped altogether (reservation-mode is set to 'disabled').
|
||||
// Define a subnet with four reservations. Some of the reservations belong
|
||||
// to the dynamic pool. Kea is able to handle this case, but it is not
|
||||
// recommended from a performance perspective, as Kea would not only need to
|
||||
// check if a given address is free, but also whether it is reserved.
|
||||
// To avoid this check, one can change reservation-mode to out-of-pool, rather
|
||||
// than 'all'. If a subnet does not have reservations at all, the reservation
|
||||
// lookup can be skipped altogether (reservation-mode is set to 'disabled').
|
||||
|
||||
# Note that the second reservation is for an address which is within the
|
||||
# range of the pool of the dynamically allocated address. The server will
|
||||
# exclude this address from this pool and only assign it to the client which
|
||||
# has a reservation for it.
|
||||
// Note that the second reservation is for an address which is within the
|
||||
// range of the pool of the dynamically allocated address. The server will
|
||||
// exclude this address from this pool and only assign it to the client which
|
||||
// has a reservation for it.
|
||||
"subnet4": [
|
||||
{
|
||||
"pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
|
||||
@@ -62,26 +62,26 @@
|
||||
"reservation-mode": "out-of-pool",
|
||||
"reservations": [
|
||||
|
||||
# This is a reservation for a specific hardware/MAC address. It's a very
|
||||
# simple reservation: just an address and nothing else.
|
||||
// This is a reservation for a specific hardware/MAC address. It's a very
|
||||
// simple reservation: just an address and nothing else.
|
||||
{
|
||||
"hw-address": "1a:1b:1c:1d:1e:1f",
|
||||
"ip-address": "192.0.2.201"
|
||||
},
|
||||
|
||||
# This is a reservation for a specific client-id. It also shows
|
||||
# the this client will get a reserved hostname. A hostname can be defined
|
||||
# for any identifier type, not just client-id.
|
||||
// This is a reservation for a specific client-id. It also shows
|
||||
// the this client will get a reserved hostname. A hostname can be defined
|
||||
// for any identifier type, not just client-id.
|
||||
{
|
||||
"client-id": "01:11:22:33:44:55:66",
|
||||
"ip-address": "192.0.2.202",
|
||||
"hostname": "special-snowflake"
|
||||
},
|
||||
|
||||
# The third reservation is based on DUID. This reservation also
|
||||
# defines special option values for this particular client. If
|
||||
# the domain-name-servers option would have been defined on a global,
|
||||
# subnet or class level, the host specific values take preference.
|
||||
// The third reservation is based on DUID. This reservation also
|
||||
// defines special option values for this particular client. If
|
||||
// the domain-name-servers option would have been defined on a global,
|
||||
// subnet or class level, the host specific values take preference.
|
||||
{
|
||||
"duid": "01:02:03:04:05",
|
||||
"ip-address": "192.0.2.203",
|
||||
@@ -91,9 +91,9 @@
|
||||
} ]
|
||||
},
|
||||
|
||||
# The fourth reservation is based on circuit-id. This is an option inserted
|
||||
# by the relay agent that forwards the packet from client to the server.
|
||||
# In this example the host is also assigned vendor specific options.
|
||||
// The fourth reservation is based on circuit-id. This is an option inserted
|
||||
// by the relay agent that forwards the packet from client to the server.
|
||||
// In this example the host is also assigned vendor specific options.
|
||||
{
|
||||
"client-id": "01:11:22:33:44:55:66",
|
||||
"ip-address": "192.0.2.204",
|
||||
@@ -109,9 +109,9 @@
|
||||
}
|
||||
]
|
||||
},
|
||||
# This reservation is for a client that needs specific DHCPv4 fields to be
|
||||
# set. Three supported fields are next-server, server-hostname and
|
||||
# boot-file-name
|
||||
// This reservation is for a client that needs specific DHCPv4 fields to be
|
||||
// set. Three supported fields are next-server, server-hostname and
|
||||
// boot-file-name
|
||||
{
|
||||
"client-id": "01:0a:0b:0c:0d:0e:0f",
|
||||
"ip-address": "192.0.2.205",
|
||||
@@ -137,8 +137,8 @@
|
||||
]
|
||||
},
|
||||
|
||||
# The following configures logging. It assumes that messages with at least
|
||||
# informational level (info, warn, error and fatal) should be logged to stdout.
|
||||
// The following configures logging. It assumes that messages with at least
|
||||
// informational level (info, warn, error and fatal) should be logged to stdout.
|
||||
"Logging": {
|
||||
"loggers": [
|
||||
{
|
||||
|
||||
@@ -1,42 +1,42 @@
|
||||
# This is an example configuration file for DHCPv6 server in Kea
|
||||
# that showcases how to do host reservations. It is
|
||||
# assumed that one subnet (2001:db8:1::/64) is available directly
|
||||
# over ethX interface. A number of hosts have various combinations
|
||||
# of addresses and prefixes reserved for them.
|
||||
// This is an example configuration file for DHCPv6 server in Kea
|
||||
// that showcases how to do host reservations. It is
|
||||
// assumed that one subnet (2001:db8:1::/64) is available directly
|
||||
// over ethX interface. A number of hosts have various combinations
|
||||
// of addresses and prefixes reserved for them.
|
||||
|
||||
{ "Dhcp6":
|
||||
|
||||
{
|
||||
# Kea is told to listen on ethX interface only.
|
||||
// Kea is told to listen on ethX interface only.
|
||||
"interfaces-config": {
|
||||
"interfaces": [ "ethX" ]
|
||||
},
|
||||
|
||||
# We need to specify the the database used to store leases. As of
|
||||
# September 2016, four database backends are supported: MySQL,
|
||||
# PostgreSQL, Cassandra, and the in-memory database, Memfile.
|
||||
# We'll use memfile because it doesn't require any prior set up.
|
||||
// We need to specify the the database used to store leases. As of
|
||||
// September 2016, four database backends are supported: MySQL,
|
||||
// PostgreSQL, Cassandra, and the in-memory database, Memfile.
|
||||
// We'll use memfile because it doesn't require any prior set up.
|
||||
"lease-database": {
|
||||
"type": "memfile",
|
||||
"lfc-interval": 3600
|
||||
},
|
||||
|
||||
# This is pretty basic stuff, it has nothing to do with reservations.
|
||||
// This is pretty basic stuff, it has nothing to do with reservations.
|
||||
"preferred-lifetime": 3000,
|
||||
"valid-lifetime": 4000,
|
||||
"renew-timer": 1000,
|
||||
"rebind-timer": 2000,
|
||||
|
||||
# Kea supports two types of identifiers in DHCPv6: hw-address (hardware/MAC address
|
||||
# of the client) and duid (DUID inserted by the client). When told to do so, Kea can
|
||||
# check for each of these identifier types, but it takes a costly database lookup
|
||||
# to do so. It is therefore useful from a performance perspective to use only
|
||||
# the reservation types that are actually used in a given network.
|
||||
// Kea supports two types of identifiers in DHCPv6: hw-address (hardware/MAC address
|
||||
// of the client) and duid (DUID inserted by the client). When told to do so, Kea can
|
||||
// check for each of these identifier types, but it takes a costly database lookup
|
||||
// to do so. It is therefore useful from a performance perspective to use only
|
||||
// the reservation types that are actually used in a given network.
|
||||
"host-reservation-identifiers": [ "duid", "hw-address" ],
|
||||
|
||||
# The following list defines subnets. Subnet, pools and interface definitions
|
||||
# are the same as in the regular scenario, without host reservations.
|
||||
# least subnet and pool entries.
|
||||
// The following list defines subnets. Subnet, pools and interface definitions
|
||||
// are the same as in the regular scenario, without host reservations.
|
||||
// least subnet and pool entries.
|
||||
"subnet6": [
|
||||
{
|
||||
"subnet": "2001:db8:1::/48",
|
||||
@@ -54,25 +54,25 @@
|
||||
|
||||
"reservation-mode": "out-of-pool",
|
||||
|
||||
# Host reservations. Define several reservations, note that
|
||||
# they are all within the range of the pool of the dynamically
|
||||
# allocated address. The server will exclude the addresses from this
|
||||
# pool and only assign them to the client which has a reservation for
|
||||
# them.
|
||||
// Host reservations. Define several reservations, note that
|
||||
// they are all within the range of the pool of the dynamically
|
||||
// allocated address. The server will exclude the addresses from this
|
||||
// pool and only assign them to the client which has a reservation for
|
||||
// them.
|
||||
"reservations": [
|
||||
# This is a simple host reservation. The host with DUID matching
|
||||
# the specified value will get an address of 2001:db8:1::100.
|
||||
// This is a simple host reservation. The host with DUID matching
|
||||
// the specified value will get an address of 2001:db8:1::100.
|
||||
{
|
||||
"duid": "01:02:03:04:05:0A:0B:0C:0D:0E",
|
||||
"ip-addresses": [ "2001:db8:1::100" ]
|
||||
},
|
||||
# This is similar to the previous one, but this time the reservation is done
|
||||
# based on hardware/MAC address. The server will do its best to extract
|
||||
# the hardware/MAC address from received packets (see 'mac-sources' directive
|
||||
# for details). This particular reservation also specifies two extra options
|
||||
# to be available for this client. If there are options with the same code
|
||||
# specified in a global, subnet or class scope, the values defined at host level
|
||||
# take precedence.
|
||||
// This is similar to the previous one, but this time the reservation is done
|
||||
// based on hardware/MAC address. The server will do its best to extract
|
||||
// the hardware/MAC address from received packets (see 'mac-sources' directive
|
||||
// for details). This particular reservation also specifies two extra options
|
||||
// to be available for this client. If there are options with the same code
|
||||
// specified in a global, subnet or class scope, the values defined at host level
|
||||
// take precedence.
|
||||
{
|
||||
"hw-address": "00:01:02:03:04:05",
|
||||
"ip-addresses": [ "2001:db8:1::101" ],
|
||||
@@ -87,12 +87,12 @@
|
||||
}],
|
||||
"client-classes": [ "special_snowflake", "office" ]
|
||||
},
|
||||
# This is a bit more advanced reservation. The client with the specified
|
||||
# DUID will get a reserved address, a reserved prefix and a hostname.
|
||||
# This reservation is for an address that it not within the dynamic pool.
|
||||
# Finally, this reservation features vendor specific options for CableLabs,
|
||||
# which happen to use enterprise-id 4491. Those particular values will
|
||||
# be returned only to the client that has a DUID matching this reservation.
|
||||
// This is a bit more advanced reservation. The client with the specified
|
||||
// DUID will get a reserved address, a reserved prefix and a hostname.
|
||||
// This reservation is for an address that it not within the dynamic pool.
|
||||
// Finally, this reservation features vendor specific options for CableLabs,
|
||||
// which happen to use enterprise-id 4491. Those particular values will
|
||||
// be returned only to the client that has a DUID matching this reservation.
|
||||
{
|
||||
"duid": "01:02:03:04:05:06:07:08:09:0A",
|
||||
"ip-addresses": [ "2001:db8:1:cafe::1" ],
|
||||
@@ -126,8 +126,8 @@
|
||||
]
|
||||
},
|
||||
|
||||
# The following configures logging. It assumes that messages with at least
|
||||
# informational level (info, warn, error and fatal) should be logged to stdout.
|
||||
// The following configures logging. It assumes that messages with at least
|
||||
// informational level (info, warn, error and fatal) should be logged to stdout.
|
||||
"Logging": {
|
||||
"loggers": [
|
||||
{
|
||||
|
||||
Reference in New Issue
Block a user