Bandwidth and Network Optimization

This section explains the following topics:

Overview

Objective

Network operators need a toolset to help automate bandwidth optimization, steer traffic with little operator intervention, and ensure that critical links always have sufficient bandwidth to avoid congestion.

Challenge

For service providers, managing bandwidth problems used to be a reactive and manual process. Pressure to solve it is huge. Network congestion leads to poor end-customer experiences. Congested links, high latency, and other network impairments lead to a poor perception of the services carried across your network or result in an inability to meet the service level agreements (SLAs) you have with your customers. In the worst-case scenario, your network issues lead to SLA or contract violations and the loss of your brand equity.

Solution

Using Local Congestion Mitigation (LCM) and Circuit Style policies, service providers can now specify business-critical links with the intention of reserving bandwidth for these links. Identifying critical links and the operator's intention enables automatic optimization of the network in real-time.

Crosswork Network Controller offers both:

  • LCM is a tactical solution for bandwidth management and congestion mitigation. It is best applied when attempting to solve congestion issues directly, on the devices themselves, without a full-scale traffic matrix or advanced planning.

  • Circuit-Style Segment Routing (CS-SR) is a strategic traffic engineering solution that permits you to reserve bandwidth in advance for critical links, avoiding congestion issues entirely for these high-priority links.

Local Congestion Mitigation

Instead of optimizing for bandwidth resources in the network by rerouting traffic in the entire network (end-to-end path optimization), LCM checks the capacity locally, in and around the congested area, at an interface level and reroutes traffic between the endpoints of the congested interface (local interface-level optimization). Focusing on an issue locally eliminates the need for simulating edge-to-edge traffic flows in the network through a full traffic matrix, which is both cumbersome and less scalable as node counts continue to increase.

When congestion is detected in the network, LCM provides recommendations to divert the minimum amount of traffic away from the congested interface. LCM collects the SR-TE policy and interface counters through SNMP. It estimates the amount of traffic that may be diverted and, if the user approves, performs the mitigation through the deployment of Tactical Traffic Engineering (TTE) SR-TE policies. Mitigating congestion locally does not require the use of the full Segment Routing Traffic Matrix (SR-TM). TTE SR-TE policies are created at the device on only either side of the congested link, with the shortest paths possible that do not congest interfaces elsewhere.

How does LCM work?

  1. First, network operators create domains that define "local" portions of the network. A domain can be the entire network, but more commonly, it matches one or more geographical areas or groups of device interfaces. In this example, we have defined a domain with four devices and all their interfaces. We also assume that all the links in this domain are 1Gpbs.

  2. Operator specifies a threshold defining what "congestion" means for a particular domain. In this example, the operator has set the domain's congestion threshold to 70%. The congestion threshold you decide on may vary. For guidance on how to determine what congestion threshold is best for your network and its domain architecture, see Cisco's Local Congestion Mitigation (LCM) White Paper.

  3. LCM first analyzes the Optimization Engine Model (a real-time representation of the physical network, topology, and traffic) on a regular cadence. After a congestion check interval, LCM detects congestion when Node 2 utilization goes above the 70% utilization threshold.

    Figure 1. How does LCM work?
    How Does LCM Work?

  4. LCM calculates how much traffic is eligible to divert. LCM will follow these rules and restrictions in its recommendations:

    LCM only diverts traffic that is not already routed by an existing SR policy (for example, unlabeled, IGP-routed, or carried via FlexAlgo-0 SIDs). Traffic within an SR policy will not be included in the LCM calculation and will continue to travel over the original programmed path.

    LCM computes diversion-eligible traffic by taking the interface traffic statistics for all traffic on the interface and subtracting the sum of traffic statistics for all SR-TE policies that flow over the interface.

    Total interface traffic – SR policy traffic = Eligible traffic that can be optimized

    This process must account for any ECMP splitting of SR policies to ensure the proper accounting of SR policy traffic. In this example, the total traffic on congested Node 2 is 800 Mbps and the total traffic of all SR policies routed over Node 2 is 500 Mbps.

    The total traffic that LCM can divert in this example is 240 Mbps. That is, 800 Mbps – 560 Mbps = 240 Mbps

  5. LCM calculates the amount of traffic that must be sent over alternate paths by subtracting the threshold-equivalent traffic from the total traffic on the interface. In this example, the amount to be diverted is 100 Mbps:

    800 Mbps – 640 Mbps (70% threshold) = 100 Mbps

    LCM must route 100 Mbps of 300 Mbps (eligible traffic) to another path.

  6. LCM determines the number of TTE SR policies are needed and their paths. The ratio of how much LCM eligible traffic can stay on the shortest path to the amount that must be rerouted, will determine the number of TTE SR policies needed on the shortest and alternate paths, respectively.

    In this example, LCM must divert one-third of the total eligible traffic (100 Mbps out of 300 Mbps) away from the congested link. Assuming a perfect ECMP, LCM estimates three tactical SR-TE policies are required to create this traffic split: one tactical SR-TE policy will take the diversion path, and two tactical SR-TE policies will take the original path. There is sufficient capacity in the path between Node 2 and Node 4. Therefore, LCM recommends three TTE SR policies (each expected to route approximately 100 Mbps) to be deployed from Node 2 to Node 3 via SR-PCE:

    • 2 TTE SR policies to take a direct path to Node 3 (200 Mbps)

    • 1 TTE SR policy takes a path via Node 4 (100 Mbps)

    These recommendations will be listed in the LCM Operational Dashboard.

Figure 2. Recommended policies on the LCM operational dashboard
Recommended Policies on the LCM Operational Dashboard

Assuming you deploy these TTE SR policies, LCM continues to monitor the deployed TTE policies and will recommend modifications or deletions as needed in the LCM Operational Dashboard. TTE SR policy removal recommendations will occur if the mitigated interface is not congested if these policies are removed (minus a hold margin). This helps to avoid unnecessary TTE SR policy churn throughout the LCM operation.

Circuit-Style policies

Circuit-Style Segment Routing Policies (CS-SR or CS policies) are connection-oriented transport services that you can use to implement what are sometimes referred to as "circuit emulations" or "private lines". Combining segment-routing architecture's adjacency SIDs with stateful PCEP path computation, CS policies provide:

  • Persistent, dedicated, bi-directional, co-routed transport paths with predictable latencies and other performance metrics in both directions.

  • Guaranteed bandwidth commitments for traffic-engineered services using these paths.

  • End-to-end path protection to ensure there is no impact on Service Level Agreements.

  • Automatic monitoring, maintenance, and restoration of path integrity.

  • Flexible operations, administration, and management of CS paths.

  • A software-defined replacement for older CEM infrastructure, such as SONET/SDH.

How do Circuit-Style policies work?

