Optimize Metrics in the Network Core

The Metric optimization tool optimizes metrics in the network core. It replaces the IGP metrics of core interfaces in a network plan with new metrics chosen to maximize the throughput achievable by the resultant routes, under a specified set of failure scenarios.

The Tactical metric optimization tool lets you quickly fix local congestion by doing as few modifications as possible on selected interfaces to push utilizations under a given level.


Note
The core of the network must be connected, and all nodes must be contained in one AS. That is, there must be a path between any two core nodes that passes only through other core nodes in the same AS, and not through edge nodes. If this is not the case, Metric optimization signals an error.

This section contains the following topics:

Core versus edge

Cisco Crosswork Planning network models allow nodes to be defined as either core nodes or edge nodes. Note that these definitions are not related to any explicit router configurations. A similar classification of circuits is determined implicitly by the nodes they connect. If a circuit is attached to one or more edge nodes, it is defined as an edge circuit. Otherwise, it is a core circuit. Edge metrics and core metrics mean metrics of edge and core circuits, respectively.

This core and edge distinction helps define certain policies followed by Cisco Crosswork Planning tools. In Metric optimization, these are as follows:

  • Only core metrics are changed.

  • The objective is to minimize utilization in the core. Utilization in the edge is not taken into account.

  • The routes selected by the metrics are restricted by the tool so that any route between a source and a destination will enter and leave the core at most once. That is, edge leakage of routes is prevented.

A consequence of these policies is that larger edge metrics in the plan file to be optimized may result in better optimized core routes. With larger given edge metrics, the Metric optimization tool has more flexibility in how it can set the core metrics without leakage of routes into the edge.

Perform metric optimization

There are many trade-offs in metric optimization. The main trade-off is between performance under normal operation versus performance under failure. Metrics can be selected to do well under the former while ignoring the latter, or to try to balance performance between the two.

Metric optimization optimizes undifferentiated traffic, but does not optimize traffic per service class or per interface queue. If there are policies set on the undifferentiated traffic, Cisco Crosswork Planning tries to minimize both the interface utilization and the policy violations.

To run the Metric optimization tool, do the following:

Procedure

Step 1

Open the plan file (see Open plan files). The plan file opens in the Network Design page.

Step 2

From the toolbar, choose Actions > Tools > Metric optimization.

Figure 1. Metric optimization options

Step 3

In the Interfaces to optimize panel, select the required interfaces to optimize. Use the drop-down list to select all or the Core interfaces, or the Select manually button to select the required interfaces manually.

Step 4

Expand the Normal (Non-Resilient) section and choose the optimization options to use. See Table 1 for field descriptions.

Step 5

Expand the Failure (Resilient) section and decide on the options to use. See Table 1 for field descriptions.

For planning purposes, the most benefit from metric optimization is that it is able to optimize routing over a large number of failure scenarios. This capability controls that optimization, as well as controls the trade-off between normal and failure optimizations.

Step 6

Specify the remaining options to fine-tune the optimization. See Table 1 for field descriptions.

Step 7

Click Next.

Step 8

(Optional) Specify the maximum number of threads. By default, the optimizer tries to set this value to the optimal number of threads based on the available cores.

Step 9

On the Run Settings page, choose whether to execute the task now or schedule it for a later time. Choose from the following Execute options:

  • Now—Choose this option to execute the job immediately. The tool is run and changes are applied on the network model immediately. Also, a summary report is displayed. You can access the report any time later using Actions > Reports > Generated reports option.

  • As a scheduled job—Choose this option to execute the task as an asynchronous job. Set these options:

    • Priority: Select the priority of the task.

    • Engine profiles: Select the engine profile as per your requirement. This section lists all the available asynchronous engine profiles.

    • Schedule: Set the time at which you want to run the tool.

    The tool runs at the scheduled time and using the selected engine profile. You can track the status of the job at any time using the Job Manager window (from the main menu, choose Job Manager). Once the job is completed, download the output file (.tar file), extract it, and import the updated plan file into the user space to access it (for details, see Import plan files from the local machine).

    Note

     
    Ensure that you save the plan file before you schedule the job. Any unsaved changes in the plan file are not considered when you run the tool as a scheduled job.

Step 10

(Optional) If you want to display the result in a new plan file, specify a name for the new plan file in the Display results section.

In the previous step:

  • If you have selected to run the task immediately, by default, the changes are applied on the current plan file. If you want to display the results in a new file, select the Display results in a new plan file check box and enter the name of the new plan file.

  • If you have scheduled the task to run at a later time, by default, the results are displayed in the Plan-file-1. Update the name, if required.

Step 11

Click Submit.

Table 1. Metric optimization options

Field

Description

Interfaces to optimize

Optimize utilization on interfaces

By default, Cisco Crosswork Planning optimizes all interfaces. You can restrict the optimized interfaces using this option. Choose the Optimize utilization on interfaces value as Core, or select the interfaces manually using Select manually.

Normal (Non-Resilient) options

Minimize maximum interface utilization

This default is usually the primary objective, and concentrates on reducing the utilization of the interface with the highest utilization.

Minimize # of interfaces with utilization > __ %

Often a small number of interfaces are bottlenecks in the network, and their utilizations cannot be reduced through rerouting. However, it is still desirable to reduce the utilization of other, under-utilized interfaces. This option tries to reduce all interface utilizations to below a specified utilization level, or, if this is not possible, to minimize the number of interfaces over this level.

Minimize average latency

If after the optimizations flexibility is available in the choice of metrics, Cisco Crosswork Planning uses this flexibility to minimize the average latency of the routes across the network. This is not user-configurable and is always on.

Enforce latency bounds

If checked, the choice of paths for each demand is restricted, if possible, to those demands with latency below the latency bound.

Failure (Resilient) options

Minimize maximum interface utilization

If checked, Cisco Crosswork Planning selects metrics to minimize the maximum interface utilization over all interfaces and all failure scenarios. If unchecked, only normal operation is optimized, and the remainder of the failure section is ignored.

Minimize # of interfaces with utilization > __ %

The number of interfaces with utilization (under any failure scenario) above a specified percentage is minimized.

Enforce no-failure utilization bound

If unchecked, maximum failure utilization is minimized with no consideration for utilization under normal operation. It is often convenient to check this option and place a bound on the utilization under normal operation, which Metric Optimization then satisfies, if possible.

Failure sets

This option determines the failure scenarios over which optimization is performed. You can select any combination of failures: All unprotected circuits, SRLGs, nodes, sites, ports, port circuits, parallel circuits, and external endpoint members.

Optimization type & traffic level options

Optimization type

Cisco Crosswork Planning can perform global or incremental metric optimizations.

  • Global—Creates optimal routes from scratch, and targets the old metrics afterward. Because Cisco Crosswork Planning can choose routes globally, this option tends to perform better under some circumstances, particularly when the target routes are poorly chosen. However, global optimization typically takes longer than incremental optimization.

  • Incremental—Uses the current routes as a basis from which improvements can be made. The target routes are not changed as radically as when using global optimizations, and therefore the number of metric changes from the metric targets is typically much smaller when using the incremental option.

Set metrics on interfaces

By default, Cisco Crosswork Planning sets or changes metrics on any of the core interfaces in the network to achieve its optimization goals. Alternatively, as provided by this option, Metric optimization restricts metric changes to the following interfaces: all, core, interfaces selected manually.

Traffic level

The traffic level over which the optimization is performed.

Non-optimized Interfaces options

Non-optimized Interfaces

For those interfaces that are not optimized, you can set the following:

  • Ignore

  • Minimize number of interfaces with util > __ %

  • Minimize number of interfaces with util > current + __ %

Other options

Target to current metrics

There are many sets of metrics that will result in equivalent sets of routes. (Doubling all metrics, for example, does not change routes.) Cisco Crosswork Planning selects between these sets of metrics by metric targeting. Metrics can be selected to match as closely as possible the current metrics in the network. This simplifies the changeover from one set of metrics to the next.

Enforce symmetric metrics

This option sets the two metrics on each interface of each circuit equal to one another. This constraint can reduce optimization performance. However, it ensures that demands from A (source) to Z (destination) and from Z to A (in the core) take the same path, and so the chances of a session between A and Z being interrupted by a failure is minimized.

Prevent edge leakage

This default option restricts how Cisco Crosswork Planning can change demand routes. If a demand starts by routing only through the core, or from the edge through the core to the edge, this option prevents the routing from being changed so that it routes through the edge in the middle of its path. This is usually a desired routing policy restriction.

Simulate after optimization

This default option performs a simulation analysis after optimizing metrics. The simulation analysis allows a detailed view, for example, of the utilizations under failure resulting from the new metric settings.

What to do next

See Metric optimization reports.

Tactical metric optimization

The Tactical metric optimization tool (Actions > Tools > Tactical metric optimization) is a reduced version of the Metric optimization tool that minimizes the number of changes and runs faster. The options for this tool are a subset of those for the Metric optimization tools.

