NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Objective

In this lesson you will enable and use Network-Wide Path Insights (NWPI) analytics in a Catalyst SD‑WAN environment to identify path performance bottlenecks and generate predictive path recommendations. This matters in production because application experience across multiple sites depends on choosing the best path (MPLS, Internet, private WAN) automatically — NWPI provides per-flow metadata and network telemetry so the SD‑WAN Controller can correlate end‑to‑end path quality and recommend changes. Real-world scenario: a retail enterprise with dozens of branches sees intermittent voice quality issues; NWPI lets operations pinpoint which hop or circuit causes jitter/loss and suggests the path to switch to.

Warning: This is an advanced lesson (CCNP Enterprise level). You must understand basic SD‑WAN architecture (vManage/controller, edge devices) from Lesson 1 before proceeding.

Quick Recap

Reference topology from Lesson 1 (no new physical devices are added in this lesson). You will reuse the same site IDs and device names defined previously. The lesson focuses on enabling NWPI metadata injection on the SD‑WAN edge and using SD‑WAN Manager analytics for path recommendations.

If you have not completed Lesson 1, stop and complete it first. NWPI operates by injecting metadata at the first hop and collecting correlated telemetry across the fabric — the fabric and controllers must already be configured.

Key Concepts — theory and practical implications

NWPI metadata injection: NWPI works by writing metadata into the SD‑WAN header on the ingress edge device. The header travels with the packet through the fabric; subsequent devices can read the metadata and feed correlated flow telemetry back to the SD‑WAN Manager. In production, this lets you map per-flow behavior across multiple divergent paths (Internet, MPLS).
Telemetry and flow correlation: SD‑WAN Manager ingests telemetry (loss, latency, jitter) and correlates it with application flow metadata. Practically, this is used to compare multiple transport paths for the same flow and determine which provides the best Quality of Experience (QoE).
Predictive Path Recommendations: Using historical telemetry and predictive modeling, the analytics engine suggests path changes (for example, move App Group X from load-balancing across private1 and private2 to only private2). In production, this powers closed-loop automation to improve application performance proactively.
Licensing and activation: NWPI and predictive recommendations depend on the appropriate analytics license (TE-EMBED-WANI as shown in the reference). Licensing must be present and activated before the analytics features can produce recommendations.
Packet flow behaviour: When enabled, the first router appends NWPI metadata into the SD‑WAN header. Routers send periodic telemetry to the SD‑WAN Manager. In production, telemetry intervals (sampling rate) affect detection sensitivity and volume — shorter intervals yield faster detection but greater overhead.

Topology (ASCII)

The topology below re-uses the site names and addresses from Lesson 1.

                            Internet
                              |
                              |
                         +----------+
                         |  Hub-Edge|
                         | 10.0.0.1 |
                         +----------+
                           /       \
                          /         \
                 MPLS    /           \   Internet
                172.16.0.0/30     192.168.100.0/30
                Branch1                Branch2
             +-----------+          +-----------+
             | BR1-Edge  |          | BR2-Edge  |
             | 10.1.1.1  |          | 10.1.2.1  |
             +-----------+          +-----------+

(Interface IPs shown on each edge device are the same identifiers used throughout this lab.)

Device Table

Device	Role	Management IP
Hub-Edge	Hub edge	10.0.0.1
BR1-Edge	Branch 1	10.1.1.1
BR2-Edge	Branch 2	10.1.2.1
SD‑WAN Manager	Controller	10.0.255.10

Use domain lab.nhprep.com and password Lab@123 for any authentication prompts in the SD‑WAN Manager GUI.

Step-by-step configuration

Each step shows the commands, what they do, why they matter, and a verification command with expected output.

Step 1: Verify licensing and analytic capability on SD‑WAN Manager

What we are doing: Confirm the TE‑EMBED‑WANI or equivalent analytics license is present and active on the SD‑WAN Manager. Predictive recommendations require the analytics license to be available. This prevents configuring NWPI without the required backend entitlement.

# Login to SD-WAN Manager (performed via the GUI in production; shown here as CLI verification commands)
show sdwan license

What just happened: The command queries the SD‑WAN Manager for installed licenses. If the TE-EMBED-WANI license is present and active, analytics and predictive features can be enabled. Without a valid analytics license, NWPI will not produce recommendations.

Real-world note: License availability is often managed by the procurement or cloud account team. Ensure the correct SKU is uploaded to avoid analytics degradation.

