The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
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
Some of the things you can do with a network simulation are as follows:
What-if Analysis—You can examine what happens if you change any aspect of the network model. For example:
Capacity Planning with Resiliency Analysis—You can simulate what happens if a node, SRLG, LAG, or a site were to fail. Cisco Crosswork Planning has the Simulation analysis tool to automate this process and provide the analysis. Once you run the tool, you will be able to see the "worst case" scenarios,
highlighting areas most at risk of congestion. Additionally, you will also get a "failure impact" view, detailing the failures
that cause the worst case. For details, see Evaluate Impact of Worst-Case Failures.
Capacity Planning and Forecasting—Using Cisco Crosswork Planning you can apply a growth percentage to a demand or set of demands and project that growth into the future. For details, see
Evaluate Impact of Traffic Growth.
Auto Resimulation
By default, auto-resimulation is disabled for the newly opened plan files. To set auto-resimulation to be enabled by default,
click at the top right corner and enable the Auto-resimulate check box. Once you update this setting, it applies to the specific plan file. Each time you open this particular file, the
same setting is used.
Figure 1. Auto Resimulation Settings
The types of changes that can be resulted in re-simulation are those that would typically affect routing in a network.
Changes in topology, such as adding and deleting objects or changing explicit paths
Changes to an object’s state, such as failing an object or making it inactive
Changes in numerous properties, such as metrics, capacities, and delay
In addition, 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 an object affects the simulation and determines whether an object is operational.
Failed State—Identifies whether the object is failed.
Active State—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 State—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.
The Failed and Active columns in the tables show a visual representation of their status. Likewise, you can show the Operational
column to show 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.
The Active, Failed, and Operational columns are available for the following objects:
Circuits
Nodes
Sites
Ports
Port circuits
SRLGs
External endpoint members
Failed State
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. The plot immediately displays where the traffic increases as a result (Failed Circuit), and the Util sim column in the Interfaces table reflects the traffic changes. Demands are then rerouted around the failure
(Reroute of Demand Around Failed Circuit).
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.
If you select an interface to fail, you are actually failing its associated circuit. To see the complete list of objects that
can be failed, see the list mentioned in State.
Figure 2. Failed Circuit
Figure 3. Reroute of Demand Around Failed Circuit
Fail and Recover Objects
To see the complete list of objects that can be failed, see the list mentioned in State.
To fail or recover objects, do the following:
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 cross icon on the object that you failed (for example, see Failed Circuit).
Step 3
Once failed, the menu option changes to > Recover. Use this option to recover the failed objects.
Protect Circuits within SRLGs
You can protect circuits from being included in SRLG failures and SRLG worst-case analysis, though there are differences in
behavior, as follows:
These circuits do not fail if you individually fail an SRLG as described in the preceding steps. However, if you fail the
circuit itself, it will fail.
These circuits are protected from being included in Simulation analysis regardless of whether they are in an SRLG.
Note that this setting has no effect on how FRR SRLGs are routed. 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.
In the Network Summary panel on the right side, select one or more circuits from the Circuits table.
Click .
Note
If you are editing a single circuit, you can also use the > Edit option under the Actions column.
Check the Protected check box. It is available as an option for the State field.
Click Save.
Step 3
Set the Network options property for protecting circuits included in SRLGs.
Click Network options in the toolbar or choose Actions > Edit > Network options.
Click the Simulation tab.
In the Redistribute routes across IGP process section, check the Exclude protected circuits from SRLG failure check box.
Click Save.
Active State
An active/inactive state identifies 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.
The complete list of objects that can be set to Active or Inactive is as follows:
Circuits
Nodes
Sites
Ports
Port circuits
SRLGs
External endpoint members
Demands
LSPs
LSP paths
Like failures, changing an object from active to inactive immediately affects how demands are routed, and affects the Util
sim column in the Interfaces tables (Inactive Circuit).
Figure 4. Inactive Circuit
Set Active or Inactive States
To see the complete list of objects whose State can be set to Active or Inactive, see the list mentioned in Active State.
To set the state of the objects to Active, do the following:
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 .
Note
If you are 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 in Active. Uncheck the check 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
The Capacity column displays 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.
The Capacity sim column is the calculated capacity of the object given the state of the network, which could include failures
that reduce capacity. All utilization figures in the Interfaces, Circuits, and Interface Queues tables are calculated based
on this Capacity sim value. 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. Specifying circuit capacities (rather than interface capacities) is the simplest
way to modify existing capacities, which is useful, for example, for build-out planning.
If the circuit has no Capacity, then its Capacity sim is the minimum of its constituent interface Capacity values. The interface
Capacity 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 displays
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
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 Circuits Table
Description
Delay
One-way transmission latency over the circuit in milliseconds (ms).
Delay sim
(Derived) If the circuit Delay value is entered, it is copied to the Delay sim column.
at the top right corner and enable the 
icon in the Network Design page.
> 
.
Feedback