mir/kea
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-09-02 15:05:16 +00:00
Code Issues Releases Wiki Activity

[master] Merge branch 'trac3684'

Browse Source
This commit is contained in:
Marcin Siodelski
2016-09-14 18:02:39 +02:00
parent 10536e380b 1fe02beb42
commit 71d21eac51
24 changed files with 555 additions and 167 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
doc/examples/kea4/backends.json
View File

@@ -68,11 +68,7 @@
# "contact_points": "192.0.2.1,192.0.2.2,192.0.2.3"
# },
# Addresses will be assigned with valid lifetimes being 4000. Client
# is told to start renewing after 1000 seconds. If the server does not respond
# after 2000 seconds since the lease was granted, client is supposed
# to start REBIND procedure (emergency renewal that allows switching
# to a different server).
# Addresses will be assigned with a lifetime of 4000 seconds.
"valid-lifetime": 4000,
# Renew and rebind timers are commented out. This implies that options
@@ -94,7 +90,7 @@
},
# The following configures logging. It assumes that messages with at least
# informational level (info, warn, error) will will be logged to stdout.
# informational level (info, warn, error and fatal) should be logged to stdout.
"Logging": {
"loggers": [
{

2
doc/examples/kea4/classify.json
View File

@@ -90,7 +90,7 @@
},
# The following configures logging. It assumes that messages with at least
# informational level (info, warn, error) will will be logged to stdout.
# informational level (info, warn, error and fatal) should be logged to stdout.
"Logging": {
"loggers": [
{

15
doc/examples/kea4/leases-expiration.json
View File

@@ -10,9 +10,10 @@
"interfaces": [ "ethX" ]
},
# We need to specify lease type. As of May 2014, three backends are supported:
# memfile, mysql and pgsql. We'll just 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"
},
@@ -34,11 +35,7 @@
"unwarned-reclaim-cycles": 10
},
# Addresses will be assigned with valid lifetimes being 4000. Client
# is told to start renewing after 1000 seconds. If the server does not respond
# after 2000 seconds since the lease was granted, client is supposed
# to start REBIND procedure (emergency renewal that allows switching
# to a different server).
# Addresses will be assigned with a lifetime of 4000 seconds.
"valid-lifetime": 4000,
# The following list defines subnets. We have only one subnet
@@ -53,7 +50,7 @@
},
# The following configures logging. It assumes that messages with at least
# informational level (info, warn, error) will will be logged to stdout.
# informational level (info, warn, error and fatal) should be logged to stdout.
"Logging": {
"loggers": [
{

15
doc/examples/kea4/multiple-options.json
View File

@@ -9,18 +9,15 @@
"interfaces": [ "ethX" ]
},
# We need to specify lease type. As of May 2014, three backends are supported:
# memfile, mysql and pgsql. We'll just 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"
},
# Addresses will be assigned with valid lifetimes being 4000. Client
# is told to start renewing after 1000 seconds. If the server does not respond
# after 2000 seconds since the lease was granted, client is supposed
# to start REBIND procedure (emergency renewal that allows switching
# to a different server).
# 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,7 +55,7 @@
},
# The following configures logging. It assumes that messages with at least
# informational level (info, warn, error) will will be logged to stdout.
# informational level (info, warn, error and fatal) should be logged to stdout.
"Logging": {
"loggers": [
{

94
doc/examples/kea4/mysql-reservations.json Normal file
View File

@@ -0,0 +1,94 @@
# This is an example configuration file for the DHCPv4 server in Kea.
# It contains configuration of the MySQL host database backend, used
# to retrieve reserved addresses, host names, DHCPv4 message fields
# and DHCP options from MySQL database.
{ "Dhcp4":
{
# 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.
"lease-database": {
"type": "memfile"
},
# 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,
# 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" ],
# Specify connection to the database holding host reservations. The type
# specifies that the MySQL database is used. user and password are the
# credentials used to connect to the database. host and name specify
# location of the host where the database instance is running, and the
# name of the database to use. The server processing a packet will first
# check if there are any reservations specified for this client in the
# reservations list, within the subnet (configuration file). If there are
# no reservations there, the server will try to retrieve reservations
# from this database.
"hosts-database": {
"type": "mysql",
"name": "kea",
"user": "kea",
"password": "kea",
"host": "localhost"
},
# Define a subnet with a single pool of dynamic addresses. Addresses from
# this pool will be assigned to clients which don't have reservations in the
# database. Subnet identifier is equal to 1. If this subnet is selected for
# the client, this subnet id will be used to search for the reservations
# within the database.
"subnet4": [
{
"pools": [ { "pool": "192.0.2.10 - 192.0.2.200" } ],
"subnet": "192.0.2.0/24",
"interface": "ethX",
"id": 1
}
]
},
# 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": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "stdout"
}
],
"severity": "INFO"
}
]
}
}

