A quick blog about something bizarre I encountered recently when recording Cisco’s Model Driven Telemetry content in our DEVOCR course. 

The thing about Model-Driven Telemetry (henceforth referred to as MDT) is that whole “Model” thing. When configuring MDT on a Cisco device, the data that you want to stream is in fact identified by a YANG model. Let’s examine the commands using my sample repo from my Cisco-MDT-TIG Stack that is containerized. 

So these are the commands that enable streaming on a Cisco IOS-XE device. Pay attention to line 3. The filter xpath command walks the YANG model down to the data that you care about using, well, XPath. Here’s the thing about YANG models – they contain lists, no different from a Python list [‘item 1’ , ‘item 2’].

So if you want to identify exactly which interface’s statistics you want to monitor, you will have to specify it in your Xpath. You may be looking ahead and noticing the syntax for querying or filtering in XPath. 

The interfaces tier does, in fact, contain a list of interfaces. The next tier is the specific interface, and we specify that interface with the syntax “interface[key=value]”. Makes sense – you want to get statistics on a specific interface so logically we should specify the interface by name, and then we can get it’s statistics.

The challenge comes in when you have to specify TWO keys in order to get to the next tier. I ran into this with Netconf, Restconf, and Streaming Telemetry. Let’s take finding an OSPF Neighbor state, for example.

Pivoting a little bit, examine this RESTCONF URL which navigates the YANG model to get to OSPF neighbor state:

https://10.10.21.15/restconf/data/Cisco-IOS-XE-ospf-oper:ospf-oper-data/ospf-state/ospf-instance=address-family-ipv4,16843009/ospf-area=0/ospf-interface=GigabitEthernet2/ospf-neighbor=2.2.2.2/state

You can see where each list and key|value pair was handled by noticing each = symbol. Very simply, you can see something like ospf-area=0. I’ve already detailed how to handle multiple keys in RESTCONF in a previous post (as seen above in ospf-instance, it uses a comma “,” to separate the values. Ospf-instance is looking for both the address family and the Router-ID expressed in 32 bit format).

So now let’s consider the normal syntax for specifying two keys in XPath using ospf-instance again:

The syntactically correct way to specify two keys in XPath is simply specify an ” and ” in between them. So that’s what you think would be the way to do it in Cisco’s gRPC streaming telemetry. It’s not. The correct way is to specify each key individually.

I honestly went digging for the documentation where I found this little trick (read: frustration) out, but I got lazy. The problem is solved – the solution is to use the two keys separately. 

Fin.