IOS-XR 7.1.3: On-box filtering in telemetry

[BostjanLa]

Hello

I have problem that when I am using telemetry to stream out basic interface statistic how to limit the number of dynamic pppoe interfaces for which I won’t send out data.

I am using following sensor-path:

Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface[interface-name="Bundle-Ether*|GigabitEthernet*|TenGigE*|BVI*"]/interface-statistics/basic-interface-stats

But in this way, I also include dynamic pppoe interfaces:

Bundle-Ether59.3900.pppoe39 

Bundle-Ether59.3900.pppoe61 

Bundle-Ether59.3900.pppoe151

Bundle-Ether59.3900.pppoe238

Bundle-Ether59.3900.pppoe363

Bundle-Ether59.3900.pppoe546

How should I exclude them but still include the Bundle_Ethernet major interfaces ?

How 

Some advice? Thx

[smilstea]

So it looks like you already have some filtering setup, however just using * which means anything.

This guide talks about regex attributes like * etc but not how far we can filter, like if we can tell the regex to look for pppoe and exclude those interfaces or not.

https://xrdocs.io/telemetry/tutorials/2018-02-13-filtering-in-telemetry-where-to-apply-and-why/

I did some research internally and found a few more examples and it looks like we don't follow traditional regex rules. Normally * just means the previous character zero or more times, but .* means any character zero or more times, but in our case we use * to represent .*. Just to be confusing I would have to assume.

Anyways below are a few examples I pulled, I am not sure if the 'r' is needed or not.

Another way to do this is to specify each bundle interface by name with no regex as its own sensor path, its more tedious to configure but I know that will work.

Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface[interface-name=r'GigabitEthernet0/0/0/[1-2]']

Cisco-IOS-XR-ip-rib-ipv4-oper:rib/vrfs/vrf[vrf-name=r'fo.*']/afs/af[af-name=r'IP.*']/safs/saf/ip-rib-route-table-names/ip-rib-route-table-name/routes/route[address=r'100.100.100.*',prefix-length=r'[2-3][0-9]']

Cisco-IOS-XR-ipv4-arp-oper:arp/nodes/node[node-name=r'0/RP./CPU0']/entries/entry

Sam

[BostjanLa]

Hello Sam

Thx for your answer I tried but the result is the same.

If I use the following sensor-path: Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface[interface-name='Bundle-Ether1']/interface-statistics/basic-interface-stats

And I play with different filters the results are as folows:

interface-name=	Sensor Path State:
“Bundle-Ether*”	Resolved
“Bundle-Ether1”	Resolved
“Bundle-Ether[0-9]”	Not Resolved
“Bundle-Ether[0-9][0-9]”	Not Resolved
“Bundle-Ether[0-9]*”	Not Resolved

If I look into your examples this should work but it doesn’t.

The “r” in [interface-name=r”something”] is there for RegEx, but if I put him there the result is also the same.

I am doing this on ASR9901 platform sw 7.1.3.

BR Bostjan

[smilstea]

So it looks like that came in 7.4.1, the additional regex values e.g. '[0-9]'.

I am going to talk to some people internally on this.

I did come across this particular classification that might help.

typedef Interface-type-set {
type enumeration {
enum "hardware-interfaces" {
value 0;
description
"Restrict the output to hardware interfaces only";
}
}
description
"Interface type set";
}

https://github.com/YangModels/yang/blob/master/vendor/cisco/xr/713/Cisco-IOS-XR-pfi-im-cmd-oper.yang

Sam

[BostjanLa]

Hello Sam

If you look at the Interface-name definition in Cisco-IOS-XR-types.yang whic is part of Cisco-IOS-XR-pfi-im-cmd-oper.yang for version 7.1.3 it is as follows:

  typedef Interface-name {
    type string {
      pattern "[a-zA-Z0-9.:_/-]+";
    }
    description
      "An interface name specifying an interface type and
       instance.
       Interface represents a string defining an interface
       type and instance, e.g. MgmtEth0/4/CPU1/0 or
       TenGigE0/2/0/0.2 or Bundle-Ether9 or
       Bundle-Ether9.98 or Serial0/0/0/0/3/1:1";
  }

So, everything I do and you are proposing is inside the above definition and should work but doesn’t.

I am still waiting for an official answer form Cisco because I opened support case for this.

Thx and BR

Bostjan

[Fredrik Lönnman]

You're reading this wrong way, the type string pattern in the YANG model is a regexp of what is allowed to be typed in the Interface-name definition, as the pattern reads you are allowed to use one or more of the characters a-zA-Z0-9.:_/-, the model itself does not imply any sort of regexp usage within this pattern. 

I know some form of regexps are allowed in the interface-name, but this cannot be inferred from the model you are quoting.

[BostjanLa]

Thanks for clarifying this.

BR

[smilstea]

You said you have a support case open, can you send me the TAC SR you have open for this?

Also I spoke with the PFI team responsible for this yang model and they recommend this:

If the requirement is only to get statistics for their Bundle interfaces, then we can use regex on native model path to filter out bundle interface-names bearing dot character like -

Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface[interface-name='Bundle-Ether*[^.]']/interface-statistics

Sam

[BostjanLa · Accepted solution]

Yes, the SR is 691746170 and yesterday I got the official answer on my question about using RegEx in sensor-path.

the actual support for regular expressions for sensor-paths is going to be supported from 7.4.1.

This feature is introduced via the following two enhancement bugs:

CSCvw21787: Telemetry: support regex filters for oc model sensor-paths and for on-change subscriptions

Integrated-releases: 07.04.01.009i.BASE, 07.04.01.009i.MGBL

CSCvw21652: Telemetry: support regex filters for native model sensor-paths

Integrated-releases: 07.04.01.005i.MGBL

At this point, the only regex supported is the '*'.

[smilstea]

So I wanted to follow up and try to get you an answer that works in your version of code.

You are right that additional regex comes in later code, and that is what I was working off of but was trying to confirm what regex worked or not as the enhancement you linked doesn't do a good job describing it to TAC engineers unfortunately.

The statsd (statistics) team confirmed that .pppoe interfaces do not give generic stats and should not give statistics for the yang model you specified. Are you seeing differently?

"

You may use "Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/cache/generic-counters"
or Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters

The first one is recommended as it reads stats from cache which is updated every 30s

the second one reads from hardware

"

Let me know if that helps.

If that does not then our only option may be to upgrade to 7.4.1.

Sam

[smilstea]

Can you let me know if this helped?

Sam

[BostjanLa]

Hello Sam

In the past we also tried this from you proposed model, but for some reason we didn’t get no data to Grafana. I tried it again but I am getting no data to Grafana. The guy who is admin for Grafana is on vacations. I think he returns next week.

I will let you know about the results.

BR Bostjan

[BostjanLa]

I also tried this last proposal from you and is not working.