The initial configuration of CS policies follows these steps:

  1. Crosswork Network Controller and its applications discover and map the network topology.

  2. Crosswork Network Controller users enable CS policy support, specifying the base bandwidth to be allocated to CS policies as a whole and a threshold percentage of bandwidth usage that will generate an alarm when exceeded on any CS-calculated path. So, for example, on a 1 GB link with 20 percent of bandwidth reserved for CS use, CS policies can use up to 200 Mbps of that link. Note, however, that if the bandwidth minimum threshold is set to the default of 80 percent, alarms will be generated as soon as 160 Mbps of the link is used.

  3. Network operators create a CS policy for each set of nodes for which they want to establish a guaranteed path. The policy specifies the two nodes to be linked by the main path, the bandwidth to be reserved, and the backup path. To accommodate bandwidth and path failures, the configuration must include bi-directionality, path protection, and performance-management liveness-detection settings.

  4. When the operator commits the CS policy, the device-resident Path Computation Client (PCC) will request the Crosswork-resident PCE server to compute candidate Working and Protected paths that conform to the CS policy's bandwidth and other constraints (using a single PCEP request message).

  5. When CS policy support is enabled, the PCC computes both paths and deducts their CS policy-guaranteed bandwidth from the allocated available bandwidth.

  6. Crosswork Network Controller replies to the PCC with the primary Working and Protected path lists and commits to, or "delegates," them. The topology map displays the current Active and Protected paths between the two nodes, using the colors configured when the CS policy was configured, and labels the two endpoint nodes so they can be identified as CS policy endpoints.

After the initial configuration:

  1. Crosswork Network Controller monitors the delegated path and the active CS policies. It updates the available and reservable bandwidth in the network in near real-time.

  2. Crosswork Network Controller generates threshold-crossing alarms when bandwidth usage or additional CS policy requirements exceed the configured reserved bandwidth or bandwidth usage threshold.

  3. If delegated paths fail for any reason, Crosswork Network Controller recomputes paths as needed.

Scenario: Use LCM to reroute traffic on an overused link

In this scenario, we will enable Local Congestion Mitigation (LCM) and observe its congestion mitigation recommendations. LCM will recommend that we deploy Tactical Traffic Engineering Segment Routing (TTE SR) policies on a device’s interfaces when usage exceeds a defined threshold. We will preview the recommended TTE SR policies before committing them.

This example uses the following topology:
Figure 3. Initial utilization

Initial Utilization

Note

If you are viewing the HTML version of this guide, click on the images to view them in full-size.

We will enable LCM with a configuration that results in the link between cw-xrv54 and cw-xrv55 becoming over-used. We will then review the mitigation solutions Crosswork Network Controller calculates. In this example, the operator decides whether to apply the solution.

Assumptions and prerequisites

The following sections list high-level requirements that must be met to ensure proper LCM operation.

Congestion evaluation requirements

LCM requires traffic statistics from the following:

  • Interface traffic measurements

  • Headend SR-TE policy traffic measurements

To ensure LCM is receiving these traffic statistics:

  • Enable SNMP on the devices whose traffic you want to monitor, including the headend device. For more on this task, see Configuring SNMP support. Note that gNMI is also an option for collecting traffic measurements.

  • Ensure that the SNMP-enabled devices are all reachable from the Data Gateway. For more on this task, see Check connectivity to the destination.

  • Configure the headend device to use strict SID labels for SR policies. To perform this task:

    1. Enable segment routing on the headend device and configure the segment routing global block (SRGB) and the segment routing local block (SRLB) ranges. For example:
      segment-routing
 mpls
  global-block 16000 23999
  node-msd 16
 !
 srlb 15000 15999
    2. Configure the SR policy candidate paths to use strict SID labels. You can use either explicit paths or dynamic paths with constraints. For example:
      segment-routing
 traffic-eng
  policy COLOR-100-TO-10.0.0.1
   color 100 end-point ipv4 10.0.0.1
   candidate-paths
    preference 100
     explicit segment-list SL1
    !
    preference 200
     dynamic
      constraints
       affinity include-any RED BLUE
       sid-algorithm strict-spf
      !
     !
    !
   !
  !
 !
!
segment-list SL1
 index 10 mpls label 16001 node 10.0.0.2 strict
 index 20 mpls label 16002 node 10.0.0.3 strict
 index 30 mpls label 16003 node 10.0.0.4 strict
!
    3. Configure the SR policy headend behavior using the binding SID and the autoroute announce option. For example:
      
!segment-routing
traffic-eng
pcc
profile 1
autoroute
include ipv4 all
force-sr-include
!
!
!
!

Congestion mitigation requirements

The headend device must support PCE-initiated SR-TE policies with autoroute steering. However, LCM will not work if the headend is a Cisco NCS device with L2VPN traffic in the network.

Devices should be configured with force-sr-include to enable traffic steering into SR-TE policies with autoroute. For example: 
segment-routing traffic-eng pcc profile ID autoroute force-sr-include

The ID parameter in this command identifies the PCC profile associated with the SR-TE policy that PCE has provisioned. The ID value can be any integer from 1 to 65535, but it must match the profile ID that PCE uses to instantiate the policy. If not, the policy will not be activated. For example, suppose PCE provisions a policy with profile ID 10. In that case, you must configure segment-routing traffic-eng pcc profile 10 autoroute force-sr-include on the headend router to enable autoroute announcement for that policy. For more information, see the Segment Routing Configuration Guide, Cisco IOS XE 17 (Cisco ASR 920 Series), COE-PCE Initiated SR Policy with OSPF and IS-IS SR-TE Autoroute Announce.


Note

The ID that is configured under the PCC profile, must match the Profile ID option set in the LCM Configuration page.

The headend device must support Equal Cost Multi-Path (ECMP) across multiple parallel SR-TE policies. To verify that a device can support SR-TE policies using ECMP, check that the device has the following:

  • Segment Routing is enabled and configured with a Segment Routing Global Block (SRGB) that matches the SRGB of the SR-TE policy headend and tailend routers. Use the show segment-routing mpls state command to verify the SRGB configuration on the device.

  • BGP-LS is enabled and configured to advertise and receive link-state information from the SR-TE policy headend and tailend routers. Use the show bgp link-state link-state command to verify the BGP-LS status and the show bgp link-state link-state database command to verify the link-state information on the device.

  • ECMP is enabled and configured to load-balance traffic across multiple equal-cost paths based on flows. Use the show ip route command to verify the ECMP routes and the show ip cef command to verify the ECMP load-balancing algorithm on the device.

If all these conditions are met, then the device can support an SR-TE policy using ECMP.

Related topics

For more information and examples on how to configure and verify SR-TE policies, see:

Step 1: Enable LCM and configure the utilization thresholds

In this step, enable LCM and configure the global utilization threshold.

Procedure

Step 1

From the main menu, choose Services & Traffic Engineering > Local Congestion Mitigation > Domain-ID and click Configure.

Step 2

Toggle the Enable switch to True, and enter the global utilization threshold you want to set. In this case, we set the threshold at 80%, and select the Interfaces to monitor > All interfaces option. To see information about other options for each configuration setting, hover the mouse over i (help icon).

Figure 4. Basic LCM configuration

Basic LCM Configuration

Step 3

Click Commit changes.

Note

 

After committing the configuration changes, LCM will display recommendations on the LCM Operational Dashboard if congestion occurs on any monitored interfaces. LCM will not commit or deploy new TTE policies automatically. Later, you will be able to preview the recommended TTE policies and decide whether or not to commit and deploy them onto your network.

Step 4

You can also define individual interface thresholds. Go to the Interface Thresholds page (Traffic Engineering > Local Congestion Mitigation > Domain-id > > Interface thresholds). You can add interfaces individually or upload a CSV file with a list of nodes and interfaces with custom utilization thresholds. For more information, see Add individual interface thresholds.

See the following example and note the defined threshold for cw-xrv54 with interface GigabitEthernet0/0/0/1 is 20%.

Note

 

The utilization thresholds in this example are extremely low and best used for lab environments.
Figure 5. Customized interface thresholds
Customized Interface Thresholds

Step 2: View link congestion on the map

The link between cw-xrv60 and cw-xrv62 is now congested.

Procedure

Step 1

From the main menu, choose Services & Traffic Engineering > Traffic Engineering.

Step 2

Click on the link to view link details, including utilization information. Usage has surpassed the custom LCM threshold defined at 20% for node cw-xrv54 with interface GigabitEthernet0/0/0/5.

Figure 6. Link congestion on the map
Link Congestion on the Map

Step 3: View TTE SR policy recommendations in the LCM operational dashboard

LCM has detected the congestion and computed tactical policies to mitigate it. We can preview these policies and then decide whether or not to commit them.

In this scenario, the congested device is healthy, reachable, and in sync with Crosswork Network Controller. The actions we take and policies we implement will be different if, in addition to congestion, the device is down, unreachable, or out of sync.

Procedure

Step 1

From the main menu, choose Services & Traffic Engineering > Local Congestion Mitigation.

When congestion is detected, the domain displays the urgency type and recommendations that are available. Click the question mark icons to display more information about the urgency type and when the most recent recommendation was given.

Figure 7. Congested detected and LCM recommendations
Congested Detected and LCM Recommendations

Step 2

Open the Operational Dashboard (Services & Traffic Engineering > Local Congestion Mitigation > Domain-ID > ... > Operational Dashboard).

The dashboard shows that cw-xrv54 utilization has surpassed 20% and is now at 29.46%. In the Recommended Action column, LCM recommends the deployment of TTE policy solution sets (Recommended action - Create set) to address the congestion on the interface.

Step 3

Before committing TTE policies, you can preview the deployment of each TTE policy solution set. Click in the Actions column and choose Preview solution.

Figure 8. Operational dashboard - preview solution
Operational Dashboard - Preview Solution

The resulting window displays the node, interface, and the recommended action for each TTE policy. From the Preview window, you can select the individual TTE policies and view different aspects and information as you would normally on the topology map. You can expand each policy to view individual segments. After reviewing the potential implications on your network, you can decide whether or not to deploy the bypass policies that LCM recommends.

The following figure shows the recommended TTE policies for node cw-xrv54.

Figure 9. Preview recommended TTE policies
Preview Recommended TTE Policies

Step 4

After you are done viewing the recommended TTE policies on the map, go back to the Operational dashboard and click Commit All. The LCM State column changes to Mitigating.

All LCM recommendations per domain must be committed to mitigate congestion and produce the expected utilization, as shown in the Operational dashboard. The mitigating solution is based on all LCM recommendations being committed because of dependencies between solution sets.

Figure 10. Operational dashboard
Operational Dashboard

Step 4: Validate TTE SR policy deployment

To validate the TTE SR policy deployment, follow the steps given below:

Procedure

Step 1

With the Operational dashboard displayed, click the Notifications icon at the top right of the user interface to open the Alarms window, then select the Events tab. You can use these two tabs to monitor LCM alarms and events. The Events tab shows the events for the LCM recommendations, the commit actions, and exceptions.

Crosswork will report network events that are detected based on the policies and features you have enabled. For example, if a link drop causes an SR-TE policy to go down or LCM detects congestion, an event is displayed in the UI.

Step 2

Return to the Operational Dashboard to see that the LCM state changes to Mitigated for all TTE policy solution sets.

Note

 

The LCM state change can take up to twice as long as the SNMP cadence.

Step 3

Confirm the TTE policy deployment by viewing the topology map. Click in the Actions column and choose View deployed policies. The deployed policies are displayed in focus within the topology map. All other policies are dimmed.

Step 5: Remove TTE SR policies on LCM recommendation

After some time, the deployed TTE SR policies may no longer be needed. This occurs if utilization continues to stay under threshold without the LCM-initiated TTE policies. If this is the case, LCM generates new recommended actions to delete the TTE SR policy sets.

To remove the TTE SR policies upon LCM recommendation, follow the steps given below:

Procedure

Step 1

If needed: Display the topology map and click in the Actions column. Choose View deployed policies.

Step 2

Click Commit all to remove the previously deployed TTE SR policies.

Step 3

Confirm the removal by viewing the topology map and SR Policy table.

LCM Scenario: Summary and conclusion

In this scenario, we observed how to leverage LCM to alleviate traffic congestion in the network. LCM takes the manual tracking and calculation out of your hands but, at the same time, gives you control as to whether to implement the congestion mitigation recommendations or not. You can preview the recommendations and see how the potential deployment will take effect in your network before you deploy them. As traffic changes, LCM tracks the deployed TTE SR policies and decides whether or not they are still needed. If not, LCM recommends deleting them.

Scenario: Use CS-SR Policies to Reserve Bandwidth

In this scenario, we enable Circuit-Style Segment Routing Traffic Engineering (CS-SR, or CS SR-TE) policies and set bandwidth-reservation parameters, then configure a CS-SR policy and visualize it on the topology map. We will inspect the policy's details, including its computed Active (working) and Protected (protect) paths.

The examples in this scenario use the following topology:

Default Topology Map

We will observe what happens when the Active bandwidth-reserved path between the NCS1 and NCS3 nodes fails. We will then re-optimize the failed path.

Assumptions and prerequisites

The following sections list high-level requirements for proper CS-SR operation, including requirements and constraints on the policy attribute values set in each CS-SR policy and the processing logic followed during path reversions.

In addition to the constraints discussed in the following sections:

  • The Crosswork Circuit Style Manager (CSM) feature pack is a feature of Crosswork Network Controller Essentials. All licensed features are available during the 90-day trial period. After the trial period, you must have a license for Optimization Engine to continue using CSM.

  • Circuit-Style policy configuration was introduced with Crosswork Network Controller 5.0. To use it, you must install version 7.9.1 (or later) of the Cisco IOS-XR Path Computation Client (PCC) on your devices. If you have been using a previous version of CNC with IOS-XR version 7.7.1 or earlier, please upgrade to version 7.9.1 or later before attempting to configure CS-SR policies.

  • When using CSM with Crosswork Network Controller, the UI navigation starts from Traffic Engineering & Services. When using CSM with Optimization Engine, the navigation starts from Traffic Engineering.

CS policy attribute constraints

In this scenario, we will build a CS policy between node NCS1 and node NCS 3. The policy will use the following settings and constraints:

  • PolicyName: NCS1-NCS3

  • Headend Device: NCS1

  • Headend IP Address: 192.168.20.4

  • Tailend Device: NCS3

  • Tailend IP Address: 192.168.20.14

  • Color-choice: 1000

  • Bandwidth: 10000

  • path-protection: Enabled

  • disjoint-path: Enabled

  • disjoint-path forward-path type: Link

  • disjoint-path forward-path group-id: 531

  • disjoint-path reverse-path type: Link

  • disjoint-path reverse-path group-id: 5311

  • performance-measurement : Enabled.

  • performance-measurement profile-type: Liveness

  • performance-measurement liveness-detection: Enabled

  • performance-measurement profile: CS-active

  • working-path: Enabled

  • working-path preference: 100

  • working-path dynamic-path: Enabled

  • working-path dynamic-path pce: Enabled

  • working-path dynamic-path metric type: igp

  • working-path dynamic-path bidirectional-association-choice: Enabled

  • working-path dynamic-path bidirectional-association-id: 230

  • working path dynamic constraints segments: Enabled

  • working-path constraints segments protection: unprotected-only

  • protect-path: Enabled

  • protect-path preference: 100

  • protect-path dynamic-path: Enabled

  • protect-path dynamic-path pce: Enabled

  • protect-path dynamic-path metric type: igp

  • protect-path dynamic-path bidirectional-association-choice: Enabled

  • protect-path dynamic-path bidirectional-association-id: 231

  • protect-path dynamic constraints segments: Enabled

  • protect-path constraints segments protection: unprotected-only

  • restore-path: Enabled

  • restore-path preference: 100

  • restore-path dynamic-path: Enabled

  • restore-path dynamic-path pce: Enabled

  • restore-path dynamic-path metric type: igp

  • restore-path dynamic-path bidirectional-association-choice: Enabled

  • restore-path dynamic-path bidirectional-association-id: 232

  • restore-path dynamic constraints segments: Enabled

  • restore-path constraints segments protection: unprotected-only

The following table shows all the options you can choose when building a policy. It is essential to understand that the attributes described in the table act as constraints. Each of them corresponds to elements of the configuration that Crosswork Network Controller uses to govern how Circuit-Style path hops are computed. Each value is effectively a path computation or optimization constraint since they either specify a required property of a path or exclude possible choices for that path.

There are dependencies that must be met as well as combinations that are not allowed. The system will warn you when these sorts of issues arise. We encourage you to experiment and learn how to provision services in your network that match the types of services you want to deliver.

Table 1. Supported Circuit Style SR-TE policy attribute values and constraints

Attribute

Description

Policy path protection

The path protection constraint is required for both sides of a Circuit Style SR-TE policy.

Bandwidth constraint

The bandwidth constraint is required and must be the same on both sides of a Circuit Style SR-TE policy. Bandwidth changes can be made to existing policies with these effects:

  • Once you configure the new bandwidth on both sides, Crosswork Network Controller will evaluate the path. This will not result in a recomputed path.

  • If the new bandwidth is higher, Crosswork Network Controller checks the existing path to ensure sufficient resources. Suppose all currently delegated paths can accommodate the new bandwidth. In that case, Crosswork Network Controller returns the same path with the new bandwidth value, indicating to the path computation client (PCC) that it was successful. If any current paths cannot accommodate the new bandwidth, it returns the old bandwidth value, indicating that it was unsuccessful. This evaluation will not be retried unless the bandwidth is changed again.

  • If the bandwidth is lower, Crosswork Network Controller returns the same path with the new bandwidth value to indicate to the PCC that it was successful.

The user interface shows both the requested and reserved bandwidth under each candidate path when you view the policy details. These values can differ if the requested bandwidth is increased but there is insufficient available CS pool bandwidth along one or more of the paths.

Candidate paths and roles

The Working path is defined as the highest preference Candidate Path (CP).

The Protect path is defined as the CP with the second highest preference.

The Restore path is defined with the lowest preference CP. The headend must have backup-ineligible configured.

CPs of the same role in each direction must have the same CP preference.

Bi-directional

All paths must be configured as co-routed.

Paths with the same role on both sides must have the same globally unique bi-directional association ID.

Disjointness

Working and Protect paths on the same PCC must be configured with a disjointness constraint using the same disjoint association ID and disjointness type.

The disjointness association ID for a Working and Protect path pair in one direction must be unique compared to the corresponding pair in the opposite direction.

Only the Node and Link disjoint types are supported. The disjoint type must be the same in both directions of the same policy.

The Restore path must not have a disjointness constraint set.

Crosswork Network Controller follows strict fallback behavior for all Working and Protect path disjointness computations. This means that if node type disjointness is configured but no path is available, Crosswork Network Controller makes no automatic attempt to compute a less restrictive link type disjoint path.

Metric type

Only the TE, IGP, and Latency metric types are supported. The metric type used must match across Working, Protect, and Restore paths in both directions.

Segment constraints

All Working, Protect, and Restore paths must have the following segment constraints:

  • protection unprotected-only

  • adjacency-sid-only

To ensure persistence through link failures, configure static adjacency SIDs on all interfaces that might be used by Circuit Style policies.

Supported policy changes

The following constraints may be changed for an operationally "up" Circuit Style SR-TE policy that has been previously delegated:

  • Metric type

  • Disjoint type

  • MSD

  • Affinities

Once configuration changes are consistent across all CPs and both PCCs (for example, the new metric type is the same for all CPs and both sides), Crosswork Network Controller will initiate a recompute, which can result in new Working, Protect, and Restore paths.

During any transitory period in which configurations are not in sync between paths on the same PCC or between PCCs, no path updates are sent to the PCCs.

Path computation

Crosswork Network Controller computes paths for circuit style policies only after a complete bi-directional, path-protected set of candidate paths has been delegated, including Working and Protect paths on both sides.

Crosswork Network Controller computes the Restore path only after the Working and Protect paths are down. The SR Circuit Style Manager feature pack configuration interface provides a configurable delay timer to control how long to wait after Restore paths are delegated from both sides before computing the path. This delay allows topology and SR policy state changes to fully propagate to Crosswork in cases where these changes triggered the Restore path delegation.

Path computation is supported for Intra/Inter area/level and Intra/Inter IGP Domain (same AS).

Reversion behavior

Reversion behavior is controlled by the configuration of the WTR lock timer option under the Protect and Revert paths (it is not relevant for the Working path):

  • No lock configuration: Revert after a default 5-minute lock

  • Lock with no duration specified: No reversion

  • Lock duration <value>: Revert after the specified number of seconds

Unsupported CS policy options

The following table lists the CS policy options, attributes, and constraints that are not supported in this version of CSM.

Table 2. Unsupported Circuit Style SR-TE policy options

Attribute

Description

Unsupported configurations

The following configurations are not supported:

  • Metric-bounds

  • SID-Algo constraints

  • Partial recovery is not supported with 7.8.x.

  • State-sync configuration between PCEs of a high-availability pair. These are not required with Circuit Style SR-TE policies. Use of this feature may result in degraded performance.

  • Multiple Circuit Style SR-TE policies between the same nodes with the same color but different endpoint IPs.

Unsupported policy changes

The following configuration changes to a previously delegated and operationally "up" Circuit Style SR-TE policy are not supported:

  • CP preference

  • Disjoint Association ID

  • Bi-directional Association ID

To change these configurations for an existing policy, you must first shut down the policy on both sides, make the change (complying with restrictions as detailed above in terms of consistency), and then "no shut" the policy.

Unsupported path computation

