clixon/example

Clixon yang routing example

Compile and run

    cd example
    make && sudo make install

Start backend:

    clixon_backend -f /usr/local/etc/routing.conf -I

Edit cli:

    clixon_cli -f /usr/local/etc/routing.conf

Send netconf command:

    clixon_netconf -f /usr/local/etc/routing.conf

Setting data example using netconf

<rpc><edit-config><target><candidate/></target><config>
      <interfaces>
         <interface>
            <name>eth1</name>
            <enabled>true</enabled>
            <ipv4>
               <address>
                  <ip>9.2.3.4</ip>
                  <prefix-length>24</prefix-length>
               </address>
            </ipv4>
         </interface>
      </interfaces>
</config></edit-config></rpc>]]>]]>

Getting data using netconf

<rpc><get-config><source><candidate/></source></get-config></rpc>]]>]]>
<rpc><get-config><source><candidate/></source><filter/></get-config></rpc>]]>]]>
<rpc><get-config><source><candidate/></source><filter type="xpath"/></get-config></rpc>]]>]]>
<rpc><get-config><source><candidate/></source><filter type="subtree"><configuration><interfaces><interface><ipv4/></interface></interfaces></configuration></filter></get-config></rpc>]]>]]>
<rpc><get-config><source><candidate/></source><filter type="xpath" select="/interfaces/interface/ipv4"/></get-config></rpc>]]>]]>
<rpc><validate><source><candidate/></source></validate></rpc>]]>]]>

Creating notification

The example has an example notification triggering every 10s. To start a notification stream in the session, create a subscription:

<rpc><create-subscription><stream>ROUTING</stream></create-subscription></rpc>]]>]]>
<rpc-reply><ok/></rpc-reply>]]>]]>
<notification><event>Routing notification</event></notification>]]>]]>
<notification><event>Routing notification</event></notification>]]>]]>
...

This can also be triggered via the CLI:

cli> notify 
cli> Routing notification
Routing notification
...

Operation data

Clixon implements Yang RPC operations by an extension mechanism. The extension mechanism enables you to add application-specific operations. It works by adding user-defined callbacks for added netconf operations. It is possible to use the extension mechanism independent of the yang rpc construct, but it is recommended to use that, and the example includes such an example:

Example:

cli> rpc ipv4
<rpc-reply>
   <ok/>
</rpc-reply>

The example works by creating a netconf rpc call and sending it to the backend: (see the fib_route_rpc() function).

  <rpc>
    <fib-route>
      <routing-instance-name>ipv4</routing-instance-name>
    </fib-route>
   </rpc>

The backend in turn registers a callback (fib_route()) which handles the RPC.

static int 
fib_route(clicon_handle h, 
	  cxobj        *xe,           /* Request: <rpc><xn></rpc> */
	  struct client_entry *ce,    /* Client session */
	  cbuf         *cbret,        /* Reply eg <rpc-reply>... */
	  void         *arg)          /* Argument given at register */
{
    cprintf(cbret, "<rpc-reply><ok/></rpc-reply>");    
    return 0;
}
int
plugin_init(clicon_handle h)
{
...
   backend_rpc_cb_register(h, fib_route, NULL, "fib-route");
...
}

State data

Netconf and restconf GET also returns state data, in contrast to config data.

In YANG state data is specified with "config false;". In the example, interface-state is state data.

To return state data, you need to write a backend state data callback with the name "plugin_statedata" where you return an XML tree with state. This is then merged with config data by the system.

pA static example of returning state data is in the example. Note that a real example would poll or get the interface counters via a system call, as well as use the "xpath" argument to identify the requested state data.

Run as docker container

cd docker
# look in README