02-03-2020 03:08 AM
In case of peer-links, we would generally be using same port number on both end of the connection.
So accordingly, I was passing [ 1/27 1/27] as port numbers used for peer-link and based on device-index, xml was configured to select the related one.
When added the config, NCS complained about “non-unique members” as part of leaf-list.
admin@ncs(config)# load merge /ncs-run/packages/cc-nso-service/test.config
Loading.
Error: bad value: "1/27 1/27" has non-unique members.
Error: on line 116: physical-interfaces access-vpc-peer-link1 [ 1/27 1/27 ]
As a work-around or fix, I have kept only one port as input and in XML, calling first element for both device.
This work-around or way of calling the interfaces would work as long as both end of the connection are having same port number. How about considering the case where, they may not be the same?
I looked around and came across “unique-leaf-list” statement but didn't find any usage or implementation.
The "unique-leaf-list" statement takes as an argument the string "true" or "false". If "unique-leaf-list" is "true", values within the leaf-lists must be unique. If "unique-leaf-list" is "false", values within the leaf-lists may be repeated. If "unique-leaf-list" is not specified, the default is true.
I tried to use this option but then NCS does not recognise it and threw error which I assume, indicates that it is not supported.
Looking forward for your suggestion/comment on this case.
Solved! Go to Solution.
02-03-2020 04:30 AM
If there are always going to be two entries on each of those lists, then you can model that as two leafs rather than a list, and then they can have the same value.
02-03-2020 03:43 AM
You didn't share much details of your model, but anyhow, I don't see how a non-unique leaf-list might work.
For leaf-list, the leaf is the list key. By definition, keys have to be unique. Otherwise, how would you identify the entry?
I'd suggest trying to figure out what is it that you try to model, and whether this leaf-list is the most appropriate way to do so, given the requirements that you mention.
It might be that some sort of a list is in order - one which is not identified by the port number alone - maybe a list having device + port number as keys, or something along those lines...
02-03-2020 04:07 AM
@yfherzog , thank you for your response.
Below is the portion of model that I have in place:
grouping cvim {
leaf type {
mandatory true;
tailf:info "Type";
type enumeration {
enum full-on;
enum micro-pod;
enum edge;
}
}
leaf nic-type {
mandatory true;
tailf:info "Nodes NIC Type";
type enumeration {
enum cisco;
enum intel;
}
}
container physical-interfaces {
tailf:info "Nodes switch interface connections";
leaf-list access-vpc-peer-link1 {
type string;
ordered-by user;
tailf:info
"VPC peer link between Access switch A and B for Layer-3; example: [1/27, 1/27]";
}
leaf-list access-vpc-peer-link2 {
type string;
ordered-by user;
tailf:info
"VPC peer link between Access switch A and B for Layer-3; example: [1/28, 1/28]";
}
leaf-list core-vpc-peer-link1 {
type string;
ordered-by user;
tailf:info
"1st VPC peer link between Core Switch A and B for Layer-3; example: [1/47, 1/47]";
}
leaf-list core-vpc-peer-link2 {
type string;
ordered-by user;
tailf:info
"2nd VPC peer link between Core Switch A and B for Layer-3; example: [1/48, 1/48]";
}
}
}
I am passing the XPATH of the port number to the device template.
Coming to your suggestion, based on the fact that leaf is the list key, we need to add some uniqueness. Example - combination of device + port number.
I probably should modify my YANG to consider this case then.
Thank you..
02-03-2020 04:30 AM
If there are always going to be two entries on each of those lists, then you can model that as two leafs rather than a list, and then they can have the same value.
02-03-2020 04:39 AM
Yes, that can be done.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide