Home
Support
Product Support
Cloud and Systems Management
Cisco Crosswork Network Automation
End-User Guides

Cisco Crosswork Network Controller 7.2 Traffic Engineering and Optimization

How are orphaned SR-TE policies and RSVP-TE tunnels managed after HA switchover?
How does Crosswork handle visualization and provisioning of SR-TE policies?
What are the limitations for provisioning Flexible Algorithm SR-TE policies?

View all Saved Content

PDF

Is this content helpful?

Helpful Unhelpful

Suggestions for Improvement

Thank you for your feedback. Your response has been recorded.

Ask about this content

Cisco Crosswork Network Controller 7.2 Traffic Engineering and Optimization

How are orphaned SR-TE policies and RSVP-TE tunnels managed after HA switchover?
How does Crosswork handle visualization and provisioning of SR-TE policies?
What are the limitations for provisioning Flexible Algorithm SR-TE policies?

Expand all sections

About this content

Traffic Engineering in Cisco Crosswork Network Controller

Traffic Engineering in Cisco Crosswork Network Controller
Supported SR-TE policies and RSVP tunnels
What is segment routing?
Segment routing path computation element
SR-TE policy PCC and PCE configuration sources
Resource reservation protocol
RSVP-TE tunnel PCC and PCE configuration sources
Sample policy and device configurations
The Traffic Engineering dashboard
View TE event and utilization history
View TE device details
Receive traffic engineering notifications
Configure TE settings
Resolve orphaned SR-TE policies and RSVP-TE tunnels

SR-MPLS and SRv6

SR-MPLS and SRv6
SR-MPLS and SRv6 policies on the topology map
View SR-MPLS and SRv6 policy details
View IGP path and metrics
Find Multiple Candidate Paths (MCPs)
View underlying paths associated with a Binding-Segment ID (B-SID) label
SR policies with multiple segment lists
Native SR paths
Configure TE link affinities
Policy deployment considerations
Create explicit SR-MPLS policies
Create dynamic SR-MPLS policies based on optimization intent
Create SR-TE policies (PCC-initiated)
Modify SR-MPLS policies
Create an ODN template

Resource Reservation Protocol (RSVP)

Resource Reservation Protocol
RSVP-TE tunnels on the topology map

Flexible Algorithm

Flexible algorithm
Supported Flexible Algorithm metrics and constraints
Configure flexible algorithm affinities
Visualize flexible algorithm topologies
Validating routing intent with path analytics
View flexible algorithm details
Configure and visualize flexible algorithm SRLG exclusion

Tree Segment Identifier Multicast Traffic Engineering

Tree Segment Identifier
View point-to-multipoint trees on the topology map
Create static Tree-SID policies
Modify a Tree-SID policy
Tree-SID important considerations

Deterministic Demand Matrix

Demand matrix
DDM device and configuration requirements
Manage demand matrix domains
Locator counter collection coverage
Locator counter collection synchronization

Path analytics service assurance

Path analytics and service assurance

Cisco Crosswork Network Controller 7.2 Traffic Engineering and Optimization

View IGP path and metrics

Updated: August 4, 2025

Want to summarize with AI?

Learn how to view IGP paths and their associated metrics for SR-MPLS or SRv6 policies.

View the physical path and metrics between the endpoints of the selected SR-MPLS policies.

Procedure

	1.	In the SR policy table, select the SR-TE (SR-MPLS and SRv6) policies that interest you.
	2.	Select the Show IGP path check box to view metrics. The IGP paths for the selected SR-MPLS policies appear as straight lines instead of segment hops.
	3.	In a dual-stack topology, select the Participating only checkbox to view metrics on participating links.
	4.	Click and then click Metrics tab.
	5.	Toggle applicable metrics to ON. Figure 1. View physical path and metrics

Need help?

Open a support case

(Requires a Cisco Service Contract)

Bias-free language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.