Simulation Overview

Network simulations

Network simulation is a predictive analysis technique that

  • enables what-if analysis to assess the outcomes of changes in the network model

  • supports capacity planning through simulations

  • helps with forecasting by projecting growth percentages onto demands, and

  • calculates demand routings and traffic distributions throughout the network based on the given traffic demand, network topology, configuration, and state.

Simulation is the fundamental capability of Cisco Crosswork Planning on which most of the other tools are built, including those for planning, traffic engineering, and worst-case failure analysis. The system supports a range of protocols and models, such as IGP, MPLS RSVP-TE, BGP, QoS, VPNs, and Multicast.

Examples

  • What-if analysis: You can examine what happens if you change any aspect of the network model, such as:

    • What happens if a link or a node fails?

    • What happens if you change a metric?

    • What happens if you change the topology?

    For more information, refer to Perform What-If Analysis.

  • Capacity planning with resiliency analysis: You can simulate what happens if a node, SRLG, LAG, or a site fails. Cisco Crosswork Planning has the Simulation analysis tool to automate this process and provide the analysis. Running the tool displays "worst-case" scenarios that highlight areas most at risk of congestion. The "Failure impact" view displays failures causing the worst case. For details, refer to Evaluate Impact of Worst-Case Failures.

  • Capacity planning and forecasting: Using the Create growth plans tool, you can apply a growth percentage to a demand or set of demands and project that growth into the future. For details, refer to Evaluate Impact of Traffic Growth.

Auto-resimulation

Auto-resimulation is a feature that

  • automatically triggers resimulation when any changes affect routing in a network, and

  • keeps simulation results updated in response to ongoing modifications.

Auto-resimulation is disabled by default in newly opened plan files.

Examples of events that trigger auto-resimulation

  • Changes in topology, such as adding and deleting objects or changing explicit paths

  • Changes to an object state, such as failing an object or making it inactive

  • Changes in numerous properties, such as metrics, capacities, and delay

Enable auto-resimulation by default

Complete these steps to enable auto-resimulation by default.

  1. Click at the top right corner.

  2. Enable the Auto-resimulate slider under the Simulator section.

    After you update this setting, it applies only to the current plan file. Each time you open this particular file, the same setting is used.

Run simulation manually

When any change is made in the plan file that affects or invalidates the current simulation, you can trigger a re-simulation manually. To do this, click the icon in the Network Design page.

States of plan objects

The state of a plan object affects the simulation and determines whether that object is operational.

There are three states available in Cisco Crosswork Planning plan objects.

  • Failed: Identifies whether the object is failed.

  • Active: Identifies whether the object is available for use in the simulated network. For example, an object might be unavailable because it has been set administratively down.

  • Operational: Identifies whether an object is operational. For example, an object might be non-operational because it is failed, is inactive, or because other objects on which it depends are not operational.

Columns in network summary tables

The Failed and Active columns in the network summary tables show a visual representation of their status. Likewise, the Operational column shows the calculated operational state. In each column, "true" indicates that the object is in that state. "false" indicates that it is not. The value of "true" or "false" for the Active state in the Interfaces table reflects the status of the associated circuit. The plot shows graphical representations of these states with either a white cross or a down arrow displayed inside a red circle.

These plan objects have the Active, Failed, and Operational columns:

  • Circuits

  • Nodes

  • Sites

  • Ports

  • Port circuits

  • SRLGs

  • External endpoint members

Failed state

A Failed state is a condition in network simulations where objects such as interfaces or circuits experience failure.

The quickest way to see the effects of failures in a simulated traffic view is to have demands in place, and then fail an object. When a failure occurs, the simulation reflects the changes immediately.

If you select an interface to fail, you are actually failing its associated circuit. To view the complete list of objects that can be failed, refer to the list in States of plan objects.

Figure 1. Failed circuit
Failed circuit example
Figure 2. Reroute of demand around a failed circuit
Reroute of demand around a failed circuit

Disabling demand rerouting

To specify that a demand should not reroute around failures, uncheck the Reroutable check box in the demand’s Edit page. This can be used as a way of including L2 traffic on an interface. For example, a one-hop, non-reroutable demand can be constructed over the interface to represent the L2 traffic. Other reroutable demands can be constructed through the interface as usual. If the interface fails, the L2 traffic is removed and the L3 traffic reroutes.

Fail or recover plan objects

This topic describes how to fail or recover objects of a plan file.

Before you begin

This table lists the objects that you can fail or recover.

Interfaces

Ports

Circuits

Port circuits

Nodes

SRLGs

Sites

External endpoint members
Procedure

Step 1

To fail a single object, click > Fail under the Actions column.

Step 2

After failing an object, the menu option changes to Recover. Use this option to recover the failed objects.

Step 3

Follow these steps to fail or recover multiple objects:

  1. Select the required objects.

  2. Click More actions > Fail or More actions > Recover to fail or recover objects.

Note

 

You can

  • select all objects, and fail or recover them

  • filter objects, and fail or recover them, or

  • select objects from the network plot, and fail or recover them.

The failed object is marked with a red circle and white X in the network plot (for example, see Failed circuit). The icon disappears when you recover the object.

Protect circuits from SRLG failures

You can protect circuits from being included in SRLG failures and SRLG worst-case analysis. However, there are differences in behavior, such as:

  • These circuits do not fail when an SRLG fails individually. However, they will fail if the circuit itself fails.

  • These circuits are protected from being included in Simulation analysis regardless of whether they are in an SRLG.


Note

