cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1070
Views
10
Helpful
4
Replies

nso service - concatenated/merged data

mastedarq
Level 1
Level 1

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