Automatic re-optimization is not supported for paths based on changes in topology, LSP state, or any periodic event. Path computation is not supported for Inter-AS.

Path reversion logic

Path reversion depends on the initial state of the Working, Protect and Revert paths and the events affecting each path. The scenarios in the following table provide examples of typical reversion behavior.

Table 3. Path reversion scenarios

Initial state

Events

Behavior

Working path is down, Protect path is up/active

Working path comes back up

  1. Working path recovers to up/standby state.

  2. Each PCC moves the Working path to active after the WTR timer expires.

  3. Protect path moves to up/standby.

Working path is down, Protect path is down, Revert path is up/active

Working path comes back up, then Protect path comes back up

  1. Working path recovers and goes to up/active state

  2. Revert path is removed

  3. Protect path recovers and goes to up/standby

Working path is down, Protect path is down, Revert path is up/active

Protect path comes back up, then Working path comes back up

On side A: The Working path failure is local (the first Adj SID in the SegList is invalid):

  1. Protect path recovers and goes to up/active.

  2. Recover path is removed.

  3. Working path recovers and goes to up/standby.

  4. Each PCC moves the Working path to active after the WTR timer expires, Protect path goes to up/standby.

On side Z: Working path failure is remote (first Adj SID in SegList is valid):

  1. Protect path recovers but is not brought up, Revert path remains up/active.

  2. Working path recovers and goes up/active.

  3. Revert path is removed.

  4. Protect path goes to up/standby.

What happens when path failures occur?

Crosswork Network Controller computes paths for CS policies only after a complete bidirectional, path-protected set of candidate paths has been delegated. A path can be considered to have "failed" for various reasons, including transient changes in workloads caused by congestion elsewhere in the network or any condition that causes the path not to meet bandwidth expectations. Irrespective of the cause, three types of paths are used during these kinds of failures. Crosswork Network Controller activates them as needed, according to their preference settings:

  • Working—This is the path with the highest preference value. Crosswork Network Controller always tries to keep the operational (Oper Up) path with the highest preference as the Active path.

  • Protected—This is the path with the second highest preference. If the Working path goes down, the Protected path (with the lower preference value) is activated. After the Working path recovers, the Protected path remains active until the default lock duration expires, and then the Working path is activated.

  • Restore—This is the path with the lowest preference path. Crosswork Network Controller computes the Restore path only when the Working and Protected paths are down. You can control how long after Restore paths are delegated to wait before the path is computed. This delay allows topology and policy state changes to fully propagate through the network and allows Crosswork Network Controller to gather and analyze telemetry to determine network health.

To address failures effectively and switch from the Working to the Protected path, configure Performance Measurement (PM) as part of your CS policy. For more information, see Step 4: Configure circuit-style SR-TE policies using import.

The following image shows that the Working and Protected paths of the example CS policy are operational. The active path is indicated by the "A" icon shown next to that path in the State column in the Candidate path list.

Figure 11. Initial candidate paths: working path is active
Initial Candidate Paths: Working Path is Active

If the Working path performance falls below expectations, the Protected path becomes Active immediately (usually under 50 milliseconds).

Figure 12. Protected path becomes active
Protected Path Becomes Active

When the Working path comes back up, the Protected path resumes the Protected role again, and the Working path (with preference 100) becomes Active again.

If both the Working and Protected paths go down, Crosswork Network Controller calculates a Restore path and makes it the active path. Note that the Restore path has the lowest preference value of 10. The Restore path only appears in this particular case. If the Working or Protected paths become operational again, Crosswork Network Controller will activate them, and the Restore path will disappear from the topology map and the Candidate path list.

Figure 13. Restore path becomes active
Restore Path Becomes Active

Step 1: Enable Circuit Style Manager

To manage and visualize circuit-style SR-TE policies on the topology map, we must first enable SR Circuit-Style Manager (CSM) and set bandwidth reservation settings. As soon as you define these settings, CSM computes the best bidirectional failover paths between the two nodes, while observing the requested CSM bandwidth and threshold settings, and the constraints defined in the circuit-style SR-TE policy. The following steps show how to do this.

CSM tries to ensure that the total reserved bandwidth on all interfaces remains at or below the network-wide resource pool. When the total usage on all interfaces exceeds the threshold value you set, CSM generates a threshold-crossing alarm.

To help you estimate the circuit-style SR-TE bandwidth pool and threshold settings that are reasonable for your organization's implementation, two examples are provided to demonstrate how CSM handles policies that exceed either the bandwidth pool size or both the pool size and alarm threshold. For this scenario, you can enter either of these examples or choose settings that are less likely to be exceeded in a practical implementation.

After enabling CSM, you must create circuit-style SR-TE policy configurations. You can use any of the following methods to create circuit-style SR-TE policies. In this scenario, we will create the same policy each time, but we will go through each method so that you can decide which methods will best meet your needs:

Procedure

Step 1

From the main menu, choose Services & Traffic Engineering > Circuit Style SR-TE > Configuration > Basic.

Step 2

Toggle the Enable switch to True.

Figure 14. Basic Circuit Style SR-TE configuration
Basic Circuit Style SR-TE Configuration

Step 3

Enter the required bandwidth pool size and threshold information, as explained in the table below. See also the examples below, and choose one of them to enter.

Field Description

Link CS BW pool size

The percentage of each link's bandwidth reservable for circuit-style SR-TE policies.

Link CS BW min threshold

The Link CS BW Pool utilization percentage beyond which Crosswork Network Controller will generate a threshold-crossing event notification.

Step 4

Click Commit changes to save the Basic configuration.

Step 5

(Optional): Click the Advanced tab to display additional CS-SR configuration values.

Figure 15. Circuit Style SR-TE configuration - advanced tab
Circuit Style SR-TE Configuration - Advanced Tab

  1. Change the values on the Advanced tab as explained in the table below.

    Field Description

    Validation interval

    This is the interval that CSM will wait before the bandwidth reserved for an un-delegated policy is returned to the circuit-style SR-TE policy bandwidth Pool.

    Timeout

    The duration CSM will wait for the delegation request before generating a threshold-crossing alarm.

    Restore delegation delay

    The duration CSM will pause before processing a restore path delegation.

    Debug optimizer

    Toggle the switch to True to turn on the Debug Optimizer for all CS-SR policies. The Debug Optimizer will write log files to the Crosswork Network Controller file system whenever it calculates routes up to the maximum number of files you specify.

    Debug optimization max files

    Enter the maximum number of log files the Debug Optimizer will write. Once the maximum is reached, the Optimizer will overwrite existing files.

  2. When you are finished entering Advanced configuration values, click Commit changes to save the configuration.

Example

Example: Bandwidth utilization surpasses defined threshold

In this example, we assume the reserved bandwidth settings are as follows:

  • Bandwidth pool size: 10%

  • Bandwidth pool threshold: 1%

Our two nodes have 10 Gbps Ethernet interfaces, so the bandwidth pool size with these settings is 1Gbs, and the alarm threshold is 100 Mbps.

  1. We create a CS policy connecting node 5501-02 to node 5501-01 (r02 - r01), with a bandwidth of 100 Mbps.

    Figure 16. CS-SR policy 10 Mbps up
    CS-SR Policy 10 Mbps Up

  2. Later, the requested bandwidth for the policy increases to 500 Mbps. The updated CS policy is created and operational (Oper State Up).

    Figure 17. CS-SR policy 500 Mbps up
    CS-SR Policy 500 Mbps Up

  3. Since the bandwidth utilization of 500 Mbps with the updated policy is greater than the configured bandwidth threshold (100 Mbps), Crosswork triggers alerts.

    Figure 18. Threshold alerts
    Threshold Alerts

Example: Bandwidth pool size and usage exceeded

In this example, we assume the reserved bandwidth settings are as follows:

  • Bandwidth pool size: 10%

  • Bandwidth pool threshold: 10%

The bandwidth pool size for the 10 Gbps Ethernet interfaces is 1Gbs and the alarm threshold is 100 Mbps.

  1. An existing CS-SR policy from node 5501-02 to node 5501-01 (r02- r01) uses a bandwidth of 500 Mbps.

  2. Later, a new policy requiring a bandwidth of 750 Mbps with a path from node 5501-02 to node 5501-01 to 5501-2 (r02- r01- r2) is requested. Since the existing policy and this new policy together exceed the bandwidth pool size, and alarm threshold of 1 Gbps (750 Mbps + 500 Mbps = 1250 Mbps), the following behaviors occur:

    • The new CS-SR policy r02- r01- r2 has been created but is not operational (Oper State Down).

      Figure 19. CS-SR policy exceeds bandwidth pool size
      CS-SR Policy Exceeds Bandwidth Pool Size

    • Alerts are triggered.

      Figure 20. Threshold alerts
      Threshold Alerts

  3. Later, the CS-SR policy r02- r01- r2 is updated and only requires 10 Mbps. The following behaviors occur:

    • Since the total bandwidth required for the two policies (10 Mbps + 500 Mbps = 510 Mbps) now requires less than the bandwidth pool size (1Gbps), CS-SR policy r02- r01- r2 becomes operational (Oper State Up).

      Figure 21. Updated CS-SR policy operational
      Updated CS-SR Policy Operational

    • Since the bandwidth utilization (10 Mbps) with the updated policy is below the configured bandwidth threshold (1 Gbps), alerts are cleared.

      Figure 22. Cleared alerts
      Cleared Alerts

Step 2: Configure circuit-style SR-TE policies using device CLI

Before Crosswork Network Controller, most network engineers created circuit-style SR-TE policies directly on the devices, using the appropriate network operating system CLI commands. This step of the scenario covers direct CLI policy configuration for a Cisco device. We present it only because this is a legitimate way to create these policies, so you can see how the configuration implemented using this method matches the configuration of the other Crosswork Network Controller-native methods presented in this scenario.

Crosswork Network Controller's topology discovery will automatically recognize CS policy configurations implemented directly on devices and will help you visualize them on the topology map. However, this method has some important drawbacks. To start with, you will need to be familiar with the CLI commands required to configure circuit-style SR-TE policies properly. More importantly, Crosswork Network Controller can discover circuit-style SR-TE policies configured directly on a device but cannot change or delete them. We encourage you to use instead the Add or Import methods, which allow you to manage and change your configuration using Crosswork Network Controller. For help using these methods, skip this step and go on to Step 3. Configure policies using add or to Step 4. Configure policies using import.

A circuit-style SR-TE policy configuration must include the destination endpoint, the amount of requested bandwidth, and the bidirectional attribute. See Assumptions and prerequisites for additional requirements and notable constraints.

When configuring circuit-style SR-TE policies directly on Cisco devices, make sure the configuration includes a Performance Measurement (PM) Liveness profile. A PM Liveness profile enables proper detection of candidate path liveness and effective path protection. Path Computation Clients (PCCs) do not validate past the first SID, so without PM Liveness, the path protection will not occur if the failure in the circuit-style SR-TE policy candidate path occurs after the first hop in the segment list. Crosswork Network Controller supports software-based and hardware-offload PM Liveness configuration methods. For more background on PM Liveness profiles and methods, see Configuring SR policy liveness monitoring.

Procedure

Step 1

Use your preferred method to access the head-end device console and log in.

Step 2

If applicable, enable the hardware module on the device for PM configuration.

Example:

hw-module profile offload 4

reload location all

Step 3

Configure the Performance Measurement (PM) Liveness profile on the device. The following example uses a hardware-offload configuration.

Example:

performance-measurement
 liveness-profile sr-policy name CS-active-path
  probe
   tx-interval 3300 
!
npu-offload enable   !! Required for hardware Offload only
  !
 !
 liveness-profile sr-policy name CS-protected-path
  probe
   tx-interval 3300
  !

npu-offload enable   !! Required for hardware Offload only
  !
 !
!

Step 4

Configure the circuit-style SR-TE policy. All configuration entries shown are required in order for the Crosswork Network Controller CSM feature pack to manage the policy. Entry values that you must change appropriately for your network (or for your PM Liveness profile) are shown in italics. See Assumptions and prerequisites for additional requirements and notable constraints.

Example:

segment-routing
 traffic-eng
  policy NCS1-NCS3

   performance-measurement
    liveness-detection
     liveness-profile backup name CS-protected      !! Name must match liveness profile defined for Protect path
     liveness-profile name CS-active               !! Name must match liveness profile defined for Active path
    !
   !
   bandwidth 10000
   color 1000 end-point ipv4 192.168.20.4
   path-protection
   ! Path protection is required on both ends of the candidate-paths
  ! Defining the Working path. Must have the highest CP preference
    preference 100
     dynamic
      pcep
      !
      metric
       type igp
      !
     !
     constraints
      segments
       protection unprotected-only
       adjacency-sid-only
      !
      disjoint-path group-id 3 type node
     !
     bidirectional
      co-routed
      association-id 230
 !
    ! Defining the Protect path. Must have second highest CP preference.
    preference 50
     dynamic
      pcep
      !
      metric
       type igp
      !
     !
     constraints
      segments
       protection unprotected-only
       adjacency-sid-only
      !
      disjoint-path group-id 3 type node
     !
     bidirectional
      co-routed
      association-id 231
     ! Defining the restore path. It must have both the lowest CP preference and backup-ineligible setting
    preference 10
     dynamic
      pcep
      !
      metric
       type igp
      !
     !
     backup-ineligible
     !

     constraints
      segments
       protection unprotected-only
       adjacency-sid-only
      !
     !
     bidirectional
      co-routed
      association-id 232
     !
    !
    !
    
     !
    !

   !
  !

 !
!

Step 3: Configure circuit-style SR-TE policies using add

You can create a circuit-style SR-TE policy between any two nodes using the Crosswork Network Controller Add function. This method is the simplest for users who want to be able to use Crosswork to edit or delete the circuit-style SR-TE policies they create.

This method doesn't eliminate the need to be familiar with the CLI command attributes needed to configure circuit-style SR-TE policies properly. If you prefer a faster method that can help you standardize these policies across your network, skip this step and use the method in Step 4. Configure policies using import.

Procedure

Step 1

From the main menu, choose Services & Traffic Engineering > Provisioning (NSO).

Step 2