94
doc/examples/kea4/pgsql-reservations.json Normal file
View File

@@ -0,0 +1,94 @@
# This is an example configuration file for the DHCPv4 server in Kea.
# It contains configuration of the PostgreSQL host database backend, used
# to retrieve reserved addresses, host names, DHCPv4 message fields
# and DHCP options from PostgreSQL database.
{ "Dhcp4":
{
# 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.
"lease-database": {
"type": "memfile"
},
# 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,
# 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" ],
# Specify connection to the database holding host reservations. The type
# specifies that the PostgreSQL database is used. user and password are the
# credentials used to connect to the database. host and name specify
# location of the host where the database instance is running, and the
# name of the database to use. The server processing a packet will first
# check if there are any reservations specified for this client in the
# reservations list, within the subnet (configuration file). If there are
# no reservations there, the server will try to retrieve reservations
# from this database.
"hosts-database": {
"type": "postgresql",
"name": "kea",
"user": "kea",
"password": "kea",
"host": "localhost"
},
# Define a subnet with a single pool of dynamic addresses. Addresses from
# this pool will be assigned to clients which don't have reservations in the
# database. Subnet identifier is equal to 1. If this subnet is selected for
# the client, this subnet id will be used to search for the reservations
# within the database.
"subnet4": [
{
"pools": [ { "pool": "192.0.2.10 - 192.0.2.200" } ],
"subnet": "192.0.2.0/24",
"interface": "ethX",
"id": 1
}
]
},
# 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": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "stdout"
}
],
"severity": "INFO"
}
]
}
}

15
doc/examples/kea4/reservations.json
View File

@@ -9,18 +9,15 @@
"interfaces": [ "ethX" ]
},
# We need to specify lease type. As of May 2014, three backends are supported:
# memfile, mysql and pgsql. We'll just 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"
},
# Addresses will be assigned with valid lifetimes being 4000. Client
# is told to start renewing after 1000 seconds. If the server does not respond
# after 2000 seconds since the lease was granted, client is supposed
# to start REBIND procedure (emergency renewal that allows switching
# to a different server).
# Addresses will be assigned with a lifetime of 4000 seconds.
"valid-lifetime": 4000,
# Renew and rebind timers are commented out. This implies that options
@@ -116,7 +113,7 @@
},
# The following configures logging. It assumes that messages with at least
# informational level (info, warn, error) will will be logged to stdout.
# informational level (info, warn, error and fatal) should be logged to stdout.
"Logging": {
"loggers": [
{

22
doc/examples/kea4/several-subnets.json
View File

@@ -10,16 +10,17 @@
"interfaces": [ "ethX" ]
},
# We need to specify lease type. As of May 2014, three backends are supported:
# memfile, mysql and pgsql. We'll just 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"
},
# Addresses will be assigned with the valid lifetimes being 4000.
# Client is told to start renewing after 1000 seconds. If the server
# does not respond after 2000 seconds since the lease was granted, client
# Addresses will be assigned with a lifetime of 4000 seconds.
# The client is told to start renewing after 1000 seconds. If the server
# does not respond within 2000 seconds of the lease being granted, client
# is supposed to start REBIND procedure (emergency renewal that allows
# switching to a different server).
"valid-lifetime": 4000,
@@ -37,19 +38,18 @@
"subnet": "192.0.4.0/24" } ]
},
# The following configures logging. Kea will log all debug messages
# to /var/log/kea-debug.log file.
# 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": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "/var/log/kea-debug.log"
"output": "stdout"
}
],
"debuglevel": 99,
"severity": "DEBUG"
"severity": "INFO"
}
]
}

