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:

  1. loading the toaster module onto a running netconfd-pro server
  2. loading the toaster module onto the current instance of yangcli-pro
  3. creating the /toaster container
  4. saving the new configuration with the /toaster container
  5. 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 4 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?