Simulation Overview

Cisco Crosswork Planning network simulations calculate 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. A number of protocols and models are supported, including IGP, MPLS RSVP-TE, BGP, QoS, VPNs, and Multicast.

This chapter focuses on the general features of Cisco Crosswork Planning simulations. The individual protocols and models are described in their respective chapters.

This section contains the following topics:

Use cases of network simulation

Network simulation is a concept that allows for predictive analysis of network changes. It

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

  • supports capacity planning through simulations, and

  • helps forecasting by projecting growth percentages on demands.

Examples

  • What-if analysis—You can examine what happens if you change any aspect of the network model. For example:

    • What happens if a link or a node fails?

    • What happens if you change a metric?

    • What happens if you change the topology?

    For details, 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 the "worst-case" scenarios that highlights areas most at risk of congestion. You will also get a "failure impact" view, detailing the failures that cause 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. Examples of such changes include:

  • 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

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

Enable auto-resimulation by default

Follow these steps to enable auto-resimulation by default.

  1. Click at the top right corner.

    Figure 1. Auto resimulation settings

  2. Enable the Auto-resimulate check box.

    After updating this setting, it applies to the specific plan file. Each time you open this particular file, the same setting is used.

Run simulation manually

Additionally, 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 is a condition that affects the simulation and determines whether an 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" means the object is in that state and "false" means it is not. Note that the "true" or "false" for Active state in the Interfaces table is reflective of the associated circuit. The plot shows graphical representations of these states with either a white cross or a down arrow 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,

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 2. Failed circuit
Figure 3. 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 window. 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 and recover objects

Follow these steps to fail or recover objects.

Before you begin

Make a note of the list of objects that can fail by referring to the States of plan objects section.

Procedure

Step 1

Select an object from its respective table.

Step 2

Under the Actions column, click the > Fail option.

In the network plot, notice a red circle with a white X on the object you failed (for example, see Failed circuit).

Step 3

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

Protect circuits from SRLG failures

You can protect circuits from being included in SRLG failures and SRLG worst-case analysis, though 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 on the right side, 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. Check the Protected check box, which is an option in the State field.

  4. Click Save.

Step 3

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

  1. Click Network options 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. Click Save.

Active state

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

An object can be inactive because:

  • 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 in the original plan that was discovered.

You can simultaneously change the active state of one or more objects. If you change the active state of an interface, you are actually changing 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 4. 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

Follow 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 on the right side, select one or more like 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 means the object is active; uncheck the box to make it inactive.

Step 5

Click Save.

Operational state

The operational state identifies whether the object is functioning. You cannot set an operational state; rather, 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 mirrors the state of those objects.

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

Simulated capacity refers to the calculated capacity of an object, taking into account network state, including any failures that may reduce capacity. This 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

When referencing the Capacity sim value, there are a few rules to note regarding its 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.

Simulated Delay

Simulated delay is the derived latency value, specifically within the context of L3 circuit delay calculations. This is indicated by the Delay sim column.

Delay is a property that can be set in the Circuit's Edit window.

Figure 5. Edit Circuit window

All Cisco Crosswork Planning delay calculations that use the L3 circuit delay, such as Metric optimization, use the Delay sim value.

Columns in the Circuits table

Description

Delay

One-way transmission latency over the circuit in milliseconds (ms).

Delay sim

(Derived) Entering a circuit Delay value copies it to the Delay sim column.