Back
Lesson 5 of 6

Intent-Based Recommendations

Objective

In this lesson you will learn how to validate AI-generated, intent-based configuration recommendations by using telemetry visibility and impact analysis before applying changes. We will use telemetry outputs from a wireless controller to confirm the controller is sending the necessary data for AIOps recommendations, examine subscription state, and walk through the pre-change checks you must perform in production to avoid unintended consequences.

In production networks, intent-based recommendations rely on accurate telemetry—if telemetry is missing or incomplete, the recommendations can be wrong or dangerous. This lesson shows how to verify telemetry health and subscriptions so you can safely accept, modify, or reject an AI recommendation in environments such as wireless assurance, network monitoring, and automated remediation.

Quick Recap

Refer to the lab topology introduced in Lesson 1. This lesson does not add new devices; we will use the same wireless controller and the telemetry collector that were shown previously.

ASCII topology (controller to telemetry collector — exact IPs from the reference material):

[ POD4-C9800-CL1 ]-----------------[ Telemetry Collector ]
   hostname: POD4-C9800-CL1           Listening IP: 172.100.1.53
   Telemetry Source IP: 192.168.4.7   Collector Port: 25103

Note: The controller advertises telemetry over a configured source address of 192.168.4.7 and the collector is at 172.100.1.53 listening on port 25103, as shown in the reference outputs we'll use below.

Key Concepts

  • Telemetry subscription model — Telemetry uses a publisher/subscriber model where devices publish streaming data to a collector based on subscriptions. Think of subscriptions like signing up a device to send certain sensor channels to a monitoring service.
    • Protocol behavior: subscriptions are configured on the device; the device establishes a transport (TCP/gRPC) session to the collector and then streams telemetry samples.
  • Telemetry health matters for recommendations — AI systems generate recommendations based on observed telemetry. If subscriptions are invalid or connection state is down, the recommendation engine may lack data and give incorrect guidance.
    • Production impact: applying a recommended change without full telemetry visibility can break services or hide the real root cause.
  • Impact analysis before change — Before accepting a change, run a preflight impact analysis: confirm telemetry connectivity, confirm relevant subscription counts, and verify device state. This reduces risk.
    • Analogy: like checking the fuel gauge, weather, and runway conditions before taking off — you verify all inputs before committing to an action.
  • Troubleshooting telemetry failures — Common problems include certificate/firewall issues or missing telemetry configuration. The device state and subscription summary commands indicate these conditions.
    • Protocol detail: a connection may be "Active" but subscription counts could be zero if configurations are missing; conversely subscriptions may be configured but connection could be down due to network filter.

Step-by-step configuration

Step 1: Review telemetry connection state on the controller

What we are doing: We query the controller to see whether it has an active connection to the telemetry collector. This is the first preflight check because a live connection is necessary for the AI engine to receive the data that drives recommendations.

POD4-C9800-CL1# sh telemetry connection all
Telemetry connections

Index Peer Address           Port  VRF Source Address       State       State Description
----- ---------------------- ----- ---- --------------------  ----------  --------------------
109   172.100.1.53           25103 0    192.168.4.7           Active      Connection up

What just happened: The sh telemetry connection all command lists active telemetry transport sessions to configured collectors. The output shows a peer at 172.100.1.53 on port 25103 with source address 192.168.4.7 and state Active — Connection up. At the protocol level, this means the controller has established the transport session (e.g., gRPC/TCP) and is ready to transmit telemetry streams to the collector.

Real-world note: In production, an active connection demonstrates that the controller can deliver telemetry. If the state were anything other than Active, AIOps may be operating on stale or missing data.

Verify:

POD4-C9800-CL1# sh telemetry connection all
Telemetry connections

Index Peer Address           Port  VRF Source Address       State       State Description
----- ---------------------- ----- ---- --------------------  ----------  --------------------
109   172.100.1.53           25103 0    192.168.4.7           Active      Connection up

Step 2: Inspect telemetry subscription summary

