Commit 5f7916dd authored by Tomek Mrugalski's avatar Tomek Mrugalski 🛰
Browse files

[master] Merge branch 'trac5212' (config comments # -> //)

# Conflicts:
#	doc/examples/kea4/reservations.json
#	doc/examples/kea6/reservations.json
parents 1f89f014 5812c3bc
......@@ -66,12 +66,13 @@
// when they get their own client-id. Kea can disable RFC6842 support.
"echo-client-id": false,
// Some clients don't use stable client identifier, but rather generate them
// during each boot. This may cause a client that reboots frequently to get
// multiple leases, which may not be desirable. As such, sometimes admins
// prefer to tell their DHCPv4 server to ignore client-id value altogether
// and rely exclusively on MAC address. This is a parameter that is defined
// globally, but can be overridden on a subnet level.
// Some clients don't use stable client identifier, but rather
// generate them during each boot. This may cause a client that
// reboots frequently to get multiple leases, which may not be
// desirable. As such, sometimes admins prefer to tell their DHCPv4
// server to ignore client-id value altogether and rely exclusively
// on MAC address. This is a parameter that is defined globally, but
// can be overridden on a subnet level.
"match-client-id": true,
// The following list defines subnets. Each subnet consists of at
......@@ -93,9 +94,10 @@
"pools": [ { "pool": "192.0.4.1 - 192.0.4.254" } ],
"subnet": "192.0.4.0/24",
// Sometimes the relay may use an IPv4 address that does not match
// the subnet. This is discouraged, but there are valid cases when it
// makes sense. One case is when there is a shared subnet.
// Sometimes the relay may use an IPv4 address that does
// not match the subnet. This is discouraged, but there are
// valid cases when it makes sense. One case is when there
// is a shared subnet.
"relay": {
"ip-address": "192.168.1.1"
}
......@@ -103,8 +105,9 @@
]
},
// 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": [
{
......
......@@ -60,13 +60,14 @@
// "connect-timeout": 3
// },
// 4. CQL (Cassandra) backend. Leases will be stored in Cassandra database. Make
// sure it is up, running and properly initialized. See kea-admin documentation
// for details on how to initialize the database. The only strictly required
// parameters are type, keyspace and contact-points. At least one contact point
// must be specified, but more than one is required for redundancy. Make sure
// you specify the contact points without spaces. Kea must be compiled with
// --with-cql option to use this backend.
// 4. CQL (Cassandra) backend. Leases will be stored in Cassandra
// database. Make sure it is up, running and properly initialized. See
// kea-admin documentation for details on how to initialize the
// database. The only strictly required parameters are type, keyspace
// and contact-points. At least one contact point must be specified, but
// more than one is required for redundancy. Make sure you specify the
// contact points without spaces. Kea must be compiled with --with-cql
// option to use this backend.
// "lease-database": {
// "type": "cql",
// "keyspace": "keatest",
......@@ -95,8 +96,9 @@
]
},
// 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": [
{
......
......@@ -10,13 +10,14 @@
"interfaces": [ "ethX" ]
},
// 4. CQL (Cassandra) backend. Leases will be stored in Cassandra database. Make
// sure it is up, running and properly initialized. See kea-admin documentation
// for details on how to initialize the database. The only strictly required
// parameters are type, keyspace and contact-points. At least one contact point
// must be specified, but more than one is required for redundancy. Make sure
// you specify the contact points without spaces. Kea must be compiled with
// --with-cql option to use this backend.
// 4. CQL (Cassandra) backend. Leases will be stored in Cassandra
// database. Make sure it is up, running and properly initialized. See
// kea-admin documentation for details on how to initialize the
// database. The only strictly required parameters are type, keyspace
// and contact-points. At least one contact point must be specified, but
// more than one is required for redundancy. Make sure you specify the
// contact points without spaces. Kea must be compiled with --with-cql
// option to use this backend.
"lease-database": {
"type": "cql",
"keyspace": "keatest",
......@@ -45,8 +46,9 @@
]
},
// 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": [
{
......
......@@ -95,8 +95,9 @@
]
},
// 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": [
{
......
......@@ -19,14 +19,15 @@
"lfc-interval": 3600
},
// The following parameters control processing expired leases. Expired leases
// will be reclaimed periodically according to the "reclaim-timer-wait-time"
// parameter. Reclaimed leases will be held in the database for 1800s to
// facilitate lease affinity. After this period the leases will be removed.
// The frequency of removal is controlled by the "flush-reclaimed-timer-wait-time"
// parameter. The lease reclamation routine will process at most 500 leases
// or will last for at most 100ms, during a single run. If there are still
// some unreclaimed leases after 10 attempts, a warning message is issued.
// The following parameters control processing expired leases. Expired
// leases will be reclaimed periodically according to the
// "reclaim-timer-wait-time" parameter. Reclaimed leases will be held in
// the database for 1800s to facilitate lease affinity. After this
// period the leases will be removed. The frequency of removal is
// controlled by the "flush-reclaimed-timer-wait-time" parameter. The
// lease reclamation routine will process at most 500 leases or will
// last for at most 100ms, during a single run. If there are still some
// unreclaimed leases after 10 attempts, a warning message is issued.
"expired-leases-processing": {
"reclaim-timer-wait-time": 5,
"hold-reclaimed-time": 1800,
......@@ -50,8 +51,9 @@
]
},
// 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": [
{
......
......@@ -60,8 +60,10 @@
},
// Note the Kea provides some of the options on its own. In
// particular:
// - IP address lease time (option 51) is governed by valid-lifetime
// parameter, so you don't need to specify it as option.
// - IP address lease time (option 51) is governed by
// valid-lifetime parameter, so you don't need to specify
// it as option.
// - Subnet mask (option 1) is calculated automatically from the
// subnet parameter specified for each "subnet4" entry.
// - renewal-timer (option 58) is calculated from renew-timer
......@@ -75,10 +77,12 @@
"name": "routers",
"data": "192.0.2.1"
},
// Typically people prefer to refer to options by their names, so they
// don't need to remember the code names. However, some people like
// to use numerical values. For example, option "domain-name" uses
// option code 15, so you can reference to it either by
// Typically people prefer to refer to options by their
// names, so they don't need to remember the code names.
// However, some people like to use numerical values. For
// example, option "domain-name" uses option code 15, so you
// can reference to it either by
// "name": "domain-name" or "code": 15.
{
"code": 15,
......@@ -87,7 +91,9 @@
// Domain search is also a popular option. It tells the client to
// attempt to resolve names within those specificed domains. For
// example, name "foo" would be attempted to be resolved as
// foo.mydomain.example.com and if it fails, then as foo.example.com
// foo.mydomain.example.com and if it fails, then as
// foo.example.com
{
"name": "domain-search",
"data": "mydomain.example.com, example.com"
......@@ -123,8 +129,9 @@
]
},
// 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": [
{
......
......@@ -31,18 +31,20 @@
// "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.
"host-reservation-identifiers": [ "circuit-id", "hw-address", "duid", "client-id" ],
"host-reservation-identifiers":
[ "circuit-id", "hw-address", "duid", "client-id" ],
// Specify connection to the database holding host reservations. The type
// specifies that the MySQL database is used. user and password are the
......@@ -77,8 +79,9 @@
]
},
// 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": [
{
......
......@@ -30,18 +30,20 @@
// "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.
"host-reservation-identifiers": [ "circuit-id", "hw-address", "duid", "client-id" ],
"host-reservation-identifiers":
[ "circuit-id", "hw-address", "duid", "client-id" ],
// Specify connection to the database holding host reservations. The type
// specifies that the PostgreSQL database is used. user and password are the
......@@ -75,8 +77,9 @@
]
},
// 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": [
{
......
......@@ -9,10 +9,10 @@
"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
......@@ -28,15 +28,15 @@
// "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), circuit-id
// (circuit identifier inserted by the relay agent) and flex-id (flexible identifier
// available when flex_id hook library is loaded). 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.
// (circuit identifier inserted by the relay agent) and flex-id (flexible
// identifier available when flex_id hook library is loaded). 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
......@@ -122,13 +122,15 @@
"boot-file-name": "/dev/null"
},
// This reservation is using flexible identifier. Instead of relying on specific
// field, sysadmin can define an expression similar to what is used for client
// classification, e.g. substring(relay[0].option[17],0,6). Then, based on the
// value of that expression for incoming packet, the reservation is matched.
// This reservation is using flexible identifier. Instead of relying
// on specific field, sysadmin can define an expression similar to what
// is used for client classification,
// e.g. substring(relay[0].option[17],0,6). Then, based on the value of
// that expression for incoming packet, the reservation is matched.
// Expression can be specified either as hex or plain text using single
// quotes.
// Note: flexible identifier requires flex_id hook library to be loaded to work.
// Note: flexible identifier requires flex_id hook library to be
// loaded to work.
{
"flex-id": "s0mEVaLue",
"ip-address": "192.0.2.206"
......@@ -139,8 +141,9 @@
]
},
// 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": [
{
......
......@@ -59,8 +59,9 @@
} ]
},
// 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": [
{
......
......@@ -40,8 +40,9 @@
]
},
// 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": [
{
......
......@@ -58,8 +58,9 @@
}
},
// 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": [
{
......
......@@ -108,8 +108,9 @@
]
},
// 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": [
{
......
# This is an example configuration file for the DHCPv6 server in Kea.
# It is a basic scenario with one IPv6 subnet configured. It demonstrates
# how to configure Kea to use various backends to store leases:
# - memfile
# - MySQL
# - PostgreSQL
# - CQL (Cassandra) backend
// This is an example configuration file for the DHCPv6 server in Kea.
// It is a basic scenario with one IPv6 subnet configured. It demonstrates
// how to configure Kea to use various backends to store leases:
// - memfile
// - MySQL
// - PostgreSQL
// - CQL (Cassandra) backend
{ "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 lease type. Exactly one lease-database section
# should be present. Make sure you uncomment only one.
// We need to specify lease type. Exactly one lease-database section
// should be present. Make sure you uncomment only one.
# 1. memfile backend. Leases information will be stored in flat CSV file.
# This is the easiest backend to use as it does not require any extra
# dependencies or services running.
// 1. memfile backend. Leases information will be stored in flat CSV file.
// This is the easiest backend to use as it does not require any extra
// dependencies or services running.
"lease-database": {
"type": "memfile",
"persist": true,
"lfc-interval": 3600
},
# 2. MySQL backend. Leases will be stored in MySQL database. Make sure it
# is up, running and properly initialized. See kea-admin documentation
# for details on how to initialize the database. The only strictly required
# parameters are type and name. If other parameters are not specified,
# Kea will assume the database is available on localhost, that user and
# password is not necessary to connect and that timeout is 5 seconds.
# Kea must be compiled with --with-dhcp-mysql option to use this backend.
# "lease-database": {
# "type": "mysql",
# "name": "keatest",
# "host": "localhost",
# "port": 3306,
# "user": "keatest",
# "password": "secret1",
# "connect-timeout": 3
# },
// 2. MySQL backend. Leases will be stored in MySQL database. Make sure it
// is up, running and properly initialized. See kea-admin documentation
// for details on how to initialize the database. The only strictly required
// parameters are type and name. If other parameters are not specified,
// Kea will assume the database is available on localhost, that user and
// password is not necessary to connect and that timeout is 5 seconds.
// Kea must be compiled with --with-dhcp-mysql option to use this backend.
// "lease-database": {
// "type": "mysql",
// "name": "keatest",
// "host": "localhost",
// "port": 3306,
// "user": "keatest",
// "password": "secret1",
// "connect-timeout": 3
// },
# 3. PostgreSQL backend. Leases will be stored in PostgreSQL database. Make
# sure it is up, running and properly initialized. See kea-admin documentation
# for details on how to initialize the database. The only strictly required
# parameters are type and name. If other parameters are not specified,
# Kea will assume the database is available on localhost, that user and
# password is not necessary to connect and that timeout is 5 seconds.
# Kea must be compiled with --with-dhcp-pgsql option to use this backend.
# "lease-database": {
# "type": "pgsql",
# "name": "keatest",
# "host": "localhost",
# "port": 5432,
# "user": "keatest",
# "password": "secret1",
# "connect-timeout": 3
# },
// 3. PostgreSQL backend. Leases will be stored in PostgreSQL database. Make
// sure it is up, running and properly initialized. See kea-admin documentation
// for details on how to initialize the database. The only strictly required
// parameters are type and name. If other parameters are not specified,
// Kea will assume the database is available on localhost, that user and
// password is not necessary to connect and that timeout is 5 seconds.
// Kea must be compiled with --with-dhcp-pgsql option to use this backend.
// "lease-database": {
// "type": "pgsql",
// "name": "keatest",
// "host": "localhost",
// "port": 5432,
// "user": "keatest",
// "password": "secret1",
// "connect-timeout": 3
// },
# 4. CQL (Cassandra) backend. Leases will be stored in Cassandra database. Make