cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1635
Views
15
Helpful
8
Replies

yang xpath questions

erdemk
Level 1
Level 1

Dear NSO community,

 

I have 2 questions related to following model, any help is appreciated ..

 

Ultimately I want to achieve this : When operator selects core-device and core-device-interface ( NSO fetches interfaces which has /30 mask in the example below ), NSO would fetch next-hop-device as the router connected to other end of the selected core-device-interface.

 

Question 1/ As an interim step, I want to fetch next-hop-device as “router which has 1.1.2.3 ip address configured to one of its ports”.  Following xpath expression finds the correct device successfully only when 1.1.2.3 ip configured to the first Gi interface on that device, typically 0/1. But, if i configure 1.1.2.3 ip to , lets say Gi 0/2 interface and Gi 0/1 is configured with any other ip address, then cli hangs while trying to fetch next-hop-device object. I tried couple of things, but couldn't succeed.

 

Question 2/ Instead of fetching router which has 1.1.2.3 ip address configured to one of its ports, I want to fetch router which has ( core-device-interface-ip + 1 ) ip address configured to one of its ports. Question is how can i do this ?

 

 

module aaa {

 

    namespace "http://com/poc/aaa";

    prefix aaa;

 

    import ietf-inet-types {

        prefix inet;

    }

    import tailf-common {

        prefix tailf;

    }

    import tailf-ncs {

        prefix ncs;

    }

 

    import tailf-ned-cisco-ios  {

        prefix ios;

    }

 

    container topology {

 

        list branch {

 

            key branch-name;

            leaf branch-name {type string;}

 

            leaf branch-core-device {

                type leafref {

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

                }

            }

            list branch-devices {

                key branch-device;

                leaf branch-device {

                    type leafref {

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

                    }

                }

            }

        }

    }

 

    list aaa-service {

        key name;

        leaf name {

            type string;

        }

 

        uses ncs:service-data;

        ncs:servicepoint aaa-servicepoint;

 

        container bbb {

            leaf core-device {

                type leafref {

                    path "/topology/branch/branch-core-device";

                }

            }

            leaf core-device-interface {                                         // fetch interfaces with /30 mask

                type leafref {

                    path "/ncs:devices/ncs:device[ncs:name=current()/../core-device]/ncs:config/ios:interface/ios:GigabitEthernet/ios:name";

                }

                must "starts-with(deref(current())/../ios:ip/ios:address/ios:primary/ios:mask, '255.255.255.252')";

            }

            leaf core-device-interface-ip {                                     //  retrieve IP address of the core-device-interface selected

                type leafref {

                    //path "deref(current()/../core-device-interface)/../ios:ip/ios:address/ios:primary/ios:address";

                    path "/ncs:devices/ncs:device[ncs:name=current()/../core-device]/ncs:config/ios:interface/ios:GigabitEthernet[ios:name=current()/../core-device-interface]/ios:ip/ios:address/ios:primary/ios:address";

                }

            }

            leaf next-hop-device {                                                     // select branch device which has ( core-device-interface-ip + 1 ) ip address on one of its interfaces.. in the interim: fetch router with 1.1.2.3 on one of its intf

                type leafref {

                    path "/topology/branch/branch-devices/branch-device";

                }

                must "starts-with(/ncs:devices/ncs:device[ncs:name=current()]/ncs:config/ios:interface/ios:GigabitEthernet/ios:ip/ios:address/ios:primary/ios:address, '1.1.2.3')";

            }

        }

    }

}

 

Many thanks in advance.

8 Replies 8

yfherzog
Cisco Employee
Cisco Employee

Hi,

 

Eventually, there is (at most) only one option for selecting the second device and interface, so there's not much selecting to do here.

What if you skip trying to solve that in YANG and instead you'd fetch the other end from within your service mapping logic?

If you need the other end visible somehow, you can add an operational leaf that the service will update once it finds the other end of the service.

yfherzog hi,

 

Thanks for your reply.

I think i cannot do this in service logic, because there are more than one hops. i mean operator will choose an interface also on next-hop-device.

I have not used operational leafs before.. by the help of operational leafs , will something like this be possible : 

- operator selects interface and commit the change

- service logic calculates and places the next-hop-device into operational leaf

- operator selects interface on the next-hop-device and commits

- ...

if this is how this can be achieved by operational leafs, i will try it.

thanks in advance

When you say that the operator needs to select an interface on the next-hop-device, is that the interface with the +1 ip address?

If so, can there be more than one interface with such address?

If not, is there a particular reason for making that an input variable?

 

 

Hi,

 

Let me explain the scenario, this is actually part of L2/3vpn service, ie one side of the service. 

Within the network, there are branches. Operator selects the branch , when he/she chooses the core-device.

Within the branch, branch devices are connected with mash topology. A service-side instance is created step by step.

- After choosing the core-device,

- First, operator chooses an interface on core-device, other end of this interface is next_hop_device. Lets call this as first_hop_device.

- Second, on the first_hop_device , operator chooses an interface,  other end of this interface is second-hop-device

- Third, on the second_hop_device select an interface, other end of this interface is third_hop_device.

- Goes on like this..

 

note : all subject interfaces are filtered with mask = /30, hence other end ip is +-1, let's take +1 for simplicity

 

How can we achieve by yang or operational leaf..

 

Thanks in advance.

 

 

 

ok.

 

I see what you mean now.

I don't think this can be addressed with operational leafs.

It might be that it can be addressed with leafrefs and must statements, but I'm really not completely sure.

 

Sorry I couldn't be of more help!

yfherzog,

 

Thank you for your reply.. By your reply, i think i found at least one way for solution of my second question, although it may not be the ideal way.

- First, operator chooses the core-device and core-device-interface and commits,

- Then, service returns the first-hop-device in a leaf which is out of service, 

- Then by help of this leaf, i can show to operator the interfaces of first-hop-device and let him/her choose the interface, and commit again..

- This goes on like this till the last device..

I will be looking for how to do it within yang, probably exploiting the xpath expressions, if possible at all.

 

And for the first question, i somehow managed it via following xpath expression.

Instead of this : 

                leaf next-hop-device {          

                    type leafref {

                        path "/topology/branch/branch-devices/branch-device";

                    }

                    must "starts-with(/ncs:devices/ncs:device[ncs:name=current()]/ncs:config/ios:interface/ios:GigabitEthernet/ios:ip/ios:address/ios:primary/ios:address, '1.1.2.3')";

 

I used this : 

                leaf next-hop-device {                        

                        type leafref {

                        path "/topology/branch/branch-devices/branch-device";

                        }

                        must "deref(deref(current()))/../ncs:config/ios:interface/ios:GigabitEthernet[contains(ios:ip/ios:address/ios:primary/ios:address, '1.1.2.3')]/ios:ip/ios:address/ios:primary/ios:address";

 

Thanks and regards..

I just want to point out that maybe you are trying to achieve with NSO two objectives that may be in contraction. On one side, you want NSO to automate your provisioning and activation. On the other side, you want to personalise your operator experience in an increasingly complex way. 

 

You may have solve this current problem but you may have new challenges ahead. This is the reason why a lot of users implement a separate GUI framework on top of NSO APIs and de-couple the two problems.

Thanks for the information ..
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: