Skip to content

Commit c6afa3d

Browse files
vosipchuvosipchu
committed
Posting a doc about filtering in IOS XR Telemetry
1 parent 5d969ab commit c6afa3d

File tree

1 file changed

+163
-0
lines changed

1 file changed

+163
-0
lines changed

‎_tutorials/2018-02-13-filtering-in-telemetry-where-to-apply-and-why.md

+163
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,163 @@
1+
---
2+
published: true
3+
date: '2018-02-13 13:20 -0800'
4+
title: Filtering in Telemetry. Where to apply and why?
5+
author: Viktor Osipchuk
6+
excerpt: Filtering in Telemetry. Where to apply and why?
7+
tags:
8+
- iosxr
9+
- MDT
10+
- Telemetry
11+
- Filtering in MDT
12+
- Streaming Telemetry
13+
---
14+
Let’s continue to explore smaller features available in IOS-XR Model Driven Telemetry, following the previous [post](https://xrdocs.github.io/telemetry/tutorials/2018-01-16-sample-intervals-in-telemetry-configuration), where sample intervals were explained. The goal of this post is to explain what filtering is, how you can use it and couple of benefits coming with filtering.
15+
16+
## Why filtering?
17+
18+
As an engineer, each time someone starts talking about filtering you may start thinking about electric circuits or (radio) signals. In both cases filtering 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.
19+
20+
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 offline processing. If to look through the [models]( https://github.com/YangModels/yang/tree/master/vendor/cisco/xr/631), one can see that IOS XR has [mostly] a model per feature or protocol. This is very convenient and one can quickly find the needed model and start exploring it.
21+
But there is also another side of having a model per feature or protocol. For example, MPLS Traffic 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.
22+
With modern Streaming Telemetry you can afford this. But the question comes right away – do I really want to get all that data? In most situations, the answer will be “No”.
23+
24+
## Filtering options
25+
26+
The very first step for you in any configuration should be an exact path definition. If you’re interested in getting summary information about your auto-mesh tunnels, there is absolutely no need to stream all other 41k different counters at all! Find what you need:
27+
28+
<div class="highlighter-rouge">
29+
<pre class="highlight">
30+
<code>
31+
$ pyang -f tree <span style="font-weight: bold">Cisco-IOS-XR-mpls-te-oper.yang</span> --tree-path <span style="font-weight: bold">mpls-te/auto-tunnel/mesh/summary</span>
32+
module: Cisco-IOS-XR-mpls-te-oper
33+
+--ro mpls-te
34+
+--ro auto-tunnel
35+
+--ro mesh
36+
+--ro summary
37+
<mark> +--ro auto-mesh-tunnels? uint32 </mark>
38+
<mark> +--ro up-auto-mesh-tunnels? uint32 </mark>
39+
<mark> +--ro down-auto-mesh-tunnels? uint32 </mark>
40+
<mark> +--ro frr-auto-mesh-tunnels? uint32 </mark>
41+
<mark> +--ro auto-mesh-groups? uint32 </mark>
42+
<mark> +--ro auto-mesh-destinations? uint32 </mark>
43+
</code>
44+
</pre>
45+
</div>
46+
47+
And it is easy now to get your sensor path based on that information:
48+
49+
<div class="highlighter-rouge">
50+
<pre class="highlight">
51+
<code>
52+
telemetry model-driven
53+
sensor-group mpls-te
54+
sensor-path <span style="font-weight: bold">Cisco-IOS-XR-mpls-te-oper:mpls-te/auto-tunnel/mesh/summary</span>
55+
</code>
56+
</pre>
57+
</div>
58+
59+
As soon as you have your sensor path defined, there might be an option to do even more filtering. The first option is to define what you want to insert into your Time Series Database (TSDB) in [Pipeline](https://github.com/cisco/bigmuddy-network-telemetry-pipeline) configuration. “Metrics.json” is a file used in Pipeline to define what you want to be inserted in your TSDB. Everything NOT specified in that file will be dropped. You can find a high-level overview of this behavior with InfluxDB [here](https://xrdocs.github.io/telemetry/tutorials/2017-04-10-using-pipeline-integrating-with-influxdb) and it will be explained deeper in upcoming tutorials.
60+
61+
Yet another option available for you is to do filtering on the router itself. Starting with IOS XR 6.2.2 release you can configure filtering within your sensor paths.
62+
Have a look at the popular Interface Stats sensor path:
63+
64+
<div class="highlighter-rouge">
65+
<pre class="highlight">
66+
<code>
67+
$ pyang -f tree <span style="font-weight: bold">Cisco-IOS-XR-infra-statsd-oper.yang</span> --tree-path <span style="font-weight: bold">infra-statistics/interfaces/interface/latest/generic-counters</span>
68+
module: Cisco-IOS-XR-infra-statsd-oper
69+
+--ro infra-statistics
70+
+--ro interfaces
71+
<mark> +--ro interface* [interface-name] </mark>
72+
+--ro latest
73+
+--ro generic-counters
74+
+--ro packets-received? uint64
75+
+--ro bytes-received? uint64
76+
+--ro packets-sent? uint64
77+
+--ro bytes-sent? uint64
78+
+--ro multicast-packets-received? uint64
79+
…
80+
</code>
81+
</pre>
82+
</div>
83+
84+
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 filtering!
85+
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 filtering!
86+
There are two ways to apply filtering for interfaces:
87+
- using regex
88+
- specifying an interface
89+
90+
This is an example of how you can ask a router to send you stats for 100G interfaces only:
91+
92+
<div class="highlighter-rouge">
93+
<pre class="highlight">
94+
<code>
95+
sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/<mark>interface[interface-name='HundredGigE*']</mark>/latest/generic-counters
96+
</code>
97+
</pre>
98+
</div>
99+
100+
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.
101+
102+
Specifying an exact interface is straightforward:
103+
104+
<div class="highlighter-rouge">
105+
<pre class="highlight">
106+
<code>
107+
sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/<mark>interface[interface-name='HundredGigE0/0/0/0']</mark>/latest/generic-counters
108+
</code>
109+
</pre>
110+
</div>
111+
112+
As you can see, configuration of filtering is easy and all you need to do, is to specify exactly what you want to stream out (where a model has this choice).
113+
114+
You can find opportunities for filtering in other models as well:
115+
116+
<div class="highlighter-rouge">
117+
<pre class="highlight">
118+
<code>
119+
$ pyang -f tree <span style="font-weight: bold">Cisco-IOS-XR-ip-rib-ipv4-oper.yang</span> --tree-path <span style="font-weight: bold">rib/vrfs/vrf/afs/af/safs/saf/ip-rib-route-table-names/ip-rib-route-table-name/protocol/bgp/as/information</span>
120+
module: Cisco-IOS-XR-ip-rib-ipv4-oper
121+
+--ro rib
122+
+--ro vrfs
123+
<mark>+--ro vrf* [vrf-name]</mark>
124+
+--ro afs
125+
<mark>+--ro af* [af-name]</mark>
126+
+--ro safs
127+
<mark>+--ro saf* [saf-name]</mark>
128+
+--ro ip-rib-route-table-names
129+
<mark>+--ro ip-rib-route-table-name* [route-table-name]</mark>
130+
+--ro protocol
131+
+--ro bgp
132+
<mark>+--ro as* [as]</mark>
133+
+--ro information
134+
+--ro protocol-names? string
135+
+--ro instance? string
136+
+--ro version? uint32
137+
+--ro redistribution-client-count? uint32
138+
+--ro protocol-clients-count? uint32
139+
+--ro routes-counts? uint32
140+
+--ro active-routes-count? uint32
141+
+--ro deleted-routes-count? uint32
142+
+--ro paths-count? uint32
143+
+--ro protocol-route-memory? uint32
144+
+--ro backup-routes-count? uint32
145+
</code>
146+
</pre>
147+
</div>
148+
149+
As you can see, there are several places where you can apply filtering.
150+
Usually in such models you will go with filtering for an exact element, like this:
151+
152+
<div class="highlighter-rouge">
153+
<pre class="highlight">
154+
<code>
155+
sensor-path Cisco-IOS-XR-ip-rib-ipv4-oper:rib/vrfs/<mark>vrf[vrf-name='MDT']</mark>/afs/af/safs/saf/ip-rib-route-table-names/ip-rib-route-table-name/protocol/bgp/as/information
156+
</code>
157+
</pre>
158+
</div>
159+
160+
161+
## Conclusion
162+
163+
As soon as you start trying telemetry, make sure you stream a specific 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 specified useful paths, you have 2 ways to fine tune your telemetry experience: filter on the router and filter on the collector. Filtering on the router gives you a benefit to stream data for the needed elements, like interfaces under attention, specific VRFs or address-families. On the collector side you may specify which fields 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 benefits to the internal MDT operation. Stay tuned, an MDT internal architecture overview will be provided soon!

0 commit comments

Comments
 (0)