A new gRPC-TLS profile that contains a pair of trustpoints is added to the telemetry configuration, so that a client ID certificate can be used for mutual authentication. The profile contains two trustpoints, one is the Certificate Authority (CA) certificate for server validation, and the other is the ID certificate for client validation. When a device connects to a receiver for the first time, based on the server configuration, client or mutual authentication may be required. The device will receive the receiver's identity certificate and validate whether the certificate is signed by the CA identified in the certificate associated with the trustpoint configured in the receiver profile.
If the receiver then requests for the certificate ID of the device, the device sends the client ID certificate previously installed in the profile’s ID-trustpoint field. If the server is configured to require mutual authentication, and there is no client ID trustpoint in the profile, the client authentication will not happen, nor will the connection succeed. The same trustpoint label can be configured for multiple profiles, and the same profile can be configured for multiple receivers. The trustpoint with the client ID is not mandatory in the profile configuration, as mutual authentication is not required for gRPC over TLS.
As in prior releases, gRPC over TLS can be configured only with server validation. Note To add the client ID trustpoint, use the telemetry protocol grpc profile command. This feature cannot be disabled; but it can be left unused by not configuring the receivers to use the gRPC-TLS protocol, or by removing or not configuring the client ID trustpoint field in the receiver configuration. This example shows how to configure a gRPC-TLS profile for mutual authentication.
telemetry receiver protocol grpc-mtls host name collector.cisco.com 57500 protocol grpc-tls profile different-ca telemetry ietf subscription 100 encoding encode-kvgpb filter xpath /memory-ios-xe-oper:memory-statistics/memory-statistic receiver-type protocol stream yang-push update-policy periodic 5000 receiver name grpc-mtls High Availability in Telemetry Dynamic telemetry connections are established over a NETCONF session through SSH to the active switch or a member in a switch stack, or the active route processor in a high-availability-capable device.
After switchover, you must destroy and re-establish all the sessions that use crypto, including NETCONF sessions that carry telemetry subscriptions. You must also re-create all the dynamic subscriptions after a switchover. gNMI dial-in subscriptions also work the same as a NETCONF session through SSH. gRPC dial-out subscriptions are configured on the device as part of the running configuration of the active switch or member of the stack. When switchover occurs, the existing connections to the telemetry receivers are torn down and reconnected (as long as there is still a route to the receiver). Subscriptions need not be reconfigured.
Model-Driven Telemetry High Availability in Telemetry Model-Driven Telemetry 41