Verify:

show sdwan license
License Name: TE-EMBED-WANI
Status: Active
Expires On: Never
Feature: NWPI Analytics, Predictive Recommendations
Device Count: 250

Step 2: Enable NWPI metadata injection on the ingress edge device(s)

What we are doing: Configure the branch edge to inject NWPI metadata into SD‑WAN headers for flows originating at that device. This is the critical first action — without metadata injection, subsequent routers cannot correlate per‑flow traces.

configure terminal
sdwan
device BR1-Edge
nwpi enable
exit
exit

What just happened: The nested configuration places NWPI metadata injection on BR1-Edge. In effect, the edge will append a small NWPI metadata block into the SD‑WAN header for selected flows so intermediate devices and the controller can correlate telemetry. This changes packet processing on the ingress: header composition is extended to include metadata fields (site-id, flow-id, trace-id).

Real-world note: Enabling metadata injection is lightweight but should be planned during change windows for high-scale sites to monitor telemetry volume effects.

Verify:

show sdwan device BR1-Edge nwpi status
Device: BR1-Edge
NWPI Metadata Injection: Enabled
Last Update: 2025-03-10 09:15:02 UTC
Flows Injected: 42
Trace Sessions Active: 2

Step 3: Create an NWPI trace between two sites (generate a network trace)

What we are doing: Instruct the SD‑WAN Manager to create a trace (a telemetry session) between two edge devices so path metrics (loss, latency, jitter) are measured and correlated. Generating a trace produces data for predictive modeling.

# Performed from SD-WAN Manager control plane (vManage). CLI-like invocation for illustration:
create nwpi trace source BR1-Edge destination Hub-Edge application-group "Office 365" duration 600

What just happened: The controller triggered a trace session where the BR1-Edge writes NWPI metadata for flows to Hub-Edge. Intermediate routers record telemetry for the trace and forward it to SD‑WAN Manager. The manager correlates per-hop metrics over the trace duration and stores them for analysis.

Real-world note: Traces can be scheduled during low-traffic periods if you are concerned about extra telemetry overhead; for time-sensitive issues, run shorter traces more frequently.

Verify:

show nwpi traces
Trace ID: NWPI-0001
Source: BR1-Edge (10.1.1.1)
Destination: Hub-Edge (10.0.0.1)
Application Group: Office 365
Start Time: 2025-03-10 09:20:00 UTC
Duration: 600 seconds
Status: Running

Step 4: View predictive path recommendations in SD‑WAN Manager

What we are doing: Query the analytics engine for predictive recommendations based on collected NWPI telemetry. This translates path metrics into actionable guidance (for example, prefer private2 over private1). Seeing the recommendation is the precursor to automated policy changes.

show nwpi recommendations trace NWPI-0001

What just happened: The controller analyzed the trace telemetry and applied predictive modeling to suggest path changes for the specified application group. It outputs a human-readable recommendation, including expected % gain and the suggested path (e.g., private2 only) versus current behavior (e.g., load-balance between private1/private2).

Real-world note: Always review recommendations before applying. Closed-loop automation can apply changes automatically, but you should validate impact and scheduling for production-critical flows.

Verify:

show nwpi recommendations trace NWPI-0001
Trace ID: NWPI-0001
Analyzed Paths: private1, private2, internet
Recommendation Summary:
 - Application Group: Office 365
 - Current Policy: AAR sequence uses load-balancing across private1 & private2
 - Recommended Change: Use private2 exclusively
 - Expected Path Quality Gain: 18% (predicted reduction in packet loss and jitter)
 - Confidence: High
 - Generated On: 2025-03-10 09:34:00 UTC

Step 5: Apply recommendation via closed-loop automation (create a copy of the AAR policy and apply)

What we are doing: Use the controller to create a copy of the existing Application Aware Routing (AAR) policy, modify its sequence to implement the recommendation for the affected site(s), and apply the policy. This demonstrates the closed-loop workflow described in the architecture.

# CLI-like sequence to create and apply policy; in practice performed in SD-WAN Manager GUI workflow
create aar policy copy "AAR-Office365" from "AAR-Central" new-policy "AAR-Office365-Rec"
modify aar policy "AAR-Office365-Rec" site-list add-site BR1-Edge sequence for AppGroup "Office 365" prefer-path private2
apply aar policy "AAR-Office365-Rec" site BR1-Edge

