Cisco Crosswork Network Controller 7.2.x Network Bandwidth Management

PDF

Cisco Crosswork Network Controller 7.2.x Network Bandwidth Management

Important considerations when using LCM

Want to summarize with AI?

Log in

This section outlines key recommendations and requirements for configuring and operating LCM.


Review these important considerations to ensure proper setup, optimal operation, and secure management of LCM domains.

User roles and permissions

  • Ensure user roles have LCM task permissions for a domain before configuring LCM and committing recommendations. For more details on RBAC and user roles, see the Cisco Crosswork Network Controller Administration Guide.

  • Device Access Group (DAG) access is not supported by LCM. Users with LCM permissions can configure and commit LCM recommendations regardless of whether or not they have DAG access for any devices in that domain.

Supported network features and limitations

  • Do not steer LDP-labeled traffic into LCM autoroute TTE SR policies. LCM does not support LDP-labeled traffic.

  • Avoid using LCM on networks with Tree SID policies, as incomplete traffic measurements can distort calculations.

Domain management and device support

  • Limit domains to a maximum of 2000 devices for efficient LCM operation. A domain is identified by the IGP process and domain ID from the PCC router's configuration (link-state instance-id) used for BGP-LS advertisement.

  • LCM recommended solutions utilize resources within a single domain only.

  • If domain interfaces or links are removed or go down (LINK_DOWN state), either intentionally or unintentionally, LCM configuration and the Domain UI card (see Configure LCM) remain available until links are aged out, providing up to 4 hours for recovery.

  • Manually remove links from the UI if you need to force domain removal before the automatic aging period. The domain remains "ready for deletion" until the last link is removed.

Traffic evaluation and statistics

  • LCM evaluates network utilization on a regular, configurable cadence of 1 minute or more, with a default of 10 minutes. The cadence can be set lower to improve responsiveness but is typically equal to or greater than the SNMP polling interval.

  • The traffic statistics collection interval affects how quickly LCM can respond to topology changes and LSP deployments that affect interface and LSP traffic measurements. Be aware that LCM can take up to twice the statistics collection interval plus the LCM evaluation interval for recommendations to fully reflect changes. During this period, LCM recommendations may evolve as the traffic measurements are updated and eventually fully converge in Crosswork Network Controller.

ECMP handling and optimization eligibility

  • LCM uses ECMP across parallel TTE SR policies, assuming roughly equal splitting of traffic. Actual ECMP behavior depends on traffic patterns and aggregation. LCM can be configured to detect and notify about excessive uneven ECMP splitting.

  • To mitigate the effects of uneven ECMP, the overprovisioning factor is used in LCM. For more information, see Configure LCM.

  • Do not steer traffic from existing SR-TE policies into LCM TTE SR policies. Ensure existing non-LCM SR-TE policies do not use regular Algo-0 prefix SIDs. Any combination of Algo-1 Strict, Flexible Algorithm, or adjacency SIDs is recommended to prevent this traffic from being steered into LCM TTE SR policies.

High Availability (HA) and SR-PCE behavior

  • After an HA switchover, you can manually add missing interfaces that were previously monitored or update domain configuration options once the system stabilizes. Missing interfaces may occur if added after the last cluster data synchronization.

  • When an SR-PCE goes down, LCM enters a dormant stage, and remains so until all SR-PCEs are reconnected and their associated topologies are fully synchronized with the topology service. LCM does not have visibility into the state of the SR-PCE redundancy set.


BGP-LS speaker placement for multiple AS networks with a dedicated IGP instance between ASBRs

Interdomain latency-optimized SR policy path computation refers to the process of finding the best routes between different networks (autonomous systems) using SR-PCE, aiming to minimize data travel delay or latency. This approach is especially important when egress peer engineering (EPE) is not supported.

  • Dedicated IGP instance: A dedicated Interior Gateway Protocol (IGP) instance can be configured between autonomous system border routers (ASBRs) across different autonomous system numbers (ASNs) to support this computation.

  • Topology reporting: Identifying ASBRs that report the topology via BGP-LS (Border Gateway Protocol Link State) is essential for accurate topology discovery.

  • BGP-LS configuration: At least one ASBR in each AS participating in the dedicated inter-AS IGP (for example, Domain 100) must have BGP-LS enabled to report the IGP between each ASBR.

  • BGP-LS identifier: Each ASBR must use the same BGP-LS identifier to report the domain.

  • Multiple ASBR support: Multiple ASBRs per AS can report BGP-LS topology, providing flexibility in topology reporting.

Figure 1. BGP-LS session reporting domain 100
BGP-LS session reporting domain 100