This setting does not affect the routing of FRR SRLGs. For information on FRR SRLGs, see Optimize RSVP-TE Routing.

Procedure

Step 1

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

Step 2

Set the Protected property for circuits.

  1. In the Network Summary panel, select one or more circuits from the Circuits table.

  2. Click Edit icon.

    Note

     

    If editing a single circuit, you can also use the > Edit option under the Actions column.

  3. In the State field, check the Protected check box.

  4. Save the changes.

Step 3

Set the Network options property for protecting circuits included in SRLGs.

  1. Click in the toolbar or choose Actions > Edit > Network options.

  2. In the Redistribute routes across IGP process section under the Simulation tab, check the Exclude protected circuits from SRLG failure check box.

  3. Save the changes.

Active state

An active state indicates whether an object is available for measured or simulated traffic calculations.

An object can be inactive for several reasons:

  • It is administratively down.

  • It is a placeholder. For example, you might be planning to install an object and want its representation in the network plot.

  • It exists in a copied plan but was not present in the original discovered plan.

You can simultaneously change the active state of one or more objects. If you change the active state of an interface, you change its associated circuit.

Like failures, changing an object from active to inactive immediately affects demand routing and the Util sim column in the Interfaces tables (Inactive circuit).

Figure 3. Inactive circuit
Inactive circuit

Objects that can be set as Active

This is the list of objects that can be set as Active:

  • Circuits

  • Nodes

  • Sites

  • Ports

  • Port circuits

  • SRLGs

  • External endpoint members

  • Demands

  • LSPs

  • LSP paths

Set objects to Active or Inactive state

Complete these steps to set the state of the objects to Active.

Before you begin

Make a note of the list of objects whose State can be set to Active or Inactive by referring to the Active State section.

Procedure

Step 1

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

Step 2

In the Network Summary panel, select one or more objects from their respective tables.

Step 3

Click Edit icon.

Note

 

If editing a single object, you can also use the > Edit option under the Actions column.

Step 4

In the State field, check the Active check box to toggle it on or off.

A check mark indicates the object is active. To make it inactive, clear the check box.

Step 5

Save the changes.
The system updates the selected objects to active or inactive, reflecting their current state in your network design. If an object is active, the Active column in the Network summary table displays "true" for that object.

Operational state

The operational state identifies whether the object is functioning. You cannot set an operational state. It is automatically calculated based on the failed and active states.

  • Any object that is failed or inactive is operationally down.

  • If the object relies on other objects to function, its operational state matches the state of those objects.

This table lists how failure or inactivity of objects impacts operational status.

If this object fails or is inactive

These objects are operationally down

Node

circuits connected to the failed node

Site

sites, nodes, and circuits within the failed site

SRLG

objects within the failed SRLG

Port

port circuits that contain the failed port

Simulated capacity

A simulated capacity is a network capacity metric that

  • reflects the effective capacity of an object

  • takes into account network state, including any failures that may reduce capacity, and

  • is represented by the Capacity sim column in the Network Summary tables.

All utilization figures in the Interfaces, Circuits, and Interface Queues tables are calculated based on this value.

The Capacity column shows the configured physical capacity of interfaces, circuits, ports, and port circuits. Each circuit, port, and port circuit has a physical capacity that you can set in the Capacity field of the Edit window. The interfaces have a configurable capacity that you can set in the Configured capacity field. From these properties, a simulated capacity (Capacity sim) is derived for each object.

Simulated capacity calculation rules

There are a few rules to note regarding Capacity sim calculation.

  • If a circuit’s Capacity is specified, this becomes the Capacity sim of the circuit, and all other capacities (interface and constituent port capacities) are ignored. Specify circuit capacities instead of interface capacities to easily modify existing capacities. This is useful for build-out planning.

  • If the circuit has no Capacity, then its Capacity sim is the minimum of its constituent interface Capacity values. The Capacity of an interface is the sum of the Capacity values of the associated ports. If the interface has no ports or if the ports have no Capacity, it is the same as the interface's Configured capacity property.


    Note

    The field in the interface's Edit window is Configured capacity, while the column name in the Interfaces table is Capacity.

  • If two ports are connected explicitly by a port circuit, the Capacity sim of the port circuit is set to the minimum capacity of the three, which effectively negotiates down the capacity of each side of the connection.

  • In a LAG interface, if any of the constituent LAG members are operationally down, the interface Capacity sim column shows a value that is reduced by the aggregate capacity of all the LAG members that are down. For example, if a 1000-Mbps port of a four-port 4000-Mbps LAG is operationally down, the simulated capacity for that LAG interface becomes 3000 Mbps.


    Note
    If a pair of ports is considered in Capacity sim calculations, both must be operational to be considered.

Delay

Delay is a property that

  • indicates the time it takes for a data packet to travel from the source to the destination across a network path

  • can be set in the Add or Edit page of the Interfaces and Circuits, and

  • is indicated by the Delay column in the Interfaces and Circuit tables.

Asymmetric delay

Starting with the 7.2 release, Cisco Crosswork Planning allows you to set different delay values on interfaces associated with circuits. In other words, each interface in a circuit can have its own delay metric, rather than a single delay value for the circuit as a whole.

Columns related to delay

There are two columns related to Delay in the Interfaces and Circuits tables.

  • Delay: One-way transmission latency in milliseconds (ms).

  • Delay sim: (Derived) Simulated one-way transmission latency. All Cisco Crosswork Planning delay calculations that use the L3 circuit delay, such as Metric optimization, use the Delay sim value.