cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1786
Views
20
Helpful
13
Replies
Highlighted
Enthusiast

How can I reference existing interface types/interfaces/configured IP's in yang service model?

Hi,

I have a question regarding a basic YANG model I am creating.

It is a YANG model to collect input data in NSO WebUI for a SitetoSite VPN (IPSec) Service.

Please consider the following leafs/typedefs:

typedef interface_type {

        type enumeration {

            enum GigabitEthernet;

            enum Ethernet;

            enum FastEthernet;

        }

    }

typedef interface_number {

        type string {

            pattern "(\\d+)(/)(\\d+)";

        }

    }

[...]

leaf endpoint1 {

         type leafref {

                path "/ncs:devices/ncs:device/ncs:name";

            }

            mandatory true;

            description 'Endpoint number one for VPN Tunnel';

            tailf:info "Endpoint number one for VPN Tunnel";

        }

        leaf interface1_type {

            type interface_type;

            //type leafref {

            //    path "????";

            //}

            mandatory true;

            description 'Interface type of interface 1';

            tailf:info "Interface type of interface 1";

        }

        leaf interface1_number {

            type interface_number;

            //type leafref{

            //path "????";

            //}

            mandatory true;

            description 'Interface number of interface 1';

            tailf:info "Interface number of interface 1";

        }


The leaf endpoint1 gives me the possibility to choose only devices which exist in the NSO CDB (in WebUI). So far so good.

I would like to have a similar dropdown for interface type and interface number (or name) which then dont use the typedefs at the top but rather reference the actual info in the CDB.

So the dropdown for "interface_type" should show all interface types which can be configured on an IOS device and the dropdown for "interface_number" should show only the interface numbers/names of actually available interfaces on the device specified in endpoint1.


I have tried various things which all led nowhere for me (importing the yang model of the cisco-ios NED into my own and tried referencing the grouping/choice -interface-name-grouping/interface-choice- which exist in the NED yang model to populate the dropdown.


Further I am trying to access the actually configured IP address of a specific interface. My path expression there doesnt work either (/ncs:devices/ncs:device{R1_PE}/ncs:config/ios:interface/GigabitEthernet{5/0}/ios:ip/ios:address/ios:primary/ios:address). During compilation I keep getting an error that my path argument is wrong: "should be of type path-arg".

As you can probably tell I am not great with XPath...pretty sure the paths I tried arent even valid XPath and therefore I get the error.


Can someone please help? Thanks.


1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Cisco Employee

You can try something of this sort:

choice interface {

    case ios-GigabitEthernet {

        leaf GigabitEthernet {

            type leafref {

                path "deref(../../endpoint1)/../ncs:config/ios:interface/ios:GigabitEthernet/ios:name";

            }

        }

    }

    case ios-TenGigabitEthernet {

        leaf TenGigabitEthernet {

            type leafref {

                path "deref(../../endpoint1)/../ncs:config/ios:interface/ios:TenGigabitEthernet/ios:name";

            }

        }

    }

A choice statement allows you define different mutually exclusive cases.

So the result will be that you can either defined the leaf GigabitEthernet or TenGigabitEthernet but not both of them at the same time (you can add more cases). This should replace the interface-type leaf.

The path on the leafref is dereferencing your endpoint1 leaf which should be present higher on hierarchy.

Once you get it compiled, I suggest testing in on ncs_cli before trying it on the web UI.

It will work on the web UI, but will be easier to debug on the CLI (on the web UI, you might need to reload the page once you select the device - depending on your implementation).

Hope that helps

Yftach

View solution in original post

13 REPLIES 13
Highlighted
Cisco Employee

You can try something of this sort:

choice interface {

    case ios-GigabitEthernet {

        leaf GigabitEthernet {

            type leafref {

                path "deref(../../endpoint1)/../ncs:config/ios:interface/ios:GigabitEthernet/ios:name";

            }

        }

    }

    case ios-TenGigabitEthernet {

        leaf TenGigabitEthernet {

            type leafref {

                path "deref(../../endpoint1)/../ncs:config/ios:interface/ios:TenGigabitEthernet/ios:name";

            }

        }

    }

A choice statement allows you define different mutually exclusive cases.

So the result will be that you can either defined the leaf GigabitEthernet or TenGigabitEthernet but not both of them at the same time (you can add more cases). This should replace the interface-type leaf.

The path on the leafref is dereferencing your endpoint1 leaf which should be present higher on hierarchy.

Once you get it compiled, I suggest testing in on ncs_cli before trying it on the web UI.

It will work on the web UI, but will be easier to debug on the CLI (on the web UI, you might need to reload the page once you select the device - depending on your implementation).

Hope that helps

Yftach

View solution in original post

Highlighted

BTW, Instead of the choice statement, you can also use interface-type enumerations leaf (as you did), and have the different interface leafrefs with relevant 'when' statement according to the interface-type leaf.

Highlighted

Hi, thanks for the helpful answers.

When I try your XPATH expression "deref(../../endpoint1)/../ncs:config/ios:interface/ios:GigabitEthernet/ios:name" I get the following error:

error: XPath error: Invalid namespace prefix: ios

Do I have to import the yang model from the Cisco IOS NED into my own yang model and assign prefix ios to it? If yes, how best do I import the ios NED yang model (there seem to be several mechanisms-import/include/uses)?

Highlighted

OK...answering this one myself:

At the top of my own YANG model I needed:

import tailf-ned-cisco-ios{

    prefix ios;

  }

Also the Makefile needs something uncommented and patched, so that the NED YANG model is considered at compilation time:

## Uncomment and patch the line below if you have a dependency to a NED

## or to other YANG files

YANGPATH += ../../tailf-ned-cisco-ios/src/ncsc-out/modules/yang \

  ../../cisco-ios/src/yang

Nevertheless I still get an error message:

error: the node 'interface' from module 'tailf-ned-cisco-ios' (in node 'config' from 'tailf-ncs') is not found

This is the path expression I use:

"deref(../endpoint1)/../ncs:config/ios:interface/ios:GigabitEthernet/ios:name"

I tried "deref(../../endpoint1)/../ncs:config/ios:interface/ios:GigabitEthernet/ios:name" but that gave me an error that node endpoint1 could not be found, so I am assuming the first path expression is better/correct.

Any ideas?

Highlighted

Hi Ian,

Yes. The import statement on the YANG file and updating the Makefile were the steps to do.

Not sure what is the tailf-ned-cisco-ios line on your makefile. That might be causing the confusion.

For me, the following line does the job (in place of the two lines you provided):

YANGPATH += --yangpath ../../cisco-ios/src/ncsc-out/modules/yang

cisco-ios should be the NED directory, located under the packages directory on your system.

The YANG import statement should be as you provided it:

import tailf-ned-cisco-ios { prefix ios; }

note that the taif-ned-cisco-ios is the module name defined inside the cisco-ios NED directory (have a look under cisco-ios/src/yang), so the makefile, should include only the directory path (cisco-ios), while the import statement in your YANG module should refer to the module name (taif-ned-cisco-ios).

Let me know if it works for you.

Yftach

Highlighted

Hi Yftach,

this worked for me as YANGPATH in the Makefile:

YANGPATH += ../../cisco-ios/src/ncsc-out/modules/yang


In your reply you have YANGPATH += --yangpath ../../cisco-ios/src/ncsc-out/modules/yang...not sure where --yangpath came from. Without it it works fine.

Thank you very much. Your answers have been a great help to me.

Highlighted

Great!

Glad to know you were able to make it work.

Highlighted

Hi,

The --yangpath option was needed in a previous version of the Makefiles and it is not longer needed.

Regards,

Roque

PS: If you check your Makefile, you would find the "--yangpath" option already added here:

NCSCPATH   = $(YANGPATH:%=--yangpath %)

Highlighted

 
Highlighted
Enthusiast

Hi again,

as already mentioned in my original post I would also like to get the IP Information for the interface from the CDB.

I am currently trying the following:

case GigabitEthernet{

         leaf GigabitEthernet-1{

              type leafref {

                   path "deref(../endpoint1)/../ncs:config/ios:interface/ios:GigabitEthernet/ios:name";

              }

          }

         leaf ip-1{

              type leafref{

              path "deref(./GigabitEthernet-1/../ios:ip/ios:address/ios:primary/ios:address)"; //????

               }

          }

}


Again I am getting an error:

error: bad argument value "deref(./GigabitEthernet-1/ios:ip/ios:address/ios:primary/ios:address)", should be of type path-arg


a) What would be a valid and correct path-arg to get the IP address of the selected Interface?

b) Is there some general documentation on the deref() function available? Where?


Thanks in advance for the help.

Highlighted

Hi,

for documentation on the deref function, you can have a look at the nso_man document and also at the NSO development guide.

For what your are trying to achieve with the IP address, can you clarify what you're aiming for?

If you look at the device leaf and the GigabitEthernet leaf, they are both pointing to LISTS on the IOS NED.

In the path for ip-1 in the other hand, all nodes are containers (except from 'address' at the end which is a leaf).

With that in mind, I'm not sure what should be the point of having a leafref, which can point to, at most, one value.

Can you explain the functionally you are looking for?

// interface * / ip address

container address {

  tailf:info "Set the IP address of an interface";

  tailf:cli-incomplete-command;

  tailf:cli-incomplete-no;

  choice address-choice {

    case fixed-case {

      // interface * / ip address a.b.c.d m.a.s.k

      container primary {

        tailf:cli-drop-node-name;

        tailf:cli-compact-syntax;

        tailf:cli-sequence-commands;

        tailf:cli-incomplete-command;

        tailf:cli-incomplete-no;

        // dep: before this created, must change l2vpn xconnect context

        tailf:cli-diff-dependency "/ios:l2vpn-xconnect/l2vpn/xconnect/context" {

          tailf:cli-trigger-on-set;

        }

        leaf address {

          tailf:cli-drop-node-name;

          tailf:cli-incomplete-command;

          tailf:cli-incomplete-no;

          type inet:ipv4-address {

            tailf:info "A.B.C.D;;IP address";

          }

        }

Highlighted

If you want to select an interface by the list of IP primary IP addresses instead of the name of the interface, then you can have the path of the interface leafref to point to the IP address, instead of the name.

So, instead of this:

        leaf GigabitEthernet {

            type leafref {

                path "deref(../../endpoint1)/../ncs:config/ios:interface/ios:GigabitEthernet/ios:name";

            }

        }

You should be able to have something like this:

        leaf GigabitEthernet {

            type leafref {

                path "deref(../../endpoint1)/../ncs:config/ios:interface/ios:GigabitEthernet/ios:ip/ios:address/ios:primary/ios:address";

            }

        }

This way, you should get a list of IP addresses, instead of list of interface names, but I'm not sure if this is what you're after.

Please note that your YANG model does not have to include all the parameters that you want your service to have access to. It should only include the parameters which requires selection.

So if your service is always going to use the primary IP address already configured on the interface that the user will select, then you don't have to include the IP on the YANG model. Instead, the service mapping logic (Java, Python, XML) can fetch this information from the interface configurations in NSO.

Highlighted

Thank you for your replies.

I simply wanted to have the (primary) IP address corresponding to the selected interface on a leaf which I could then reference in my XML template, so there wouldnt be any need for fetching it in the service logic in Java/Python.

I guess you are right though, the selection process for the user finishes by selecting the interface, which implies a certain IP, which then gets fetched in the service logic using Java/Python. Thanks for putting me on that path which I am now likely to follow.