Skip to content

GitLab

Commit 5812c3bc authored by Francis Dupont's avatar Francis Dupont
Browse files

[5212] Wrapped lines made too long

parent b2ba456f
Hide whitespace changes
Inline Side-by-side
Showing with 178 additions and 134 deletions
doc/examples/kea4/advanced.json
View file @ 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": [
{
......
doc/examples/kea4/backends.json
View file @ 5812c3bc
......@@ -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": [
{
......
doc/examples/kea4/cassandra.json
View file @ 5812c3bc
......@@ -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": [
{
......
doc/examples/kea4/classify.json
View file @ 5812c3bc
......@@ -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": [
{
......
doc/examples/kea4/leases-expiration.json
View file @ 5812c3bc
......@@ -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": [
{
......
doc/examples/kea4/multiple-options.json
View file @ 5812c3bc
......@@ -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": [
{
......
doc/examples/kea4/mysql-reservations.json
View file @ 5812c3bc
......@@ -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": [
{
......
doc/examples/kea4/pgsql-reservations.json
View file @ 5812c3bc
......@@ -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": [
{
......
doc/examples/kea4/reservations.json
View file @ 5812c3bc
......@@ -29,18 +29,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" ],
// 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
......@@ -120,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"
......@@ -137,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": [
{
......
doc/examples/kea4/several-subnets.json
View file @ 5812c3bc
......@@ -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": [
{
......
doc/examples/kea4/single-subnet.json
View file @ 5812c3bc
......@@ -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": [
{
......
doc/examples/kea4/with-ddns.json
View file @ 5812c3bc
......@@ -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": [
{
......
doc/examples/kea6/advanced.json
View file @ 5812c3bc
......@@ -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": [
{
......
doc/examples/kea6/backends.json
View file @ 5812c3bc
......@@ -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",
......@@ -96,8 +97,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": [
{
......
doc/examples/kea6/cassandra.json
View file @ 5812c3bc
......@@ -46,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": [
{
......
doc/examples/kea6/classify.json
View file @ 5812c3bc
......@@ -77,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": [
{
......
doc/examples/kea6/leases-expiration.json
View file @ 5812c3bc
......@@ -23,10 +23,11 @@
// 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 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,
......@@ -58,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": [
{
......
doc/examples/kea6/multiple-options.json
View file @ 5812c3bc
......@@ -66,12 +66,13 @@
"data": "2001:db8:2::45, 2001:db8:2::100"
},
// 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, DHCPv6 can optionally use
// server unicast communication, if extra option is present. Option
// "unicast" uses option code 12, so you can reference to it either
// by "name": "unicast" or "code": 12.
// 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, DHCPv6 can optionally use server
// unicast communication, if extra option is present. Option
// "unicast" uses option code 12, so you can reference to it
// either by "name": "unicast" or "code": 12.
{
"code": 12,
"data": "2001:db8:1:0:ff00::1"
......@@ -145,8 +146,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": [
{
......