The tool tries to find the most optimal solution it can. In general, the longer it runs, the better the result. The Time limit option tells the tool to stop looking for better solutions after the specified amount of time, and use the best solution it has found so far. If the option is not set, the tool continues to run until it runs out of solutions to explore, which can take a long time. If you need all available solutions to be explored, use the Metric optimization tool.

Metric optimization reports

Each time Metric optimization is run, a Metric-Opt report is automatically generated. You can access this information at any time by choosing Actions > Reports > Generated reports and then clicking the Design History link in the right panel.

A report is majorly categorized into the following sections:

Metric optimization report

Following information is available in the Metric-Opt Report section:

  • Options—Summarizes the options used to call Metric optimization. Some of these options (for example, the Output File and Report File) are only relevant when using the CLI tool.

  • Number of demands—Total number of demands in the plan.

  • Objectives—Summarizes the optimization objectives in order of priority.

Warnings

Warnings detected by Metric optimization might lead to misleading or undesirable results. Following are some of the warning message examples:

  • No Improvement in Optimization

    No routing improvement found: metrics unchanged

    Metric optimization was unable to improve on the metrics in the network. If the incremental option was specified and latency bounds were enforced, this could be because the target metrics violated latency bounds in ways that incremental optimization could not fix.

  • Optimization Exit Diagnostics

    Optimization performance may be limited by low edge metrics

    During the optimization, some desirable routes could not be selected because the given edge metrics would have caused edge leakage.

  • Optimization Constraints Violated

    <n> \{intra. inter\site core metrics exceed \crlf \{intra, inter\site-metric \{upper, lower\-bound

    One or more intrasite or intersite core metric bounds have been violated.

  • Maximum normal utilization exceeds specified bound

    The original plan had normal utilization above the specified bound, and Metric optimization was unable to reduce the normal utilization below this bound. If this occurs, Metric optimization tries to set normal utilization as low as possible. No worst-case optimization is performed because reducing utilization under the normal scenario is the highest priority.

  • <n> demands with non-zero bandwidth exceed latency bounds

    Because enforcing latency bounds is the highest optimization priority, this situation should not occur unless a latency bound is less than the shortest possible latency for a demand.

  • <n> demands with zero bandwidth exceed latency bounds

    Metric optimization does not always enforce latency bounds for zero bandwidth demands. These warnings can occasionally occur even if it is possible to find lower latency paths for the signaled demands.

  • Unrouted Demands

    <n> unroutable demands under normal operation

    There are <n> demands for which no route exists between source and destination, even under the No Failure scenario.

  • <n> unroutable demands under <m> circuit failure scenarios

    There are <n> demands for which no route exists between source and destination under <m> circuit failure scenarios. (Different demands might be unroutable under different circuit failures.)

  • <n> unroutable demands under <m> SRLG failure scenarios

    There are <n> demands for which no route exists between source and destination under <m> SRLG failure scenarios. (Different demands might be unroutable under different SRLG failures.)

  • <n> unroutable demands under <m> source/dest node failure scenarios

    There are <n> demands whose source and/or destination nodes fail under <m> failure scenarios. These demands clearly cannot be routed in these circumstances. (Different demands might be unroutable under different node failures.)

  • <n> unroutable demands under <m> non-source/dest node failure scenarios

    There are <n> demands for which no route exists between source and destination under <m> node failure scenarios, where the nodes that fail are intermediate nodes in the path of the demands, and are not source/destination nodes of the demands. (Different demands might be unrouted under different node failures.)

Routing summary

Summary statistics are displayed of the routes in network, both before (in parentheses) and after the optimization.

  • Core/Edge Max Utilization—The maximum percentage utilization over any interface in the core or edge network. The normal utilization is under the normal (no-failure) scenario, and the worst-case utilization is maximized over all failure scenarios in the failure set.

  • Latency—Median and average latencies over all routed demands, both in milliseconds and as a percentage of the latency of the smallest latency route possible.

    The latency of each demand’s routing is calculated as a percentage of the latency of the shortest possible route, by latency, for that demand. Under the percentage column, the median and average of these percentages are displayed.

  • Num of demands routed away from shortest path—The number of routes (out of all the demands routed) that do not follow the shortest path, by latency. This statistic is an indicator of how much the routes have been affected by utilization minimization as the primary criterion for optimization.

  • Num of demand routes exceeding latency bounds—The number of routes (out of all the demands routed) that exceed the latency bounds.

Metrics

The metric targeting choice is shown, together with the number of metrics different from the target metrics. Lists of interfaces for which metrics differ from the target metrics are displayed, together with both the target metric and the optimized metric. The metrics are separated into those on intrasite and intersite interfaces.