15
doc/examples/kea4/single-subnet.json
View File

@@ -10,18 +10,15 @@
"interfaces": [ "ethX" ]
},
# We need to specify lease type. As of May 2014, three backends are supported:
# memfile, mysql and pgsql. We'll just 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"
},
# Addresses will be assigned with valid lifetimes being 4000. Client
# is told to start renewing after 1000 seconds. If the server does not respond
# after 2000 seconds since the lease was granted, client is supposed
# to start REBIND procedure (emergency renewal that allows switching
# to a different server).
# Addresses will be assigned with a lifetime of 4000 seconds.
"valid-lifetime": 4000,
# Renew and rebind timers are commented out. This implies that options
@@ -43,7 +40,7 @@
},
# The following configures logging. It assumes that messages with at least
# informational level (info, warn, error) will will be logged to stdout.
# informational level (info, warn, error and fatal) should be logged to stdout.
"Logging": {
"loggers": [
{

17
doc/examples/kea6/advanced.json
View File

@@ -15,9 +15,10 @@
"interfaces": [ "ethX" ]
},
# We need to specify lease type. As of May 2014, three backends are supported:
# memfile, mysql and pgsql. We'll just 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"
},
@@ -71,19 +72,19 @@
]
},
# The following configures logging. Kea will log all debug messages
# to /var/log/kea-debug.log file.
# 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": [
{
"name": "kea-dhcp6",
"output_options": [
{
"output": "/var/log/kea-debug.log"
"output": "stdout"
}
],
"debuglevel": 99,
"severity": "DEBUG"
"debuglevel": 0,
"severity": "INFO"
}
]
}

6
doc/examples/kea6/backends.json
View File

@@ -90,15 +90,15 @@
]
},
# The following configures logging. Kea will log all debug messages
# to /var/log/kea-debug.log file.
# 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": [
{
"name": "kea-dhcp6",
"output_options": [
{
"output": "/var/log/kea-debug.log"
"output": "stdout"
}
],
"debuglevel": 0,

12
doc/examples/kea6/classify.json
View File

@@ -74,19 +74,19 @@
]
},
# The following configures logging. Kea will log all debug messages
# to /var/log/kea-debug.log file.
# 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": [
{
"name": "kea-dhcp6",
"output_options": [
{
"output": "/var/log/kea-debug.log"
"output": "stdout"
}
],
"debuglevel": 99,
"severity": "DEBUG"
],
"debuglevel": 0,
"severity": "INFO"
}
]
}

17
doc/examples/kea6/duid.json
View File

@@ -30,9 +30,10 @@
"interfaces": [ "ethX" ]
},
# We need to specify lease type. As of May 2014, three backends are supported:
# memfile, mysql and pgsql. We'll just 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"
},
@@ -50,7 +51,7 @@
# The following list defines subnets. Each subnet consists of at
# least subnet and pool entries.
"subnet6": [
"subnet6": [
{
"pools": [ { "pool": "2001:db8:1::/80" } ],
"subnet": "2001:db8:1::/64",
@@ -59,17 +60,17 @@
]
},
# The following configures logging. Kea will log all debug messages
# to /var/log/kea-debug.log file.
# The following configures logging. It assumes that messages with at least
# informational level (info, warn, error) will will be logged to stdout.
"Logging": {
"loggers": [
{
"name": "kea-dhcp6",
"output_options": [
{
"output": "/var/log/kea-debug.log"
"output": "stdout"
}
],
],
"debuglevel": 0,
"severity": "INFO"
}

17
doc/examples/kea6/leases-expiration.json
View File

@@ -10,9 +10,10 @@
"interfaces": [ "ethX" ]
},
# We need to specify lease type. As of May 2014, three backends are supported:
# memfile, mysql and pgsql. We'll just 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"
},
@@ -56,19 +57,19 @@
]
},
# The following configures logging. Kea will log all debug messages
# to /var/log/kea-debug.log file.
# 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": [
{
"name": "kea-dhcp6",
"output_options": [
{
"output": "/var/log/kea-debug.log"
"output": "stdout"
}
],
"debuglevel": 99,
"severity": "DEBUG"
"debuglevel": 0,
"severity": "INFO"
}
]
}

