07-07-2023 01:27 PM
I can successfully configure a data-kicker to monitor any changes within an interface:
admin@ncs(config)# kickers data-kicker mykicker monitor /devices/device[name='c0']/config/interface
admin@ncs(config-data-kicker-mykicker)# commit
Commit complete.
but trying to limit the kicker scope further within the interface fails:
admin@ncs(config)# kickers data-kicker mykicker monitor /devices/device[name='c0']/config/interface/switchport
admin@ncs(config-data-kicker-mykicker)# commit
Aborted: 'kickers data-kicker mykicker monitor': invalid path.
I tried examining the YANG to get some clues, but was surprised to discover "switchport" and "vlan" leafs don't exist:
mike@Mikes-MacBook-Pro yang % pwd
/Users/mike/ncs/install-5.7.11/src/ncs/yang
mike@Mikes-MacBook-Pro yang % grep -r --include="*.yang" "switchport" *
mike@Mikes-MacBook-Pro yang %
mike@Mikes-MacBook-Pro yang % grep -r --include="*.yang" "vlan" *
tailf-cli-extensions.yang: vlan 1,3,10-20,30,32,300-310
mike@Mikes-MacBook-Pro yang %
How can I create a data-kicker monitor for all interface switchport access vlans on a device?
Solved! Go to Solution.
07-11-2023 12:57 AM
The YANG type is in fact an instance-identifier, and not an identityref.
But the actual type used in our model is the "node-instance-identifier". From tailf-kickers.yang
leaf monitor {
type tailf:node-instance-identifier;
mandatory true;
...
}
And "node-instance-identifier" is essentially the same as the yang builtin "instance-identifier", except that predicates for keys are optional. That is why this expression above works:
/devices/device[name='c0']/config/interface/GigabitEthernet/switchport/access/vlan
Here, the key for the list GigabitEthernet is not specified - which means it will monitor all instances of the list.
Other than keys, there is no way to skip some nodes in the path or use wildcards for path nodes etc.
07-10-2023 12:28 AM
Hi
Looks like your xpath is invalid because the interface type is missing, try this:
kickers data-kicker mykicker monitor /devices/device[name='c0']/config/interface/*/switchport
Or if you know the type (for example GigabitEthernet):
kickers data-kicker mykicker monitor /devices/device[name='c0']/config/interface/GigabitEthernet/switchport
HTH
07-10-2023 04:59 AM
Hello Marcel,
Thank you for the suggestions. The first one seems like an intuitive solution, but gives the same result:
admin@ncs(config)# kickers data-kicker mykicker monitor /devices/device[name='c0']/config/interface/*/switchport
admin@ncs(config-data-kicker-mykicker)# commit
Aborted: 'kickers data-kicker mykicker monitor': internal error
The second one worked for me:
admin@ncs(config-data-kicker-mykicker)# kickers data-kicker mykicker monitor /devices/device[name='c0']/config/interface/GigabitEthernet/switchport/access/vlan
admin@ncs(config-data-kicker-mykicker)# commit
Commit complete.
I'm thrilled to have your solution and would also like to better understand why my initial monitor (and your wildcard version) do not work. It seems like NSO has some "special" way of processing interfaces.
Best regards,
Mike
07-10-2023 05:15 AM
Actually I don't have to much experience with kickers and need to dig in myself. I hope one of the NSO cracks in the forum can explain this.
07-11-2023 12:13 AM
I'm thrilled to have your solution and would also like to better understand why my initial monitor (and your wildcard version) do not work. It seems like NSO has some "special" way of processing interfaces.
Your example did not work just because it's an invalid xpath - you must specify this intermediate node in some way - I don't know why my first example is not working - from my point of view it should, cause it's a valid path. However, can you try this one as well:
kickers data-kicker mykicker monitor /devices/device[name='c0']/config/interface//switchport
07-11-2023 12:29 AM
07-11-2023 12:39 AM
Thanks for the clarification.
07-11-2023 12:57 AM
The YANG type is in fact an instance-identifier, and not an identityref.
But the actual type used in our model is the "node-instance-identifier". From tailf-kickers.yang
leaf monitor {
type tailf:node-instance-identifier;
mandatory true;
...
}
And "node-instance-identifier" is essentially the same as the yang builtin "instance-identifier", except that predicates for keys are optional. That is why this expression above works:
/devices/device[name='c0']/config/interface/GigabitEthernet/switchport/access/vlan
Here, the key for the list GigabitEthernet is not specified - which means it will monitor all instances of the list.
Other than keys, there is no way to skip some nodes in the path or use wildcards for path nodes etc.
07-11-2023 01:08 AM
As per stated in the tailf-kicker.yang module, the "monitor" leaf takes a value that is "like a yang instance-identifier but list nodes may be specified without keys, omitting the key predicate will be interpreted as a key wild-card.
leaf monitor {
type tailf:node-instance-identifier;
mandatory true;
tailf:validate data-kicker {
tailf:internal;
tailf:dependency ".";
tailf:dependency "../variable";
}
description
"If a node that matches the value of this leaf is changed,
the 'trigger-expr' expression is evaluated, and the
'trigger-type' is used to determine if the kicker triggers
or not.
The value of this leaf is like an instance-identifier, but
a list may be specified without any keys. This is treated like
a wildcard that matches all entries in the list.";
}
As far as i can read from ABNF grammar a yang instance-identifier is not allowed to use the "//" operator. So you need a fully specified path. Which is what you tried in the second one that worked.
07-11-2023 05:29 AM
Many thanks to Marcel for demonstrating a way to get to the vlan node and you all for clarifying the differences between a kicker monitor and an Xpath. I now have a better understanding of the constraints involved.
Best regards,
Mike
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