What we are doing: We examine the device subscription counts to ensure the expected telemetry models are configured and valid. Subscription validity is required for the collector and AI engine to receive the correct data channels.

POD4-C9800-CL1# sh telemetry ietfsubscription summary
Subscription Summary
====================
Maximum supported: 128

Subscription   Total   Valid   Invalid
-----------------------------------------------
All            112     112     0
Dynamic        0       0       0
Configured     112     112     0
Permanent      0       0       0

Active–All good     Connecting –Cert/FW issue     N/A –Telemetry config missing

What just happened: The sh telemetry ietfsubscription summary command provides a summary of telemetry subscriptions and their validity. Here, 112 total subscriptions exist and all 112 are valid, indicating proper configuration. The text line explains common failure states: Connecting implies transport issues (certificate/firewall); N/A indicates missing telemetry configuration. A healthy subscription set ensures the AI engine sees the intended metrics, counters, and state.

Real-world note: A configured but invalid subscription can still appear as present; you must check both the subscription count and the connection state before trusting recommendations.

Verify:

POD4-C9800-CL1# sh telemetry ietfsubscription summary
Subscription Summary
====================
Maximum supported: 128

Subscription   Total   Valid   Invalid
-----------------------------------------------
All            112     112     0
Dynamic        0       0       0
Configured     112     112     0
Permanent      0       0       0

Active–All good     Connecting –Cert/FW issue     N/A –Telemetry config missing

Step 3: Force push telemetry configuration (GUI action) and re-check

What we are doing: Sometimes telemetry changes (new subscriptions or updated models) must be re-pushed from management. The reference shows a GUI flow to force-push telemetry settings. After forcing a push, re-verify subscription and connection state so the AI engine has fresh data before recommendations are evaluated.

  • Action (GUI): Inventory > Actions > Telemetry > Update Telemetry Settings
POD4-C9800-CL1# sh telemetry connection all
Telemetry connections

Index Peer Address           Port  VRF Source Address       State       State Description
----- ---------------------- ----- ---- --------------------  ----------  --------------------
109   172.100.1.53           25103 0    192.168.4.7           Active      Connection up

What just happened: The GUI action “Update Telemetry Settings” forces the management system to push the configured telemetry subscriptions and transport settings down to the device. After that push, sh telemetry connection all confirms the transport session is still active. For impact analysis, forcing a telemetry push refreshes what the AI engine sees and reduces the chance of recommendations being stale.

Real-world note: Force-pushing is useful when you have added new telemetry models (for example, new counters for Wi-Fi 7 MLO or new AP stats). In production, schedule pushes during maintenance windows if the device must temporarily reestablish flows.

Verify:

POD4-C9800-CL1# sh telemetry connection all
Telemetry connections

Index Peer Address           Port  VRF Source Address       State       State Description
----- ---------------------- ----- ---- --------------------  ----------  --------------------
109   172.100.1.53           25103 0    192.168.4.7           Active      Connection up

Step 4: Pre-change impact analysis using telemetry health

What we are doing: Before applying an AI recommendation (for example, a configuration change to RRM, AP power, or a remediation script), perform impact checks: confirm subscriptions are valid and the connection is stable, and document current counters so you can roll back if needed.

POD4-C9800-CL1# sh telemetry ietfsubscription summary
Subscription Summary
====================
Maximum supported: 128

Subscription   Total   Valid   Invalid
-----------------------------------------------
All            112     112     0
Dynamic        0       0       0
Configured     112     112     0
Permanent      0       0       0

Active–All good     Connecting –Cert/FW issue     N/A –Telemetry config missing

What just happened: Re-running the subscription summary gives you the current state: 112 valid subscriptions. For impact analysis you should note the counts and verify there are no Invalid subscriptions and no connection problems. If either were present, the recommendation might be based on incomplete data.

Real-world note: Treat this as a checklist item in your change control process. AI recommendations should be accompanied by proof that telemetry was complete at the time they were generated.

Verify:

POD4-C9800-CL1# sh telemetry ietfsubscription summary
Subscription Summary
====================
Maximum supported: 128

Subscription   Total   Valid   Invalid
-----------------------------------------------
All            112     112     0
Dynamic        0       0       0
Configured     112     112     0
Permanent      0       0       0

Active–All good     Connecting –Cert/FW issue     N/A –Telemetry config missing

Step 5: Post-change validation (after accepting a recommendation)

What we are doing: After you accept an AI recommendation and implement the change (for example via the management UI or CLI outside the scope of the reference), verify that telemetry still flows and that the subscription profile remains healthy. This ensures the remediation hasn't disrupted monitoring visibility.

POD4-C9800-CL1# sh telemetry connection all
Telemetry connections

Index Peer Address           Port  VRF Source Address       State       State Description
----- ---------------------- ----- ---- --------------------  ----------  --------------------
109   172.100.1.53           25103 0    192.168.4.7           Active      Connection up

POD4-C9800-CL1# sh telemetry ietfsubscription summary
Subscription Summary
====================
Maximum supported: 128

Subscription   Total   Valid   Invalid
-----------------------------------------------
All            112     112     0
Dynamic        0       0       0
Configured     112     112     0
Permanent      0       0       0

Active–All good     Connecting –Cert/FW issue     N/A –Telemetry config missing

What just happened: The two verification commands confirm the telemetry transport and subscriptions are intact post-change. If telemetry had dropped, AIOps would lose the feedback loop and could continue to make incorrect decisions. Post-change validation closes the loop on intent-based automation.

Real-world note: Always include telemetry verification in automated playbooks after making changes. This lets automation detect and roll back changes when monitoring visibility is lost.

Verification Checklist

  • Check 1: Telemetry transport is Active — verify with sh telemetry connection all and expect the peer 172.100.1.53 on port 25103 and source 192.168.4.7 to be Active — Connection up.
  • Check 2: Subscriptions are valid — verify with sh telemetry ietfsubscription summary and expect All 112 112 0 (112 total, 112 valid, 0 invalid).
  • Check 3: After applying a recommended change, re-run both sh telemetry connection all and sh telemetry ietfsubscription summary to ensure no disruption in telemetry flow.

Common Mistakes

SymptomCauseFix
Telemetry connection shows no peer or connection downFirewall or network path blocking port 25103; certificate or transport issueVerify network access to 172.100.1.53:25103 from 192.168.4.7; check collector accessibility and certificates; re-run sh telemetry connection all after fixes
Subscription counts show 0 or many invalid subscriptionsTelemetry config not pushed or incorrect models selectedForce push telemetry configuration from management: Inventory > Actions > Telemetry > Update Telemetry Settings; then verify with sh telemetry ietfsubscription summary
Recommendations appear stale or incorrectAI engine lacks recent telemetry due to intermittent connectionConfirm sh telemetry connection all is Active and re-push telemetry settings; ensure subscriptions are valid (sh telemetry ietfsubscription summary) before relying on recommendations
Post-change monitoring disappearsApplied change modified source/management interface or blocked telemetry portRevert change or update telemetry configuration to use new source/interface; verify connectivity with sh telemetry connection all

Key Takeaways

  • Always validate telemetry connectivity and subscription validity before accepting or applying AI-generated recommendations; telemetry is the data foundation of intent-based automation.
  • Use sh telemetry connection all to confirm the transport session (peer 172.100.1.53, port 25103, source 192.168.4.7) is Active — without this, the AI engine cannot receive live streams.
  • Use sh telemetry ietfsubscription summary to confirm configured subscriptions are valid (e.g., All 112 112 0). An invalid or missing subscription set means the AI engine may lack necessary telemetry channels.
  • Include telemetry verification in every pre-change and post-change checklist to reduce risk in production; force-pushing telemetry settings from management is an accepted remediation when configuration drift occurs.

Tip: Think of telemetry as the sensor network for your AI assistant — without reliable sensors, even a perfect recommendation is useless or dangerous. Always confirm your sensors are alive and calibrated before you act.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security