You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The first model is the [OpenConfig telemetry model](https://github.com/openconfig/public/blob/master/release/models/telemetry/openconfig-telemetry.yang) and the second is the XR native telemetry model. If you look at them in detail, you will notice that the native model closely follows the OpenConfig model. In fact, the two are more or less functionally equivalent, although the native model will let you do things that are supported by IOS XR but not defined by OpenConfig (like disable TLS). In this tutorial, I'll focus on openconfig-telemetry, but you could do everything with Cisco-IOS-XR-telemetry-model-driven-cfg as well.
52
+
The first model is the [OpenConfig telemetry model](https://github.com/openconfig/public/blob/master/release/models/telemetry/openconfig-telemetry.yang) and the second is the XR native telemetry model. If you look at them in detail, you will notice that the native model closely follows the OpenConfig model, although the native model will let you do things that are supported by IOS XR but not defined by OpenConfig (like disable TLS). In this tutorial, I'll focus on openconfig-telemetry, but you could do everything with Cisco-IOS-XR-telemetry-model-driven-cfg as well.
53
53
54
54
The NETCONF \<get-schema\> operation will give you the contents of the schema but the full YANG output can be really verbose and overwhelming, so I'll pipe the output to the [pyang](https://github.com/mbj4668/pyang) utility for a compact tree view with the following bit of code:
55
55
@@ -163,7 +163,7 @@ module: openconfig-telemetry
163
163
164
164
You can spend a lot of time understanding the intricacies of YANG and all the details, but all we really need to know for now is that the model has three major sections:
165
165
166
-
- The **destination-group** tells the router where to send telemetry data and how.
166
+
- The **destination-group** tells the router where to send telemetry data and how. Only needed for dial-out configuration.
167
167
- The **sensor-group** identifies a list of YANG models that the router should stream.
168
168
- The **subscription** ties together the destination-group and the sensor-group.
So what does all that mean to the router? It breaks down into three parts which you'll recall from the YANG model above:
268
242
269
-
- The **destination-group** tells the router where to send telemetry data and how. If you parse the XML above, you'll see that the router has a destination group named "DGroup 1" that goes to 172.30.8.4 port 5432 using the self-describing GPB encoding.
270
-
- The **sensor-group** identifies a list of YANG models that the router should stream. In this case, the router has a sensor-group called "SGroup1" that will send interface statistics data from the Cisco-IOS-XR-infra-statsd-oper YANG model.
271
-
- The **subscription** ties together the destination-group and the sensor-group. This router has a subscription name "Sub1" that will send the list of models in SGroup1 to the destinations in DGroup1 at an interval of 30 second (30000 milleseconds).
243
+
- The **destination-group** tells the router where to send telemetry data and how. The absence of a destination-group in the output above alerts us to the fact that this is a dial-in configuration (the collector will initiate the session to the router).
244
+
- The **sensor-group** identifies a list of YANG models that the router should stream. In this case, the router has a sensor-group called "SGroup3" that will send interface statistics data from the OpenConfig Interfaces YANG model.
245
+
- The **subscription** ties together the destination-group and the sensor-group. This router has a subscription name "Sub3" that will send the list of models in SGroup3 at an interval of 30 second (30000 milleseconds).
272
246
273
-
If you read the [earlier tutorial](https://xrdocs.github.io/telemetry/tutorials/2016-07-21-configuring-model-driven-telemetry-mdt/) on configuring MDT with CLI, you might recognize this as the same as the TCP Dial-Out configuration described there. If you missed that thrilling installment, the XML above is the YANG equivalent of this CLI:
247
+
If you read the [earlier tutorial](https://xrdocs.github.io/telemetry/tutorials/2016-07-21-configuring-model-driven-telemetry-mdt/) on configuring MDT with CLI, you might recognize this as the same as the gRPC dial-in configuration described there. If you missed that thrilling installment, the XML above is the YANG equivalent of this CLI:
So let's say we want to add a second destination (to `2001:db8:0:100::b`) to DGroup1 and a second model to SGroup1 (Cisco-IOS-XR-ipv4-arp-oper). We can do that with the following NETCONF operations:
270
+
So let's say we want to add a second model to SGroup3 (Cisco-IOS-XR-ipv4-arp-oper). We can do that with the following NETCONF operations:
0 commit comments