In the Services/Policies column on the left, select SR-TE > Circuit-Style Policy. Crosswork displays the Create SR-TE > Circuit Style Policy window.

Step 3

Click Add icon. Crosswork displays the Create SR-TE > Circuit Style Policy window.

Step 4

In this scenario, we will use the name NCS1-NCS3. Enter that name in the Name field, then click Continue.

Step 5

Begin by making the following entries in the respective fields on the Create SR-TE > Circuit Style Policy:

  • Name: NCS1-NCS3

  • Color-choice: 1000

  • Bandwidth: 10000

  • path-protection: Check the checkbox.

Note

 

The color-choice and bandwidth values shown here are examples only. If you decide to follow this example in your network, use a color-choice value that is not already in use and a bandwidth value that is available within the percentage you are dedicating to CS policies.

Step 6

Continue the scenario by entering the circuit-style SR-TE policy constraints and specifications shown in the table below. The user interface for the Add function groups policy fields into related categories. Click on the field group name or the > icon at the right to expand a category and display its dependent fields.

You must change the device names and IP addresses you enter to match the devices on your network.

Table 4. Example: circuit-style SR-TE policy ssing add

Expand this:

To specify this:

head-end

  • Device: Enter NCS1.

  • Ip-address: Enter 192.168.20.4.

tail-end

  • Device: Enter NCS3.

  • Ip-address: Enter 192.168.20.14.

disjoint-path

Click Enable disjoint-path.

disjoint-path > forward-path

  • Type: Select Link.

  • group-id: Enter 531.

disjoint-path > reverse-path

  • Type: Select Link.

  • group-id: Enter 5311.

performance-measurement

Click Enable performance-measurement.

performance-measurement > Profile-type

Click liveness.

performance-measurement > Profile-type > liveness-detection

Click Enable liveness-detection. Then:

  • Profile: Enter CS-active.

  • Backup: Enter CS-protected.

working-path

Click Enable working-path. Then select dynamic-path.

working path > dynamic

Click Enable dynamic-path. Then:

  • pce: Check the checkbox.

  • Metric-type: Select igp

  • Bidirectional-association-choice: Select bidirectional-association-id and enter 230in the field.

working path > dynamic > constraints > segments

Click Enable segments. Then in the Protection field, select unprotected-only.

protect-path

Click Enable protect-path. Then select dynamic-path.

protect-path > dynamic

Click Enable dynamic. Then:

  • pce: Check the checkbox.

  • Metric-type: Select igp

  • Bidirectional-association-choice: Select bidirectional-association-id and enter 231in the field.

protect-path > dynamic > constraints > segments

Click Enable segments. Then in the Protection, field, select unprotected-only.

restore-path

Click Enable restore-path. Then select dynamic-path.

restore-path > dynamic

Click Enable dynamic-path. Then:

  • pce: Check the checkbox.

  • Metric-type: Select igp

  • Bidirectional-association-choice: Select bidirectional-association-id and enter 232in the field.

restore-path > dynamic > constraints > segments

Click Enable segments. Then in the Protection field, select unprotected-only.

Step 7

When you finish, click Dry run to validate and save your changes. Crosswork Network Controller will display your changes in a popup window.

If you want to configure a service with requirements that do not match those described in this example, contact Cisco Customer Experience.

Step 8

When you are ready to activate the policy, click Commit changes.

Step 4: Configure circuit-style SR-TE policies using import

If your organization has already implemented circuit-style SR-TE policies and wants to roll them out on more network devices, the easiest way to do so is using Crosswork Network Controller's Import function. You can use Import to download a policy template file from Crosswork Network Controller. The template file will be in JSON or XML format. You can save the template under a new name, insert the policy values of your choice, and then import the modified file.

Using the Import function is fast and a good way to standardize circuit-style SR-TE policies across your network. You can set the same template files to establish CS-SR policies between multiple pairs of devices, varying only the endpoint names and addresses and any other values as appropriate for each circuit.

Procedure

Step 1

From the main menu, choose Services & Traffic Engineering > Provisioning (NSO).

Step 2

In the Services/Policies column on the left, select SR-TE > Circuit-Style Policy.

Step 3

Click Import icon. Then click the Download sample JSON and XML files (.zip) link. The downloaded ZIP file contains templates for all the Crosswork Network Controller service types, including Circuit-Style, in JSON and XML formats.

Step 4

Unzip samplePayload.zip and locate the CS-Policy.json and CS-Policy.xml template files.

Step 5

Using a JSON or XML file editor of your choice, open the CS-Policy template file and save it under the name cs1-cs4.

Step 6

If using the JSON template file, edit it to look like the example below. If you are using the XML template, go on to the next step.

Example:

CS-SR policy in JSON
{
  "name": "NCS1-NCS3",
  "head-end": {
    "device": "NCS1",
    "ip-address": "192.168.20.4"
  },
  "tail-end": {
    "device": "NCS3",
    "ip-address": "192.168.20.14"
},
  "color": 1000,
  "bandwidth": 10000,
  "disjoint-path": {
    "forward-path": {
      "type": "Link",
      "group-id": 531
    },
    "reverse-path": {
      "type": "Link",
      "group-id": 5311
    }
  },
  "performance-measurement": {
    "profile-type": "liveness",{
      "profile": "CS-active",
      "backup": "CS-protected"
    },
  },  
  "path-protection": {},
  "working-path": {
    "dynamic": {
      "constraints": {
        "segments": {
          "protection": "unprotected-only"
        }
      },
      "pce": {},
      "metric-type": "igp",
      "bidirectional-association-id": 230
    }
  },
  "protect-path": {
    "dynamic": {
      "constraints": {
        "segments": {
          "protection": "unprotected-only"
        }
      },
      "pce": {},
      "metric-type": "igp",
      "bidirectional-association-id": 231
    },
    "revertive": true
  },
  "restore-path": {
    "dynamic": {
      "constraints": {
        "segments": {
          "protection": "unprotected-only"
        }
      },
      "pce": {},
      "metric-type": "igp",
      "bidirectional-association-id": 232
    }
  }
}

Step 7

If you are using the XML template file, edit it to look like the example below.

Example:

CS-SR policy in XML
<config xmlns="http://tail-f.com/ns/config/1.0">
  <cs-sr-te-policy xmlns="http://cisco.com/ns/nso/cfp/cisco-cs-sr-te-cfp">
    <name>NCS1-NCS3</name>
    <head-end>
      <device>cs1</device>
      <ip-address>192.168.20.4</ip-address>
    </head-end>
    <tail-end>
      <device>cs4<device>
      <ip-address>192.168.20.14<ip-address>
    <tail-end>
    <color>1000</color>
    <bandwidth>10000<bandwidth>
    <disjoint-path>
      <forward-path>
        <type>Link</type>
        <group-id>531</group-id>
      </forward-path>
      <reverse-path>
        <type>Link</type>
        <group-id>5311</group-id>
      </reverse-path>
    </disjoint-path>
    <performance-measurement>
      <profile-type>liveness
        <profile>CS-active</profile>
        <backup>CS-protected"</backup>
      </profile-type>
    </performance-measurement>
    <path-protection></path-protection>
    <working-path>
      <dynamic>
        <constraints>
          <segments>{
            <protection>unprotected-only</protection>
          </segments>{
        </constraints>{
          <pce></pce>       
          <metric-type>igp</metric-type>
          <bidirectional-association-id>230</bidirectional-association-id>
      </dynamic>
    </working-path>
    <protect-path>
      <dynamic>
        <constraints>
          <segments>
            <protection>unprotected-only</protection>
          </segments>
        </constraints>
        <pce></pce>       
        <metric-type>igp</metric-type>
        <bidirectional-association-id>231</bidirectional-association-id>
      </dynamic>
    </protect-path>
  <restore-path>
    <dynamic>
      <constraints>
        <segments>
          <protection>unprotected-only</protection>
          </segments>
        </constraints>
        <pce></pce>       
        <metric-type>igp</metric-type>
        <bidirectional-association-id>232</bidirectional-association-id>
      </dynamic>
    </restore-path>
  </cs-sr-te-policy>
</config>

Step 8

When you have finished editing the file and saved your changes, navigate to Services & Traffic Engineering > Provisioning > SR-TE > Circuit-Style Policy again.

Step 9

Click Import icon again. In the File name field, enter the path and file name of your modified template file, or click Browse to locate and select it. Then click Import.

Step 5: View circuit-style SR-TE policies on the topology map

Next, use Crosswork Network Controller to visualize the NCS1-NCS3 circuit-style SR-TE policy and isolate it on the map. To make this step more realistic and demonstrate how to focus on just one policy, the scenario assumes that we have multiple active circuit-style SR-TE policies, not just the policy we created. We'll also view the circuit-style SR-TE policy details, including endpoints, bandwidth constraints, IGP metrics, and candidate (Active/Working and Protect) paths.

Procedure

Step 1

From the main menu, choose Services & Traffic Engineering > Traffic Engineering > SR-MPLS. Then click Circuit style.

Figure 23. View Circuit Style SR-TE policies
View Circuit Style SR-TE Policies

The policy table lists all of the circuit-style SR-TE policies.

Step 2

From the Actions column, click Circuit Style SR-TE > View details for one of the circuit-style SR-TE policies.

Note

 

You cannot edit or remove circuit-style SR-TE policy configurations that have been created directly on the device.


View Circuit Style SR-TE Policy Details

The Circuit style policy details panel is displayed. By default, the Active path is displayed in the topology map and shows the bidirectional paths (Bi-Dir Path checkbox is checked) on the topology map. The Candidate path list displays the Active (path that currently takes traffic) and Protected paths.


CS-SR Policy Details Summary

Note

 

The bandwidth constraint value can differ from the bandwidth you requested if the value was increased and insufficient resources existed to satisfy demand on all Active and Protected candidate paths.

Step 3

View Candidate path configuration details.

  1. The Circuit style policy details panel allows you to drill down to view more information about the candidate paths. The operational (Oper State Up) candidate path with the highest preference will always be the Active path. In this example, the Protected path (with preference 50) is currently the Active path and is displayed on the topology map. Notice that it is designated with a green "A" icon under State to clearly indicate it is currently the operational Active path. Click Expand all to view more information about both paths.


    Candidate Path on Topology Map

    Note

     

    • First preference paths are shown as purple links.

    • Second preference paths are shown as blue links.

    • Third preference paths are shown as pink links.
    If the circuit-style SR-TE policy configuration was done through the UI, you have the option to view the circuit-style SR-TE policy configuration. To see the configuration, click the link next to Config id. For example:
    View Candidate Path Details

Step 4

To view the physical path and metrics between endpoints of the selected policies, click Display Preferences icon to turn applicable metrics on and check the IGP path checkbox.
IGP Metrics

Step 6: Verify circuit-style SR-TE policy bandwidth utilization

Let's verify that the reserved bandwidth pool settings we defined when enabling circuit-style SR-TE (see Step 1: Enable Circuit Style Manager) are configured properly. We can also check how much bandwidth is either in use or still available.

Procedure

Step 1

From the main menu, choose Services & Traffic Engineering > Traffic Engineering > SR-MPLS. Then, under the SR-MPLS column, click Circuit style. The SR Policy table lists all CS SR policies.

Step 2

In the SR Policy table, check the check box next to the participating device whose details you want to see.

Step 3

On the topology map, click on a participating circuit-style SR-TE policy node to display the device details for that node.

Step 4

On the Device details page, click the Links tab to display the list of CS-SR and other links on the participating node. Then click on the link whose details you want to see. The Link details list displays a Summary of the link information.

Step 5

On the Link details page, click on the Traffic engineering tab, then the General tab. The link details list displays detailed information for the link.

Under Circuit style bandwidth pool, you can see the reserved bandwidth pool size, the amount of bandwidth currently being used, and the amount of bandwidth (of the total allocated to circuit-style SR-TE policies) that is still available.

This example shows the reserved bandwidth pool size as 800 Mbps for NCS-3 and NCS1. The configured settings were earlier defined as 80% for the bandwidth pool size. Since the interfaces on this circuit are 1 Gbps, we can confirm that circuit-style SR-TE has correctly allocated 80 percent of the bandwidth for these two interfaces.

Figure 24.
CS-SR Policy Bandwidth Pool

Step 7: Trigger circuit-style SR-TE path recomputation

Circuit-Style policies are static in nature, meaning once the paths are computed, Crosswork Network Controller will not re-compute them automatically. Changes in your network topology or operational status may affect the previously computed Working and Protected paths to the extent that you want Crosswork Network Controller to re-compute and optimize them for the new situation. In this step, we demonstrate how to re-optimize paths to accommodate these types of changes.

For more details on the logic CSM employs in these cases, see What happens when path failures occur?.

Procedure

Step 1

From the main menu, choose Services & Traffic Engineering > Traffic Engineering > SR-MPLS and click Circuit style.

Figure 25. Select Circuit Style tab
Select Circuit Style Tab

Step 2

The SR Policy table displays the status of each of the Active CS-SR policies. One of them is Operationally down.

Step 3

From the Actions column next to the CS-SR TE policies whose Operational State is Down, click More icon> View details.

Crosswork Network Controller displays the Circuit style policy details window in the side panel. By default, the topology map shows the Active path and the bidirectional paths on the topology map (for these to appear, the Bi-Dir path checkbox in the topology map's Show panel must be checked). The Candidate path list at the bottom of the side panel displays the Active (Working) and Protected paths.

In the Summary panel, click the See more link to get a closer look at the type of Summary details available. The Candidate Path list displays the Active and Protected paths.

Step 4

To have Crosswork Network Controller re-optimize these paths: Click More icon at the top of the Circuit style policy details panel and select Re-optimize. Click Yes when prompted to confirm your selection.

Summary and conclusion

In this scenario, we observed how to use Circuit Style Segment Routing policies to reserve bandwidth for high-priority services and traffic in the network. CS-SR removes the need to manually track and calculate high-priority traffic paths, but it still gives you control over how those paths are calculated and optimizes bandwidth usage on each path. You can use these policies to ensure that bandwidth is dedicated to these services. As traffic changes, Circuit Style policies warn you when your dedicated "circuit" paths fail and allow you to re-optimize them as needed.