@XRDOCS TELEMETRY BLOGS TUTORIALS SEARCH  TAGS

Viktor Osipchuk
ex-Cisco Follow

Save to PDF

Filtering in Telemetry. Where to apply and why?

 4 minutes read

Home/ Tutorials/Filtering in Telemetry. Where to apply and why?

Let’s continue to explore smaller features available in IOS-XR Model Driven Telemetry, following the previous
post, where sample intervals were explained. The goal of this post is to explain what ltering is, how you can use
it and couple of bene ts coming with ltering.

Why ltering?

As an engineer, each time someone starts talking about ltering you may start thinking about electric circuits or
(radio) signals. In both cases ltering is used to get rid of everything, that is not needed. Like removing of high
order harmonics, that can lead to equipment damage (in electric circuits) or improper signal processing and
recovery.

Streaming Telemetry in IOS XR appeared back in 6.0.1 release and there are around 200 Native YANG models
available today (with 6.3.1 release). The major goal is to make every counter in a box available to you for o ine
processing. If to look through the models, one can see that IOS XR has [mostly] a model per feature or protocol.
This is very convenient and one can quickly nd the needed model and start exploring it. But there is also
another side of having a model per feature or protocol. For example, MPLS Tra c Engineering has been available
in IOS XR for many years and has a very wide coverage. As the result, MPLS-TE YANG native model has more
than 41k leafs of operational data! Correlate this with the number of tunnels you can have and you can see, that
the amount of data streamed out could be enormous. With modern Streaming Telemetry you can a ord this. But
the question comes right away – do I really want to get all that data? In most situations, the answer will be “No”.

Filtering options

The very rst step for you in any con guration should be an exact path de nition. If you’re interested in getting
summary information about your auto-mesh tunnels, there is absolutely no need to stream all other 41k di erent
counters at all! Find what you need:

$ pyang -f tree Cisco-IOS-XR-mpls-te-oper.yang --tree-path mpls-te/auto-tunnel/mesh/summary

module: Cisco-IOS-XR-mpls-te-oper
+--ro mpls-te
+--ro auto-tunnel
+--ro mesh
+--ro summary
+--ro auto-mesh-tunnels? uint32
+--ro up-auto-mesh-tunnels? uint32
+--ro down-auto-mesh-tunnels? uint32
+--ro frr-auto-mesh-tunnels? uint32
 +--ro auto-mesh-groups? uint32
+--ro auto-mesh-destinations? uint32

And it is easy now to get your sensor path based on that information:

telemetry model-driven
sensor-group mpls-te
sensor-path Cisco-IOS-XR-mpls-te-oper:mpls-te/auto-tunnel/mesh/summary

As soon as you have your sensor path de ned, there might be an option to do even more ltering. The rst
option is to de ne what you want to insert into your Time Series Database (TSDB) in Pipeline con guration.
“Metrics.json” is a le used in Pipeline to de ne what you want to be inserted in your TSDB. Everything NOT
speci ed in that le will be dropped. You can nd a high-level overview of this behavior with In uxDB here and it
will be explained deeper in upcoming tutorials.

Yet another option available for you is to do ltering on the router itself. Starting with IOS XR 6.2.2 release you
can con gure ltering within your sensor paths. Have a look at the popular Interface Stats sensor path:

$ pyang -f tree Cisco-IOS-XR-infra-statsd-oper.yang --tree-path infra-statistics/interfaces/interface/latest/ge

module: Cisco-IOS-XR-infra-statsd-oper
+--ro infra-statistics
+--ro interfaces
+--ro interface* [interface-name]
+--ro latest
+--ro generic-counters
+--ro packets-received? uint64
+--ro bytes-received? uint64
+--ro packets-sent? uint64
+--ro bytes-sent? uint64
+--ro multicast-packets-received? uint64
…

In the highlighted section you can see “interface-name” in square brackets. It shows that all the leafs below will
be sent for each interface. And this is exactly the place where you can apply ltering! Your router might have a
big number of interfaces. If you are interested in 100G interfaces only, or if you don’t care about sub-interfaces,
or if you just need to get stats from your core facing ports, you can achieve this with ltering! There are two ways
to apply ltering for interfaces:

using regex
specifying an interface

This is an example of how you can ask a router to send you stats for 100G interfaces only:

sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface[interface-name='HundredGigE*']

An asterisk (a “*” symbol) above is used to represent “any” interface that is 100G (“HundredGigE”). This way
Streaming Telemetry will push stats for all 100G interfaces on a router.
Specifying an exact interface is straightforward:

sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface[interface-name='HundredGigE0/0

As you can see, con guration of ltering is easy and all you need to do, is to specify exactly what you want to
stream out (where a model has this choice).

You can nd opportunities for ltering in other models as well:

$ pyang -f tree Cisco-IOS-XR-ip-rib-ipv4-oper.yang --tree-path rib/vrfs/vrf/afs/af/safs/saf/ip-rib-route-table-

module: Cisco-IOS-XR-ip-rib-ipv4-oper
+--ro rib
+--ro vrfs
+--ro vrf* [vrf-name]
+--ro afs
+--ro af* [af-name]
+--ro safs
+--ro saf* [saf-name]
+--ro ip-rib-route-table-names
+--ro ip-rib-route-table-name* [route-table-name]
+--ro protocol
+--ro bgp
+--ro as* [as]
+--ro information
+--ro protocol-names? string
+--ro instance? string
+--ro version? uint32
+--ro redistribution-client-count? uint32
+--ro protocol-clients-count? uint32
+--ro routes-counts? uint32
+--ro active-routes-count? uint32
+--ro deleted-routes-count? uint32
+--ro paths-count? uint32
+--ro protocol-route-memory? uint32
+--ro backup-routes-count? uint32

As you can see, there are several places where you can apply ltering. Usually in such models you will go with
ltering for an exact element, like this:

sensor-path Cisco-IOS-XR-ip-rib-ipv4-oper:rib/vrfs/vrf[vrf-name='MDT']/afs/af/safs/saf/ip-rib-route-table-names

Conclusion

As soon as you start trying telemetry, make sure you stream a speci c path within a model and not all the
counters from that model. It will remove wasting of resources on the router, on the wire and on the collection
side. After you speci ed useful paths, you have 2 ways to ne tune your telemetry experience: lter on the router
and lter on the collector. Filtering on the router gives you a bene t to stream data for the needed elements, like
interfaces under attention, speci c VRFs or address-families. On the collector side you may specify which elds
you want to insert into your database. Both ways help with improving resource utilization. Filtering on the router
side also brings additional not so obvious bene ts to the internal MDT operation. Stay tuned, an MDT internal
architecture overview will be provided soon!

 Tags: Filtering in MDT iosxr MDT Streaming Telemetry Telemetry

 Updated: February 13, 2018

SHARE ON

   

Leave a Comment

6 Comments 
1 Login

G Join the discussion…

LOG IN WITH OR SIGN UP WITH DISQUS ?

Name

 1 Share Best Newest Oldest

JP Lopes − ⚑
5 years ago

Hi Viktor,
When you lter the telemetry information at the router within the sensor paths, is the
ltering being done pre or pos processing?
For example, when you lter for just HundredGigE* interfaces like in the example you
presented, does the router "queries" all its interfaces (100G, 10G,1G,...) and only streams
out the 100G ones, or does the router "queries" only its 100G interfaces? In terms of
router processing it's quite different...

0 0 Reply ⥅

Victor Maggiolo − ⚑
5 years ago edited

Hey Viktor,

Thanks for all the information !

Is there a way to tell pipeline to only output the data of a speci c xport_input section to a
speci c xport_output section ? instead of the default all-to-all fashion ?

For instance:

[myInput1]
...

[myInput2]
..

[myInput3]
...

[defaultOutput]
output myInput1, myInput2 and myInput3

[myTapOutput]
output only myInput3

Regards,

Victor

0 0 Reply ⥅

V
Viktor Osipchuk Mod > Victor Maggiolo − ⚑
5 years ago

Hi Victor! No, you just activate input/output and it will in all-to-all fashion. There
is no way to specify direction today.
thanks!

/Viktor

0 0 Reply ⥅

Denis Fischer − ⚑
5 years ago

Hello Victor!
Is it possible to limit the depth of the path?
For example, we have the path Cisco-IOS-XR-controller-optics-oper:optics-oper/optics-
ports/optics-port/optics-info and we only need counters for this path.
But the router also collects counters for all of the lower paths.
On one of the routers it takes up to 226819 ms.
Do you have any advice on how to get around this?

0 0 Reply ⥅

V
Viktor Osipchuk Mod > Denis Fischer
− ⚑
5 years ago

Hi Denis,
you can't do ltering based on the depth. Can you please send me an email with
more details like platform / version / # of pluggables / total
 more details, like platform / version / # of pluggables / total
collection+encoding time / elds you need to be collected. If you can attach sh
run telem m and sh tele m subs <> internal, it would be great (your time is very
high). Thanks!

0 0 Reply ⥅

S
Shukhrat Ibragimov > Viktor Osipchuk 5 years ago
− ⚑
Hi Viktor!

Did you nd solution for this?

For example, I need telemetry data only for "Cisco-IOS-XR-
wdsysmon-fd-oper:system-monitoring/cpu-utilization/total-cpu-
one-minute", not the "Cisco-IOS-XR-wdsysmon-fd-oper:system-
monitoring/cpu-utilization/process-cpu" sub-tree.

0 0 Reply ⥅

Subscribe Privacy Do Not Sell My Data

FOLLOW:  TWITTER  GITHUB  FEED

This site is maintained by Cisco Systems, Inc. employees. Powered by Jekyll & Minimal Mistakes.