Basic Dial-Out
Last updated
Last updated
Configure Dial-Out MDT on XR1 using the following parameters:
The collector is 10.100.100.1:57500
Use GPB-KV
Use gRPC without TLS
Use the YANG model Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters
Push the data at a 5 second interval to the collector
Login to Grafana at http://10.200.255.4 using admin/admin123.
Go to Dashboards:
Create a new dashboard:
Select Add visualization:
Select InfluxDB as the data source:
Enter the copy the following query into this box:
Hit the refresh button. Once the MDT session is configured on XR1, you should start to see data.
MDT (Model Driven Telemetry) is a new feature that allows for optimized export of operational data from a router. Previously, most deployments would use SNMP for polling. You could obtain data such as interface counters, but only at 5 minute intervals. Perhaps you could reduce this to 1 minute intervals, but at the expense of CPU utilization on both the poller and routers.
With MDT, we can collect measurements/data points from routers at a centralized monitoring server at very short intervals. This interval can be so short that is defined in msec, not seconds. This means that you are no longer waiting for SNMP polling cycles to complete. You can get the data in near real-time.
MDT is composed of multiple layers:
The data store layer. Data is stored on the router in a “raw” format in databases.
The data model layer. Data is mapped to a YANG model in order to be able to be consumed by collectors in a predictable format. MDT uses YANG operational models.
The producer layer. This is where the time interval for capturing the data is defined. This is how often to produce the data.
The exporter layer. This is where the destination of the collector is defined, as well as the encoding and transport method.
Note that only *-oper.yang models are used with MDT. These are operational models, not config or action models.
With MDT we have three encoding options:
GPB-Compact (just called “GPB”)
This is the most efficient encoding method. Everything is encoded in binary.
A proto file is required on the collector per YANG model
GPB stands for Google Proto Buffers
GPB-KV (called “self-describing GPB”)
This is a less efficient encoding method. The keys are strings (hence the term “self-describing”) but the data is binary.
Only one proto file is used in total. (No matter how many models are used).
JSON
This is the least efficient encoding method. Everything is a string.
This is generally only used when testing MDT. Once you put it in production, you likely want to compress the data more by using GPB encoding.
MDT has two session initiation methods: dial-in and dial-out.
With dial-in, the collector dynamically creates a session with the router. The router only has to listen for incoming connections. The collector tells the router what YANG model it wants to subscribe to and how often to push the data.
With dial-out, the router initiates the connection to the collector. You must define the YANG path, collector address, encoding/transport, and time interval.
We have a few options for transporting the data. We can use either TCP or gRPC for dial-out, and only gRPC for dial-in.
Generally only gRPC seems to be used for dial-out. (The TCP option is just a raw TCP socket). gRPC is Google RPC. It is a basic RPC framework, but uses the google proto buffs for more efficient encoding. Additionally, gRPC uses HTTPs, so TLS is available for security.
MDT configuration for dial-out is broken into three parts:
The destination
The sensor group (the path for the YANG model)
The subscription, which ties together the destination and sensor group, and defines the interval
We define the destination using the following config. The options for encoding are GPB, GPB-KV, and JSON. We are using GPB-KV, which is called self-describing GPB. The options for transport are gRPC, TCP, or UDP. We are using gRPC without TLS, so we use the no-tls keyword.
Next we define the sensor group. This just contains the paths for the YANG models which contain the data we want to export. In this lab, we were provided with the path. In the next lab, we will see how to find this path ourselves.
Finally, we tie these two items together in a subscription. The interval for streaming the data is configured in msec.
Because our TIG stack has Grafana, we can browse to Grafana and paste the given query to verify we are receiving data. This is explained at the beginning of the lab.
We also should verify the components of the MDT config on the router itself. All show commands begin with show telemetry model-driven so it’s not too difficult to use context-sensitive help to find the information you’re looking for.
First we can see a summary of the MDT sessions. We have one active subscription, one active destination using gRPC without TLS, and one active sensor path.
The subscription shows us that the TCP connection is established:
If we made a typo in the destination address/port, we would see the state as “NA" instead.
We can also see that the sensor path is valid because the state is “resolved.”
If we add a bad sensor path, we can see that the state is “not resolved” because it is an “invalid sensor path.”
By default, the router will use a loopback as the source interface. However, when using a regular interface, you might need to set the third-party app source-interface in the config:
This config gives linux a source “hint” for apps that are running on IOS-XR. Note that this config is available on XRv9K, but not XRd.
See here for more information:
