@XRDOCS TELEMETRY BLOGS TUTORIALS SEARCH  TAGS

Shelly Cadora
Principal Technical Marketing Engineer, Cisco Follow

Save to PDF

Sensor Paths for Segment Routing Tra c Engineering

 3 minutes read

Home/ Tutorials/Sensor Paths for Segment Routing Tra c Engineering

SR-TE, Meet MDT

Recently, when I was building out a proof of concept in my lab for some new Segment Routing Tra c
Engineering (SR-TE) use cases, I found myself wanting a quick way to check if all my policies were coming up
and forwarding tra c. Model-Driven Telemetry (MDT) can get a lot of operational data o the network very
quickly. The only tricky part is identifying the YANG model and container that has the best data for a given use
case. So I wanted to share a couple of the SR-TE models that were useful for me.

SR-TE Policy Status

One high-level performance indicator for SR-TE is the operational state of the SR-TE policies on the headend. In
CLI, a quick way to verify that is with this command:


RP/0/RP0/CPU0:iosxrv-1#show segment-routing traffic-eng policy summary
Sun Mar 31 22:55:35.164 UTC

XTC policy database summary:

----------------------------

IPv4 source address: 1.1.1.1

Total configured policies: 6
Operational: up 6 down 0

RP/0/RP0/CPU0:iosxrv-1#

In the output of this command, you can see that all six of the con gured policies are up. This same data can be
found in the XR Native YANG model Cisco-IOS-XR-infra-xtc-agent-oper.yang . That model can have a lot of data, so
to narrow it down to just the policy summary data, specify your MDT sensor-path like this:

sensor-path Cisco-IOS-XR-infra-xtc-agent-oper:xtc/policy-summary

(For the complete con guration of MDT, see Con guring Model-Driven Telemetry ).

If you use pipeline to collect that data, you can easily direct the data to In uxDB and display it with Grafana. Just
add this entry to your metrics.json le in pipeline:
 
{
"basepath" : "Cisco-IOS-XR-infra-xtc-agent-oper:xtc/policy-summary",
"spec" : {
"fields" : [
{"name" : "configured-total-policy-count"},
{"name" : "configured-down-policy-count"},
{"name" : "configured-up-policy-count"}
]
}
}

The resulting graph in Grafana might look something like this as you con gure and bring up SR-TE policies:

SR-TE Topology Summary

Another high-level indicator can be found in the SR-TE topology database statistics. In CLI, a quick way to verify
that is with this command:


RP/0/RP0/CPU0:iosxrv-1#show segment-routing traffic-eng ipv4 topology summary
Sun Mar 31 23:24:38.880 UTC

XTC Agent's topology database summary:

--------------------------------

Topology nodes: 8
Prefixes: 6
Prefix SIDs: 11
Links: 20
Adjacency SIDs: 40

RP/0/RP0/CPU0:iosxrv-1#

This same data can be reported via MDT using this sensor-path:


sensor-path Cisco-IOS-XR-infra-xtc-agent-oper:xtc/topology-summary

Not surprisinging, the metrics.json entry for this sensor-path looks like this:


{
"basepath" : "Cisco-IOS-XR-infra-xtc-agent-oper:xtc/topology-summary",
"spec" : {
 "fields" : [
{"name" : "links"},
{"name" : "nodes"},
{"name" : "prefix-sids"},
{"name" : "adjacency-sids"},
{"name" : "prefixes"}
]
}
}

Here is the resulting graph when I brought up my 8-node lab topology:

SR-TE Policy Tra c

The proof in the SR-TE pudding is whether or not tra c is actually getting forwarded by that policy. I explored
several di erent YANG models for this, but the best one ended up being one of the most common MDT sensor-
paths – good old interface statistics!

The sensor-path for interface statistics is as follows:


sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters

No need to modify the metrics.json le for this one: it’s included in the default metrics.json le in pipeline.

The “interface” to monitor in this case is actually the name of the SR-TE policy. The name is a combination of the
policy’s color and tailend, e.g. “srte_c_10_ep_1.1.1.6” is the index name for the policy with Color 10, Tailend
1.1.1.6.

The following graph shows tra c starting to ow through seven SR-TE policies:

To display only the SR-TE policy interfaces, structure your Query in Grafana like this:
 
