If you load a module into the server dynamically with the <load> or <load-bundle> operations, this configuration is not saved in the netconfd-pro.conf file. If you create configuration data for this module in the server, and then restart the server, the data will not be recognized.
If you restart the server and the configuration has nodes from YANG modules that are not loaded into the server,
the data will not be known to the server. An "unknown-namespace" error will be generated and the server will exit.
Example:
Here we see a yangcli-pro user:
- loading the toaster module onto a running netconfd-pro server
- loading the toaster module onto the current instance of yangcli-pro
- creating the /toaster container
- saving the new configuration with the /toaster container
- restarting the server
yangcli-pro@localhost> load toaster yangcli-pro@localhost> mgrload toaster yangcli-pro@localhost> create /toaster yangcli-pro@localhost> commit yangcli-pro@localhost> restart
After these steps, this is what the user finds when netconfd-pro attempts to reboot:
RPC Error 229: rpc-error: (229) unknown-namespace L:protocol S:error app-tag:data-invalid lang:en msg:unknown namespace error-info: bad-element T:string = --:toaster error-info: bad-namespace T:string = http://netconfcentral.org/ns/toaster error-info: error-number T:uint32 = 229
To fix this problem, make sure the server CLI parameters (or /etc/yumapro/netconfd-pro.conf file)
loads the YANG modules that are reported as unknown, in this case the toaster module.
CLI example of loading the toaster module at boot time using the module parameter:
> netconfd-pro --module=toaster
Configuration file example that loads the toaster module every time the server boots using this config file:
#### leaf-list module # # Specify a module that the server should load at boot-time # e.g., module test2 # module test3 # # no default for module module toaster
If specifying your module using the --module parameter does not solve the problem then it may be that your
modpath configuration parameter or YUMAPRO_MODPATH environment variable is causing netconfd-pro to
look for your module in the wrong place.
Note that the default for YUMAPRO_MODPATH is /usr/share/yumapro/modules. Also please note that if you set
the modpath in your netconfd-pro.conf or use the modpath parameter via command line at startup this will override
your YUMAPRO_MODPATH environment variable. Please ensure that your module is located in the scope defined by
your modpath parameter or YUMAPRO_MODPATH environment variable, whichever applies to your case.
For more information on configuring where your modules are discovered by YumaPro tools please review:
How do I control where YANG modules are found by netconfd-pro server and yangcli-pro client?