A connection is instantiated as soon as it is requested. That is, as soon as the first subscription receiver goes from the resolving state to the transport requested state, a connection instance with the parameters that were resolved by the subscription receiver is created. If the requested connection is successfully setup and used by telemetry, the connection state changes to connected, which means that a connection exists between the Cisco IOS XE device and the receiver device. To reallocate the resources used by the receiver, the subscription receivers that want to use the resources are informed that the connection is set up.
These subscription receivers then transition to the connecting state to set up the resources required to connect the subscription to the receiver. Once these resources are in place, the subscription receiver’s state changes to connected, and update notifications are received by the receiver. The following are some of the reasons why a telemetry connection cannot become active: • Destination unreachable. • No listener at the remote host port. • Listener at the remote host port is of the wrong type. • Authentication failures.
When a connection setup is in progress, any subscription receiver using this connection is in the connecting state because it has successfully resolved the parameters needed to initiate the connection setup. Note The action taken when a connection setup fails is specific to the protocol. The following table shows the retry behaviors for connections within a single setup request and for re-resolution requests when the connection setup request fails. This behavior is the same for connections requested by the legacy receivers as well. Table 7:
Protocol-Specific Retry Intervals Troubleshooting Named Receiver Connections When a subscription is set up, one of the common problems is that no telemetry update messages are received. Possible reasons could be that there are no events to send, or the subscription is not valid. This section describes how to troubleshoot some of the common problems that occur in named receiver connections. The logs from the telemetry process, and the output of some of the show commands provide information that can be used for troubleshooting the named receiver configuration.
Model-Driven Telemetry Troubleshooting Named Receiver Connections Protocol Connection Retries Re-resolution Requests • grpc-tcp • grpc-tls 5 retries at 1, 3, 4, and 7 seconds in between them No limit; continuously requests re-resolution when connection retries fail. (14 seconds per try.) • cloud-native • cntp-tcp • cntp-tls • native • tls-native 5, 10, 15, 20, 25, and 30 seconds. Model-Driven Telemetry 27