LSP Visualization#

1. Objective#

Managing SR-TE and MPLS tunnels across a multi-router network is one of those tasks that looks simple until you are doing it at scale. How many LSPs are active right now? Which path does each one take? Is that path still optimal after a link went down last night? In a traditional CLI workflow, answering any of those questions means opening device sessions one by one and piecing together the picture yourself.

This activity shows you a better way. You will use NSP as a single pane of glass to discover and visualize LSPs across the topology, define Path Profiles to control how the PCE optimizes your tunnels, and provision a new PCC-initiated LSP, all without touching a single CLI session. By the end, you will have a clear picture of how centralized visibility and policy-driven path control can reduce the time and risk involved in day-to-day LSP operations.

2. Technology explanation#

2.1 PCE, PCC, and PCEP#

In a PCE-based network, path computation is split between two roles:

• PCE (Path Computation Element) — a centralized controller (NSP in this case) that computes optimal paths based on topology, constraints, and optimization objectives. The PCE has a global view of the network that no single router possesses.

• PCC (Path Computation Client) — a router (such as PE1) that delegates path computation to the PCE. The PCC signals and maintains the LSP, but relies on the PCE to decide where it goes.

PCEP (Path Computation Element Communication Protocol) is the protocol that carries messages between PCC and PCE. Through PCEP, a PCC can request a path, receive a computed route, and hand over ongoing control of that LSP to the PCE — a mode called delegation. This delegation is what makes dynamic re-optimization possible: when topology changes (a link fails, latency spikes), the PCE can push a new path to the PCC without any manual intervention.

2.2 Path Profiles#

Path Profiles in NSP Path Control allow you to define how the PCE (Path Computation Element) or PCC (Path Computation Client) optimizes LSPs — controlling objectives, constraints, bandwidth strategies, and protection. Once created, a Path Profile can be referenced by any LSP to enforce consistent computation behavior.

2.3 Model-Driven Configurator (MDC)#

MDC allows you to directly push YANG-modeled configuration to a device through the NSP WebUI without writing any code.

3. Tasks#

You should read these tasks from top to bottom before beginning the activity.

It is tempting to skip ahead, but tasks may require you to have completed previous tasks before tackling them.

3.1 Quick start on NSP Web UI#

3.2 Locate and Inspect Active LSPs#

Now let's find the LSPs running in the network.

1. Navigate to Path Control.
2. What information can you extract from this menu?
3. Navigate to the LSPs menu from the dropdown.
4. Review the list of LSPs currently visible:
   • How many LSPs are active?
   • What are their source and destination nodes?
   • What is the operational state of each LSP?
5. Select one LSP and open its detail view. Take note of:
6. The actual hop-by-hop path through the network
7. The bandwidth reservation (if available)
8. The operational state (up, down, degraded)
9. Try to identify whether the LSP is using a primary or secondary path.

3.3 Query LSP Data via REST API#

NSP exposes LSP operational data through its REST API. Let's query it directly.

Authenticate against the NSP API using curl:

curl -k -X POST https://{{server}}/rest-gateway/rest/api/v1/auth/token \
  -H "Content-Type: application/json" \
  --user "pathcontrol:$EVENT_PASSWORD" \
  -d ‘{"grant_type": "client_credentials"}’

Query the list of LSPs using the NSP REST API. Use Postman or the NSP WebUI API explorer rather than curl for this step, as the response is easier to navigate interactively.

curl -X GET "https://{{server}}/sdn/api/v4/mpls/lsps"
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Accept: application/json"

///

Explore the response structure and look for:

• LSP name and identifier
• Ingress and egress node
• Path hops
• Operational state fields

3.4 Create a Path Profile in NSP#

Navigate to Path Control → Path Profiles (dropdown), then New Profile (top right).

Configure the Path Profile using the parameters below. Not all fields are mandatory. Focus on the highlighted ones for this activity.

Once you have filled in the parameters, click Save and verify that the new Path Profile appears in the list.

3.5 Provision a PCC-Initiated LSP#

Now that you have a Path Profile, create a PCC-initiated SR-TE LSP on PE1 and attach it to the profile you just created. Use MDC (Model Driven Configurator) as shown below.

1. Navigate to Model Driven Configurator and select PE1 as the target device.
2. Navigate to the configuration tree: configure > router > Base > mpls > lsp.
3. Click Create LSP and fill in the following fields:

1. Under the LSP, add a primary path with the following settings:

1. Also add a path-profile entry:

1. Click Deploy and verify the configuration was applied successfully on PE1.

3.6 Play, Reflect, and Share Observations#

This final task combines a hands-on exploration exercise with a team discussion and note-taking activity. There are no right or wrong answers — your insights and observations are the goal.

3.6.1 Part 1 — Free exploration: try to break things#

Now that you have a solid understanding of LSPs and Path Profiles, it is time to experiment freely. Push the network to its limits and observe how NSP responds.

Here are some ideas to get you started:

• Change the optimization objective of an existing LSP and observe whether it gets rerouted
• Shut down a port along an active LSP path and see how the network reacts
• Modify a Path Profile shared by multiple LSPs and observe the impact
• Create conflicting LSPs with competing optimization objectives and see what happens
• Remove a link along an active LSP path and observe the ripple effect

3.6.2 Part 2 — Team Discussion#

As a team, discuss and document your answers to the following.

LSP visibility

• Was the LSP information in NSP complete and accurate compared to what you expected?
• How easy was it to trace an LSP end-to-end through the topology?
• Did your newly created LSP appear correctly on the topology map?

Path Profiles

• How does using a Path Profile change the way you think about LSP provisioning at scale?
• What would happen if two LSPs with conflicting optimization objectives shared the same Path Profile?

4. Summary#

Congratulations! In this activity you explored how NSP surfaces, controls, and provisions LSP data across a network topology. Key takeaways include:

• Centralized visibility matters — NSP eliminates the need to SSH into individual nodes to understand LSP state, dramatically reducing the time to answer basic operational questions.
• Path Profiles unlock consistency — By decoupling optimization policy from individual LSP configuration, Path Profiles allow network teams to enforce consistent computation behavior across hundreds of LSPs without touching each one individually.
• PCE delegation is powerful — Handing path computation to the PCE with pce-control: true means the network can react dynamically to topology changes, without requiring manual re-provisioning.
• Topology context is key — Seeing an LSP highlighted on a topology map immediately reveals dependencies and potential failure impact in a way that raw CLI output cannot.