17
doc/examples/kea6/multiple-options.json
View File

@@ -9,9 +9,10 @@
"interfaces": [ "ethX" ]
},
# We need to specify lease type. As of May 2014, three backends are supported:
# memfile, mysql and pgsql. We'll just 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"
},
@@ -49,19 +50,19 @@
]
},
# The following configures logging. Kea will log all debug messages
# to /var/log/kea-debug.log file.
# 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": [
{
"name": "kea-dhcp6",
"output_options": [
{
"output": "/var/log/kea-debug.log"
"output": "stdout"
}
],
"debuglevel": 99,
"severity": "DEBUG"
"debuglevel": 0,
"severity": "INFO"
}
]
}

92
doc/examples/kea6/mysql-reservations.json Normal file
View File

@@ -0,0 +1,92 @@
# This is an example configuration file for the DHCPv6 server in Kea.
# It contains configuration of the MySQL host database backend, used
# to retrieve reserved addresses, host names, DHCPv4 message fields
# and DHCP options from MySQL database.
{ "Dhcp6":
{
# 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.
"lease-database": {
"type": "memfile"
},
# 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.
"host-reservation-identifiers": [ "duid", "hw-address" ],
# Specify connection to the database holding host reservations. The type
# specifies that the MySQL database is used. user and password are the
# credentials used to connect to the database. host and name specify
# location of the host where the database instance is running, and the
# name of the database to use. The server processing a packet will first
# check if there are any reservations specified for this client in the
# reservations list, within the subnet (configuration file). If there are
# no reservations there, the server will try to retrieve reservations
# from this database.
"hosts-database": {
"type": "mysql",
"name": "kea",
"user": "kea",
"password": "kea",
"host": "localhost"
},
# Define a subnet with a pool of dynamic addresses and a pool of dynamic
# prefixes. Addresses and prefixes from those pools will be assigned to
# clients which don't have reservations in the database. Subnet identifier
# is equal to 1. If this subnet is selected for the client, this subnet
# id will be used to search for the reservations within the database.
"subnet6": [
{
"subnet": "2001:db8:1::/48",
"pools": [ { "pool": "2001:db8:1::/80" } ],
"pd-pools": [
{
"prefix": "2001:db8:1:8000::",
"prefix-len": 56,
"delegated-len": 64
}
],
"interface": "ethX",
"id": 1
}
]
},
# 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": [
{
"name": "kea-dhcp6",
"output_options": [
{
"output": "stdout"
}
],
"debuglevel": 0,
"severity": "INFO"
}
]
}
}

92
doc/examples/kea6/pgsql-reservations.json Normal file
View File

