From: Marcin Siodelski Date: Wed, 28 Nov 2018 18:45:28 +0000 (+0100) Subject: [#195,!131] Applied changes to the NETCONF step by step. X-Git-Tag: 284-need-dhcp6-example-for-netconf_base~2 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=e847b7cc55a5741b484c73a3abcb6ba1d2b7090a;p=thirdparty%2Fkea.git [#195,!131] Applied changes to the NETCONF step by step. As a result of review. --- diff --git a/doc/guide/netconf.xml b/doc/guide/netconf.xml index dc65972739..e48dce6f7f 100644 --- a/doc/guide/netconf.xml +++ b/doc/guide/netconf.xml @@ -714,6 +714,10 @@ done in dependency order and reverse dependency order accordingly.
Step by Step Netconf Operation Example + Copies of example configurations presented within this section + can be found in the Kea source code, under doc/examples/kea6 + and doc/examples/netconf. +
Setup of Netconf Operation Example @@ -733,9 +737,13 @@ done in dependency order and reverse dependency order accordingly. - The Kea DHCPv6 server must be launched with a configuration - specifying a control socket so kea-netconf - can push configuration to it: + The Kea DHCPv6 server must be launched with the configuration + specifying a control socket used to receive control commands. + The kea-netconf process uses this socket + to communicate with the DHCPv6 server, i.e. it pushes + translated configurations to that server using control commands. + The following is the example control socket specification for the + Kea DHCPv6 server: { "Dhcp6": { @@ -746,66 +754,22 @@ done in dependency order and reverse dependency order accordingly. } } - Launched when the configuration is in the - boot.json file by: + In order to launch the Kea DHCPv6 server using configuration + contained within boot.json file, run: # kea-dhcp6 -d -c boot.json - The current configuration can be dumped by: + The current configuration of the server can be fetched via + control socket by running: # echo '{ "command": "config-get" }' | socat UNIX:/tmp/kea6-sock '-,ignoreeof' - A more complete startup configuration must be installed in the - sysrepo datastore. The configuration in - startup.xml is: - -<config xmlns="urn:ietf:params:xml:ns:yang:kea-dhcp6-server"> - <subnet6> - <id>1</id> - <pool> - <start-address>2001:db8::1:0</start-address> - <end-address>2001:db8::1:ffff</end-address> - <prefix>2001:db8::1:0/112</prefix> - </pool> - <subnet>2001:db8::/64</subnet> - </subnet6> - <interfaces-config> - <interfaces>eth1</interfaces> - </interfaces-config> - <control-socket> - <socket-name>/tmp/kea6-sock</socket-name> - <socket-type>unix</socket-type> - </control-socket> -</config> - - and can be installed by: - - # sysrepocfg -d startup -f xml -i startup.xml kea-dhcp6-server - - A copy of these configurations are in the netconf example directory. - - - - kea-netconf will push the configuration - found in the sysrepo startup datastore to all Kea servers during - its initialization phase. After it subscribes to module changes - in the sysrepo running datastore. This action copies the - configuration from the startup datastore to the running datastore - and enables the running datastore making it available. - - - - Changes to the running datastore are applied after validation - to Kea servers. Note they are not by default copied back to the - startup datastore, i.e. changes are not permanent. - - - - kea-netconf configuration to manage the - Kea DHCPv6 server in the netconf.json is: + The following is the example netconf.json + configuration for kea-netconf, to manage the Kea + DHCPv6 server: { "Netconf": @@ -841,28 +805,81 @@ done in dependency order and reverse dependency order accordingly. } } - Note in production you should not need to log at the DEBUG level. + Note that in production you should not need to log at the DEBUG level. + + The Kea Netconf agent is lanched by: # kea-netconf -d -c netconf.json + + + Now that both kea-netconf and + kea-dhcp6 are running, it is possible to populate + updated to configuration to the DHCPv6 server. The following is + the configuration extracted from the startup.xml: + +<config xmlns="urn:ietf:params:xml:ns:yang:kea-dhcp6-server"> + <subnet6> + <id>1</id> + <pool> + <start-address>2001:db8::1:0</start-address> + <end-address>2001:db8::1:ffff</end-address> + <prefix>2001:db8::1:0/112</prefix> + </pool> + <subnet>2001:db8::/64</subnet> + </subnet6> + <interfaces-config> + <interfaces>eth1</interfaces> + </interfaces-config> + <control-socket> + <socket-name>/tmp/kea6-sock</socket-name> + <socket-type>unix</socket-type> + </control-socket> +</config> + + In order to populate this new configuration: + + # sysrepocfg -d startup -f xml -i startup.xml kea-dhcp6-server + + + + + kea-netconf will push the configuration + found in the sysrepo startup datastore to all Kea servers during + its initialization phase, after it subscribes to module changes + in the sysrepo running datastore. This action copies the + configuration from the startup datastore to the running datastore + and enables the running datastore making it available. + + + + Changes to the running datastore are applied after validation + to the Kea servers. Note they are not by default copied back to the + startup datastore, i.e. changes are not permanent. + +
Error handling in Netconf Operation Example - There are 4 ways for a configuration to be bad: + There are four classes of isssues with the configurations applied via + netconf: + The configuration does not comply with the YANG schema. + - The configuration can not be translated from YANG to + The configuration cannot be translated from YANG to the Kea JSON. + The configuration is rejected by the Kea server. @@ -871,15 +888,15 @@ done in dependency order and reverse dependency order accordingly. The configuration was validated by the Kea server but - can not be applied. + cannot be applied. - In the first case the configuration in - the BAD-schema.xml file: + In the first case, the following BAD-schema.xml + configuration file: <config xmlns="urn:ietf:params:xml:ns:yang:kea-dhcp6-server"> <subnet4> @@ -907,8 +924,8 @@ done in dependency order and reverse dependency order accordingly. - In the second case the configuration is rejected by - kea-netconf, for instance for the + In the second case, the configuration is rejected by + kea-netconf. For example, the BAD-translator.xml file: <config xmlns="urn:ietf:params:xml:ns:yang:kea-dhcp6-server"> @@ -934,7 +951,7 @@ done in dependency order and reverse dependency order accordingly. - In the third case the configuration is presented to the + In the third case, the configuration is presented to the Kea DHCPv6 server and fails to validate as in the BAD-config.xml file: @@ -960,9 +977,9 @@ done in dependency order and reverse dependency order accordingly. - In the last case the problem is detected too late and - the change must be reverted, for instance using the startup - datastore as a backup, or with other words use the + In the last case, the misconfiguration is detected too late and + the change must be reverted in sysrepo, e.g. using the startup + datastore as a backup. For this reason, please use the sysrepocfg / option (or simlar feature of NETCONF clients) with care. @@ -1080,9 +1097,6 @@ done in dependency order and reverse dependency order accordingly. </logger> </config> - Note in Kea models the "loggers" list was moved in global - parameters and the "Logging" global object removed as it is - planned in a future release for Kea JSON configurations. @@ -1128,8 +1142,8 @@ done in dependency order and reverse dependency order accordingly. - To finish one of the previous examples can be replayed using - sysrepocfg in edit mode by: + Finally, any of the previous examples can be replayed using + sysrepocfg in edit mode as follows: # sysrepocfg -d running -f xml -e vi kea-dhcp6-server