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.
WAE Design network simulations calculate demand routings and traffic distributions through the network based on the given
traffic demand, network topology, configuration, and state. Simulation is the fundamental capability of WAE Design 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, Multicast, and Layer 1 (L1).
This chapter focuses on the general features of WAE Design simulations. The individual protocols and models are described
in their respective chapters.
Simulations can be performed under different simulation convergence modes (Fast Reroute, IGP and LSP Reconvergence, and Autobandwidth
Convergence), depending on which stage of the network recovery after failure is being investigated. If in Autobandwidth simulation
mode, the results for simulations with failures are identical to those in the IGP and LSP Reconvergence simulation mode. The
default simulation mode is IGP and LSP Reconvergence, and except where identified, the documentation describes this simulation
mode. For more information, see RSVP-TE Simulation.
This section contains the following topics:
Traffic Simulation
WAE Design uses demands to simulate traffic between source and destination endpoints within a network. Each demand has a specified
amount of traffic.
By default, an up-to-date simulation of an open plan is always available. Any change in the plan that affects or invalidates
the current simulation automatically triggers a resimulation. Types of changes that result in resimulations 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.
To toggle automatic resimulation on and off, do one of the following:
Click the drop-down arrow next to the Simulation On/Off icon (white arrow in green circle) in the Visualization toolbar.
Check or uncheck Auto resimulate to toggle it on or off.
Choose Tools > Simulator > Switch On/Switch Off.
State
The state of an object affects 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, T means the object is in that state and F means it is not.
Note that the T or F for Active state in the Interfaces table is reflective of the associated circuit. The plot shows graphical
representations of these states with crosses of various colors and fills.
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 Properties dialog box. 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.
You can simultaneously fail one or more objects of the same type. If you select an interface to fail, you are actually failing
its associated circuit.
Objects That Can Be Failed
Circuits
Nodes
Sites
Ports
Port circuits
SRLGs
L1 links
L1 nodes
External endpoint members
Failing and Recovering Objects
From the...
Fail Objects
Recover Objects
Context menu
Select one or more objects.
Right-click one and choose Fail.
Right-click in an empty plot area.
Choose All to recover all failed objects or individually select an object to recover it.
Properties dialog box
Select one or more objects.
Right-click one and choose Properties.
Check Failed and click OK.
Select one or more objects.
Right-click one and choose Properties.
Uncheck Failed and click OK.
Protecting 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 RSVP-TE Optimization.
Procedure
Step 1
Set the Protected property for circuits.
Select one or more circuits.
Right-click a selected circuit and choose Properties.
Check Protected and click OK.
Step 2
Set the Network Option property for protecting circuits included in SRLGs.
Choose Edit > Network Options or click the Network Options icon in the Visualization toolbar.
Click the Simulation tab.
Check Exclude protected circuits from SRLG failure and click OK.
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.
Objects That Can Be Set to Inactive
Circuits
Nodes
Sites
Ports
Port circuits
SRLGs
L1 links
L1 nodes
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).
Setting Active or Inactive States
Procedure
Step 1
Right-click one or more like objects from their respective tables.
Step 2
In the Properties dialog box, check the Active check box to toggle it on or off. A check mark means the object is active. Then click OK.
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 Properties dialog box. 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 Property dialog
box 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.
If two ports are connected implicitly by an L1 circuit, the Capacity Sim of the two ports is set to the minimum Capacity
of the two, which again, 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 and Distance
Both Delay and Distance are properties that can be set in the circuit Properties dialog box. To automate the process of setting
these, use the Latency and Distance Initializer.
All WAE Design delay calculations that use the L3 circuit delay, such as Metric Optimization, use the Delay Sim value.
Circuits Table Column
Description
Delay
One-way transmission latency over the circuit in milliseconds (ms).
Distance
Distance of the circuit in kilometers (km).
Delay Sim
(Derived) If the circuit Delay value is entered, it is copied to the Delay Sim column.
If no Delay is explicitly set, the Delay Sim column in the Circuits table is copied from the L1 Delay Sim column of the mapped
L1 circuit (if one exists), which is based on the L1 circuit path that is currently the active path.
If no Delay is explicitly set and there is no mapped L1 circuit, the Delay Sim value in the Circuits table is copied from
the maximum Delay Sim property of all associated port circuits. If none of these port circuits is mapped to an L1 circuit,
then the Delay Sim value is set to 0.
If there is no circuit Delay value, no associated L1 circuits, and no associated port circuits with Delay Sim values, the
Delay Sim value is 0.
Distance Sim
(Derived) If the circuit Distance value is entered, it is copied to the Distance Sim column.
If no Distance is explicitly set for the circuit, the Distance Sim column in the Circuits table is copied from the L1 Distance
Sim column of the mapped L1 circuit (if one exists), which is based on the L1 circuit path that is currently the active path.
If the Distance is not specified (na) and if there are no L1 circuits mapped to the circuit, the Distance Sim column is 0.
Latency and Distance Initializer
Following is the default behavior for the Latency and Distance Initializer. If there are no Longitude and Latitude available
for use, the Distance and Delay properties are set to zero.
L1 defaults
The current L1 circuits Delay and Distance properties are removed unless Keep existing distances if available is checked.
The L1 node and L1 waypoint Longitude and Latitude properties are used to estimate the L1 distances. If an L1 node does not
have these properties set, the shortest distance calculation is based these same properties of its immediate parent site,
if applicable. (L1 nodes are not required to have parent sites.) The L1 link delays are calculated from these distances.
Each L1 circuit path’s Distance Sim and Delay Sim columns are calculated as the sum of the distances and delays of L1 links
over which the L1 circuit path is routed.
L3 defaults
L3 circuit delays and distances are inherited from L1 circuits if there are L1 circuits mapped to the L3 circuits. Otherwise,
the L3 delay and distance are estimated using the shortest distance between nodes at the endpoints of the circuits. If a node
does not have Longitude and Latitude properties, the calculation is based on these same properties of its immediate parent
site, if applicable. (Nodes are not required to have parent sites.) Thus, if you have an L1 model, the delays and distances
are more precise because the physical paths that the L3 circuits take are known.
ITU G.826 adjustments are used to convert L3 circuit distance (d) to an adjusted circuit distance (r) as follows.
If d < 1000, set r = 1.5 * d
If 1000 <= d <= 1200, set r = 1500
If d > 1200, set r = 1.25 * d
If this option is unchecked, set r equal to d.
Both the L3 and L1 delays are calculated to be the speed of light along a distance r, multiplied by the speed of light in
medium correction factor (between 0 and 1). The default for this correction factor is 0.67.
Procedure
Step 1
This initializer can act on two different selected object types (L1 links and L3 circuits), so the defaults for the dialog
box differ, depending both on selections and on how you access it. Regardless of the method, you can modify your selection
options once the dialog box is opened. Following are guidelines for having the dialog box open with the most desirable defaults.
To Calculate...
Select These Objects
Choose
L1 link distance and delay, and L3 circuit delay
No selections
or
One or more L1 links and one or more L3 circuits
Initializers > Latency and Distance.
L1 link distance and delay
No selections
or
One or more L1 links
Right-click an L1 link and choose Initialize Latency.
L3 circuit delay
No selections
or
One or more L3 circuits
Use one of these options:
Right-click an L3 circuit and choose Initialize Latency.
Right-click a circuit or interface and choose Properties. Click the Estimate button. This option is specific to L3 circuits.
Step 2
In each area, Layer 1 and Layer 3, verify or change your selection to act on the desired objects.
For L1 links, the default is to delete distances. To keep them, check Keep existing distances if available.
For L1 circuit paths, the default is to inherit distance and delay from L1 links. If desired, use the L1 Links drop-down list
to base these calculations on all, selected, or tagged L1 links. If you do not want the distance and delay set, choose None.
For L3 circuits, use the Circuits drop-down list to calculate L3 circuit delay and distance for all, selected, or tagged L3
circuits. If you do not want the delay or distance set, choose None.
Verify the inclusion ITU G.826 adjustments in the calculation, which is the default and which is usually left unchanged.
Step 3
For both L1 links and L3 circuits, verify or change the default speed of light factor of 0.67. This is usually left unchanged.
Then click OK.