diff --git a/doc/examples/kea4/reservations.json b/doc/examples/kea4/reservations.json index 4dc9feee65..e3cda897da 100644 --- a/doc/examples/kea4/reservations.json +++ b/doc/examples/kea4/reservations.json @@ -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": [ { diff --git a/doc/examples/kea6/reservations.json b/doc/examples/kea6/reservations.json index 15a7a1dd0f..73fbc4b2e2 100644 --- a/doc/examples/kea6/reservations.json +++ b/doc/examples/kea6/reservations.json @@ -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": [ {