What just happened: The controller cloned the existing centralized AAR policy, created a per-site variant that implements the recommendation (prefer private2), and applied it to BR1-Edge. According to the documented behavior, if the centralized policy is later changed, the system may revert recommendations — you must manage central policy changes carefully.

Real-world note: Closed-loop changes are powerful but must be accompanied by audit trails and rollback plans. Central policy changes can trigger automated reverts.

Verify:

show aar policy name AAR-Office365-Rec
Policy Name: AAR-Office365-Rec
Derived From: AAR-Central
Applied To: BR1-Edge (10.1.1.1)
Application Group: Office 365
Sequence:
  1) Match: Office 365
     Action: Prefer private2
     Status: Active
Last Applied: 2025-03-10 09:40:12 UTC

Step 6: Validate application QoE and review historical trends

What we are doing: After applying the policy, inspect NWPI analytics for the impact: check the path metrics and confirm predicted gains materialized. Historical trends and daily/weekly aggregates help validate improvement and detect regressions.

show nwpi path-stats source BR1-Edge destination Hub-Edge application-group "Office 365" period 3600

What just happened: The command requests aggregated path statistics for the last hour. You should see improved metrics for the now-preferred path (private2) compared to the previous multi-path distribution if the recommendation was correct.

Real-world note: Allow sufficient time after policy changes for stable metrics to accumulate before declaring success.

Verify:

show nwpi path-stats source BR1-Edge destination Hub-Edge application-group "Office 365" period 3600
Source: BR1-Edge (10.1.1.1)
Destination: Hub-Edge (10.0.0.1)
Application Group: Office 365
Period: Last 3600 seconds
Path: private2
  Avg Latency: 24 ms
  Avg Loss: 0.6 %
  Avg Jitter: 3 ms
  Observations: Stable
Path: private1
  Avg Latency: 40 ms
  Avg Loss: 2.8 %
  Avg Jitter: 8 ms
  Observations: Degraded
Path Quality Improvement (private2 vs prior mixed): 19%

Verification Checklist

Check 1: NWPI metadata injection enabled on ingress edge(s)
- Verify with: show sdwan device BR1-Edge nwpi status — should show "NWPI Metadata Injection: Enabled"
Check 2: Trace session ran and analytics produced a recommendation
- Verify with: show nwpi traces and show nwpi recommendations trace <TraceID> — trace status must be Running/Completed and recommendation present
Check 3: AAR policy copy was applied to the site and traffic moved to recommended path
- Verify with: show aar policy name <policy> and show nwpi path-stats ... — the policy should be applied and preferred path metrics should show improvement
Check 4: Historical metrics confirm the expected gain
- Verify with: show nwpi path-stats source BR1-Edge destination Hub-Edge application-group "Office 365" period 3600 — expected numeric improvement in loss/jitter/latency

Common Mistakes

Symptom	Cause	Fix
No recommendations appear after running a trace	Analytics license (TE-EMBED-WANI) absent or inactive	Verify license with `show sdwan license`; upload/activate required license
Trace shows "No telemetry" or zero flows injected	NWPI metadata injection not enabled on ingress edge	Enable with `device <name> nwpi enable` and re-run trace
Applied recommendation reverts unexpectedly	Centralized AAR policy was modified after closed-loop application (system reverts recommendations)	Coordinate central policy changes; re-apply recommended policies after changes or use the bulk re-apply workflow
Metrics show no improvement after applying recommendation	Recommendation may have low confidence or transient conditions caused the initial detection	Re-run traces at different times; validate across multiple samples before permanent change

Key Takeaways

NWPI provides correlated per-flow metadata and telemetry so SD‑WAN Manager can analyze end‑to‑end path quality — this is essential for diagnosing cross-domain (MPLS/Internet/private) issues.
The NWPI workflow requires: an active analytics license, NWPI metadata injection on ingress edges, trace generation, recommendation review, and careful application of AAR policy changes.
Predictive path recommendations can improve QoE proactively, but closed-loop automation must be controlled with rollback/audit processes to avoid unintended policy churn.
In production, always validate analytics recommendations with repeated traces and historical aggregates before making permanent central policy changes.

Tip: Treat NWPI recommendations as operational guidance — use them to prioritize troubleshooting and to automate changes only when proper validation and governance are in place.

If you completed this lesson, proceed to Lesson 3 to practice multi‑site comparisons and automate bulk recommendation re-application across multiple branches (we will demonstrate scheduling and policy reversion safeguards).