nso service - concatenated/merged data

[mastedarq]

I've encountered some data concatenation behaviour which I can't figure out how to deal with. Maybe someone will be able to help me with this.

I've got a service called "interface" with piece of which configures IPv6 addresses on interface. I'd also like to add route-tags to some of this addresses (but not for all). From the router perspective the configuration should look like this:

interface GigabitEthernet0/0/0/4
 ipv6 address 2001:cafe:beef:1::1/64
 ipv6 address 2001:cafe:beef:2::1/64 route-tag 10
 ipv6 address 2001:cafe:beef:3::1/64 route-tag 20

Now, I've created such a Yang data representation of above piece of configuration:

...
list ipv6-addresses {
  key ipv6-address;
  
  leaf ipv6-address {
    type string;
  }

  leaf ipv6-route-tag {
    type uint16;
  }
} // list ipv6-addresses
...

* for simplify IPv6 leaf is "string" type here.

My XML template looks like this:

...
<ipv6 when="{/afi='ipv6'}">
  <address>
    <prefix-list>
      <prefix>{/ip-parameters/ipv6-addresses/ipv6-address}</prefix>
      <route-tag>{/ip-parameters/ipv6-addresses/ipv6-route-tag}</route-tag>
    </prefix-list>
  </address>
</ipv6>
...

Now, when I'm configuring instance of this service and specify all of the parameters I've got such a result:

interface GigabitEthernet 0/0/0/4
 ipv6 address 2001:cafe:beef:1::1/64 route-tag 1020 // shouldn't be here at all
 ipv6 address 2001:cafe:beef:2::1/64 route-tag 1020 // should be 10
 ipv6 address 2001:cafe:beef:3::1/64 route-tag 1020 // should be 20
exit

Everything looks ok from service perspective:

interface test 
    ...
    ip-parameters 
        ...
        ipv6-addresses 2001:cafe:beef:1::1/64
        ipv6-addresses 2001:cafe:beef:2::1/64 
            ipv6-route-tag 10
        
        ipv6-addresses 2001:cafe:beef:3::1/64 
            ipv6-route-tag 20;

but the problem appear when passing this configuration to the device:

 devices {
     device r13 {
         config {
             interface {
                 GigabitEthernet 0/0/0/4 {
                     ipv6 {
                         address {
                            prefix-list 2001:cafe:beef:1::1/64 {
                                route-tag 1020;
                            }
                            prefix-list 2001:cafe:beef:2::1/64 {
                                route-tag 1020;
                            }
                            prefix-list 2001:cafe:beef:3::1/64 {
                                route-tag 1020;
			    }
                            ...

I observed similar "concatenation" behaviour with:

- access-lists (where lines were concatenated for each rule ID)

- network statements in BGP address-family (when networks were using route-maps and route-map values were concatenated)

In case with access-list I added some python code with "for" loop which went through ACL list and set parameters to variable and pass it to the XML template. It helped, but... I'm not quite sure why.

I went through IOS-XR NED Yang model to figure out what types of data are the objects I've an issues with, but it appears I've got exactly same types of it in my model.

[yfherzog · Accepted solution]

As template engine is traversing the ipv6-addresses, the XML context is changing to point to the current entry on the list.

You can see that if you run commit dry-run | debug template.

When you try to access nodes with their absolute path, you're resetting that context.

So, what you need to do, is once you provide all key leafs for the list, you need to start referring to other leafs on that list using relative path.

Something like this:

...
<ipv6 when="{/afi='ipv6'}">
  <address>
    <prefix-list>
      <prefix>{/ip-parameters/ipv6-addresses/ipv6-address}</prefix>
      <route-tag>{ipv6-route-tag}</route-tag>
    </prefix-list>
  </address>
</ipv6>
...

[mastedarq]

Works like a charm :)

But as I'm not a programmer, I'll need to go dirt with this xml workflow You just mention about to figure out what's going on with it.

[yfherzog]

The XML processing context is a bit tricky.

Using '| debug template' is your best option to understand what's going on there. It can be very verbose, so might be a bit painful to follow, but once you'll get a hang of it, it should be ok :)

[mastedarq]

---

@yfherzog wrote:

... can be very verbose, so might be a bit painful to follow...

---

Yeah, I've been there, "persistent gaze at" method, similar to how IPSec troubleshoot looks like. It was long long time ago and it still hunts me at night sometimes...