cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
441
Views
2
Helpful
4
Replies

Document or Code of Generic CLI NED

Vennila
Beginner
Beginner

Hi All,

We need to understand how the yang device model is getting converted into CLI. I believe, it is done via CLI NED. We want to understand the pattern used to convert yang into CLI.

Where can we find the documentation or code of generic CLI NED ?

Thanks in Advance!

1 Accepted Solution

Accepted Solutions

alam.bilal
Cisco Employee
Cisco Employee

Generic NED is different from a CLI NED.

A CLI NED is for a device/platform for which the CLI has a similar look  and feel to Cisco-IOS. For that we can use the CLI engine in NSO.

The way the engine translate the YANG to CLI is usually pretty straight forward. Just using the same containment hierarchy and keywords used to define/declared in the models. Browse the cisco-ios YANG model to get a feel.

Sometimes the device/vendor have special quirks. One such example would be - at which sub-modes the "no" should be issued. When a "no" is issued, do we also need to also provide all the params or some/none. So within the device's YANG, clues can be put in place to instruct the engine on how to render the CLI thus avoiding special per-CLI logic. These clues are put in using annotations. Some of these annotations are documented here:

xxx@nso-dev:~/$ man tailf_yang_cli_extensions

View solution in original post

4 Replies 4

alam.bilal
Cisco Employee
Cisco Employee

Generic NED is different from a CLI NED.

A CLI NED is for a device/platform for which the CLI has a similar look  and feel to Cisco-IOS. For that we can use the CLI engine in NSO.

The way the engine translate the YANG to CLI is usually pretty straight forward. Just using the same containment hierarchy and keywords used to define/declared in the models. Browse the cisco-ios YANG model to get a feel.

Sometimes the device/vendor have special quirks. One such example would be - at which sub-modes the "no" should be issued. When a "no" is issued, do we also need to also provide all the params or some/none. So within the device's YANG, clues can be put in place to instruct the engine on how to render the CLI thus avoiding special per-CLI logic. These clues are put in using annotations. Some of these annotations are documented here:

xxx@nso-dev:~/$ man tailf_yang_cli_extensions

Hi Again,

Am still bit confused how the engine works in case of nested hierarchy. i.e., how it identifies that a containment is completed. Is it referring to curly braces to identify that?

If you explain the concept using below example, that would be really great.

  container macsec {

    config false;

    description "Macsec operational data";

    container mka {

      description "MKA Data";

      container interfaces {

        description "MKA Data";

        list interface {

          key "name";

          description "MKA Data for the Interface";

          container session {

            description "MKA Session Data";

            uses MKA-SESSION;

          }

          leaf name {

            type xr:Interface-name;

            description "Interface Name";

          }

        }

      }

    }

  }

Also is it possible to see that mapping written inside the engine.

Thanks in Advance!

Best to open up the YANG for the corresponding CLI NED and inspect how the modelling is done for the command/submode of interest.

Modelling a given command/submode can get tricky and knowing the set of annotations to use may be non-trivial. Best left to the NED engineer.

Thanks for your response Bilal!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the NSO Developer community:

Recognize Your Peers