2
0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-08-30 21:45:37 +00:00
Files
kea/doc/examples/netconf/simple-dhcp4.json
Thomas Markwalder 8a3683dc9b [#3831] Removed /tmp example conf and .pre
Changes to be committed:
    modified:   kea4/dhcpv4-over-dhcpv6.json
    modified:   netconf/simple-dhcp4.json
    modified:   netconf/simple-dhcp6.json
    modified:   ../../src/bin/keactrl/kea-ctrl-agent.conf.pre
    modified:   ../../src/bin/keactrl/kea-dhcp-ddns.conf.pre
    modified:   ../../src/bin/keactrl/kea-dhcp4.conf.pre
    modified:   ../../src/bin/keactrl/kea-dhcp6.conf.pre
    modified:   ../../src/bin/keactrl/kea-netconf.conf.pre
2025-05-19 08:44:57 -04:00

120 lines
5.4 KiB
JSON

// This is a simple example of a configuration for Netconf that handles
// DHCPv4 configuration. This example provides YANG interface for
// DHCPv4 server only.
{
"Netconf":
{
// Three flags control netconf (default values are true):
// - "boot-update" about the YANG configuration load when
// netconf boots.
// - "subscribe-changes" about the subscription to notifications
// when the running YANG module is changed.
// - "validate-changes" allows to validate changes or not.
"boot-update": true,
"subscribe-changes": true,
"validate-changes": true,
// This map specifies how each server is managed:
// the YANG model to use and the control channel.
"managed-servers":
{
// This is how Netconf can communicate with the DHCPv4 server.
"dhcp4":
{
// Eventually, the kea-netconf will be able to handle multiple
// models. However, for the time being the only choice for
// DHCPv4 server is kea-dhcp4-server model.
"model": "kea-dhcp4-server",
// The three control flags can be defined in this scope too
// and takes precedence over global and default values.
// boot-update determines whether the initial configuration
// should be retrieved from netconf during kea-netconf startup.
// You almost always want to set this to yes.
"boot-update": true,
// This flag control whether the kea-netconf daemon should
// subscribe to any changes. If set to true, kea-netconf will
// monitor sysrepo and will pick up any changes that may be
// introduced, either using netconf clients or sysrepocfg.
"subscribe-changes": true,
// This parameters specifies whether kea-netconf will attempt
// to verify if the upcoming NETCONF configuration is sane. The
// verification is done by calling config-test. Depending on
// Kea response, the new configuration is accepted or rejected.
"validate-changes": false,
// Currently three control channel types are supported:
// - "stdout" which output the configuration on the standard
// output (this is mainly for testing purposes, but you can
// use simple script (such as curl or socat) to pass that
// information to the server.
// - "unix" which uses the local control channel supported by
// "dhcp4" and "dhcp6" servers ("d2" support is coming in Kea 1.5)
// - "http" which uses the Control Agent (CA) to manage itself or
// to forward commands to "dhcp4" or "dhcp6".
"control-socket":
{
"socket-type": "unix",
"socket-name": "kea4-ctrl-socket"
},
// Comment is optional. You can put some notes here.
"comment": "Kea DHCPv4 server serving network on floor 13"
}
},
// Netconf is able to load hook libraries that augment its operation.
// The primary functionality is the ability to add new commands.
// Uncomment this section to load a hook library.
// "hooks-libraries": [
// // Hook libraries list may contain more than one library.
// {
// // The only necessary parameter is the library filename.
// "library": "/opt/local/netconf-commands.so",
// // Some libraries may support parameters. Make sure you
// // type this section carefully, as the CA does not validate
// // it (because the format is library-specific).
// "parameters": {
// "param1": "foo"
// }
// }
// ]
// Similar to other Kea components, Netconf also uses logging.
"loggers": [
{
"name": "kea-netconf",
"output-options": [
{
// "output": "/var/log/kea/kea-netconf.log",
"output": "stdout",
// Several additional parameters are possible in addition
// to the typical output. Flush determines whether logger
// flushes output to a file. Maxsize determines maximum
// filesize before the file is rotated. maxver
// specifies the maximum number of rotated files being
// kept.
"flush": true,
"maxsize": 204800,
"maxver": 4,
// We use pattern to specify custom log message layout
"pattern": "%d{%y.%m.%d %H:%M:%S.%q} %-5p [%c/%i] %m\n"
}
],
// You can change the severity to DEBUG, INFO, WARN, ERROR or
// CRIT. For DEBUG level, you can also additionally specify
// debuglevel (0-99, higher = more verbose). All configurations
// are logged on DEBUG/55.
"severity": "INFO",
"debuglevel": 0
}
]
}
}