"SELECT \"packets-sent\" FROM \"Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/

Tra c Collector and SR Tra c-Matrix (SR-TM)

Interested in the tra c patterns on your network? SR-TM tracks the aggregated ows that enter and leave the
network. The Tra c Collector process collects and stores histories of packet and bytes statistics for pre xes,
tunnel counters and the Tra c-Matrix counters.

The sensor-path for Tra c-Collector is as follows:


sensor-path Cisco-IOS-XR-infra-tc-oper:traffic-collector/afs/af/counters/tunnels/tunnel

If you’re using pipeline, add this to your metrics.json:


{
"basepath" : "Cisco-IOS-XR-infra-tc-oper:traffic-collector/afs/af/counters/tunnels/tunnel",
"spec" : {
"fields" : [
{"name":"interface-name", "tag": true},
{"name":"is-active"},
{"name":"interface-name-xr"},
{"name":"base-counter-statistics",
"fields" : [
{"name":"count-history",
"fields" : [
{"name":"transmit-number-of-bytes-switched"},
{"name":"transmit-number-of-packets-switched"},
{"name":"event-end-timestamp"},
{"name":"event-start-timestamp"}
]
},
{"name":"transmit-packets-per-second-switched"},
{"name":"transmit-bytes-per-second-switched"}
]
}
]
}
}

Thanks to my colleague, @StLitkowski, for working this one out.

Just the Beginning

These four sensor-paths should get you started with high-level monitoring of SR-TE. But it’s really just the
beginning. Once you start exploring, you’ll quickly realize that IOS XR has an astonishing amount of SR-TE data
available in YANG models and streamable via MDT.

 Tags: iosxr MDT segment routing SR-TE telemetry traffic-engineering

 Updated: March 31, 2019

SHARE ON

   

Leave a Comment

What do you think?

5 Responses

Upvote Funny Love Surprised

6 Comments 
1 Login

G Join the discussion…

LOG IN WITH OR SIGN UP WITH DISQUS ?

Name

 Share Best Newest Oldest

G
Gonzalo Diaz − ⚑
5 years ago

Hi Shelly, thank you for all your contributions, all of them were vital to start with the MDT
approach

I'm working with MDT also and just wanted to know about the tricky process of nding
the correct native yang model?

Do you use a manual approach o the github repository? Is there a way to nd out the
correct model from a cli show command?

Thanks in advance

0 0 Reply ⥅

S
Shelly Cadora > Gonzalo Diaz − ⚑
5 years ago

Hi, Gonzalo.
 For operational data, there isn't a good automatic way to translate between CLI
and native models today. We're working on this from a variety of angles and
hope to have better answers in the future. If you have some speci c show
command you're looking for, I'll try to help if I can. Long familiarity with the oper
models is my only advantage :)

Take care,
Shelly

0 0 Reply ⥅

G
Gonzalo Diaz > Shelly Cadora − ⚑
5 years ago

Hi Shelly,

I was looking for speci c CGN on ASR9K, but i make a workaround

validating local pool usage for pre-nat side with a yang model for "ip
daps" if i remember correctly :)

Best regards

0 0 Reply ⥅

U
uldanay moldagaliyeva − ⚑
5 years ago

Hi Shelly, thank you for your blogs.

I am a student. in laboratory we want to collect data from cisco asr9k and perform ML to
detect HTTP-get type attack (layer 7). For that I need telemetry data about request rate,
average request time, average length of requests. Please, could you suggest me
appropriate Cisco Yang models to collect such kind of information or something related.
I tryed to collect interfaces statistics and tcp statistics, but they are not appropriate for
my purpose.
Thank you!

0 0 Reply ⥅

V
Viktor Osipchuk > uldanay moldagaliyeva
− ⚑
5 years ago

Hi Uldanay,

if you're targeting L7 collection, you have to collect telemetry data from your
server. There is not that much you can get from your router. (though, XR can
stream tons of data)

0 0 Reply ⥅

S
Shelly Cadora > uldanay moldagaliyeva
− ⚑
5 years ago

Is there a CLI that you use today to get that data? If there's a CLI, then we know
that the data actually exists inside the router. Then we can nd the model.

Thanks,
 a s,
Shelly

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.