@@ -0,0 +1,92 @@
# This is an example configuration file for the DHCPv6 server in Kea.
# It contains configuration of the PostgreSQL host database backend, used
# to retrieve reserved addresses, host names, DHCPv4 message fields
# and DHCP options from PostgreSQL database.
{ "Dhcp6":
{
# 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.
"lease-database": {
"type": "memfile"
},
# 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.
"host-reservation-identifiers": [ "duid", "hw-address" ],
# Specify connection to the database holding host reservations. The type
# specifies that the PostgreSQL database is used. user and password are the
# credentials used to connect to the database. host and name specify
# location of the host where the database instance is running, and the
# name of the database to use. The server processing a packet will first
# check if there are any reservations specified for this client in the
# reservations list, within the subnet (configuration file). If there are
# no reservations there, the server will try to retrieve reservations
# from this database.
"hosts-database": {
"type": "postgresql",
"name": "kea",
"user": "kea",
"password": "kea",
"host": "localhost"
},
# Define a subnet with a pool of dynamic addresses and a pool of dynamic
# prefixes. Addresses and prefixes from those pools will be assigned to
# clients which don't have reservations in the database. Subnet identifier
# is equal to 1. If this subnet is selected for the client, this subnet
# id will be used to search for the reservations within the database.
"subnet6": [
{
"subnet": "2001:db8:1::/48",
"pools": [ { "pool": "2001:db8:1::/80" } ],
"pd-pools": [
{
"prefix": "2001:db8:1:8000::",
"prefix-len": 56,
"delegated-len": 64
}
],
"interface": "ethX",
"id": 1
}
]
},
# 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": [
{
"name": "kea-dhcp6",
"output_options": [
{
"output": "stdout"
}
],
"debuglevel": 0,
"severity": "INFO"
}
]
}
}

17
doc/examples/kea6/reservations.json
View File

@@ -12,9 +12,10 @@
"interfaces": [ "ethX" ]
},
# We need to specify lease type. As of May 2014, three backends are supported:
# memfile, mysql and pgsql. We'll just 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"
},
@@ -109,19 +110,19 @@
]
},
# The following configures logging. Kea will log all debug messages
# to /var/log/kea-debug.log file.
# 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": [
{
"name": "kea-dhcp6",
"output_options": [
{
"output": "/var/log/kea-debug.log"
"output": "stdout"
}
],
"debuglevel": 99,
"severity": "DEBUG"
"debuglevel": 0,
"severity": "INFO"
}
]
}

18
doc/examples/kea6/several-subnets.json
View File

@@ -10,9 +10,10 @@
"interfaces": [ "ethX" ]
},
# We need to specify lease type. As of May 2014, three backends are supported:
# memfile, mysql and pgsql. We'll just 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"
},
@@ -30,19 +31,19 @@
# The following list defines subnets. Each subnet consists of at
# least subnet and pool entries.
"subnet6": [
"subnet6": [
{ "pools": [ { "pool": "2001:db8:1::/80" } ],
"subnet": "2001:db8:1::/64" },
{ "pools": [ { "pool": "2001:db8:2::/80" } ],
"subnet": "2001:db8:2::/64" },
"subnet": "2001:db8:2::/64" },
{ "pools": [ { "pool": "2001:db8:3::/80" } ],
"subnet": "2001:db8:3::/64" },
{ "pools": [ { "pool": "2001:db8:4::/80" } ],
"subnet": "2001:db8:4::/64" } ]
},
# The following configures logging. It assumes that warning messages
# will 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": [
{
@@ -52,7 +53,8 @@
"output": "stdout"
}
],
"severity": "WARN"
"debuglevel": 0,
"severity": "INFO"
}
]
}

23
doc/examples/kea6/simple.json
View File

@@ -5,15 +5,16 @@
{ "Dhcp6":
{
{
# Kea is told to listen on ethX interface only.
"interfaces-config": {
"interfaces": [ "ethX" ]
},
# We need to specify lease type. As of May 2014, three backends are supported:
# memfile, mysql and pgsql. We'll just 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"
},
@@ -31,7 +32,7 @@
# The following list defines subnets. Each subnet consists of at
# least subnet and pool entries.
"subnet6": [
"subnet6": [
{
"pools": [ { "pool": "2001:db8:1::/80" } ],
"subnet": "2001:db8:1::/64",
@@ -40,19 +41,19 @@
]
},
# The following configures logging. Kea will log all debug messages
# to /var/log/kea-debug.log file.
# 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": [
{
"name": "kea-dhcp6",
"output_options": [
{
"output": "/var/log/kea-debug.log"
"output": "stdout"
}
],
"debuglevel": 99,
"severity": "DEBUG"
],
"debuglevel": 0,
"severity": "INFO"
}
]
}