Demands
Feature |
Release Information |
Description |
---|---|---|
Private Demand/LSP Enhancements |
Cisco WAE Release 7.4.0 |
A new attribute called Require LSP is added to Demands properties table. When this attribute is set to True for a demand, the WAE Design simulation uses only LSPs to route this demand in both steady-state and under failures. If this is not possible, the demand is not routed. |
Because demands determine how traffic is routed through the simulated WAE Design model, creating realistic demands and demand meshes is imperative to the accuracy of other information that can be derived from WAE Design. As such, all defaults are set to create demands and demand meshes that best suit most network models.
Each demand is comprised of unique properties (keys) that define it, other properties, and traffic. The following list summarizes these, though for a complete list of properties, refer to the available columns in the Demands table.
Selected demand paths are blue. An “A” labels the source, and a “Z” labels the destination.
Unique Properties (Keys) |
Each demand is defined by a unique combination of these four properties. |
Name—By default, this is blank. |
|
Source—Nodes, interfaces, external ASes, or external endpoints. |
|
Destination—Nodes, interfaces, external ASes, external endpoints, or multicast destinations. |
|
Service class—User-defined classification of traffic, such as for voice or video. |
|
Commonly Used Properties |
Latency bound—Policy that sets the maximum permissible latency on a demand under normal operation. This property is used by WAE Design traffic engineering tools. |
Topology—Demands can be assigned to a specific IGP, and only route through interfaces that belong to that IGP. |
|
Active—Only active demands are routed during simulations. |
|
Reroutable—Enable/disable the routing of demands around failures. Turning off reroutes around failures might be useful, for example, when simulating Layer 2 traffic. |
|
Require LSP—If this option is selected, WAE Design simulation only uses LSPs in routing that demand. If this is not possible, the demand will not be routed. By default, this option is disabled. |
|
Tags—User-defined label that lets you group demands for subsequent processing. Most tools, for example, allow you to choose a set of tags on which to operate. |
|
Private LSP—If a demand is associated with a private LSP, the demand can only route through that LSP, and the only demand that is permitted to cross that LSP is this demand. You can associate an existing demand to an existing private LSP. The Private LSP drop-down list shows the private LSP that is currently associated with the selected demand. You can choose a different private LSP, or you can choose None to remove an associated LSP. |
|
Traffic |
By default, demands have zero traffic, so you must add the simulated traffic to them. |
Demand traffic belongs to the service class of the demand. |
|
Demand traffic can be set per traffic level. |
Demand Sources and Destinations
When creating sources and destinations, follow these recommendations:
-
For internal routing, use nodes.
-
For external ASes, use a combination of ASes, nodes, and interfaces. Using interfaces lets you specify the exact interface on which the demand traffic is going into or out of a node.
-
For more complex routing where multiple sources or destinations (and multiple failover scenarios) are required, use external endpoints.
-
For multicast routing, use multicast destinations.
If multiple interfaces are attached to a node and if a demand is sourced to or destined for that node, the traffic splits across one or more of those interfaces, depending on other properties, such as IGP metrics or BGP policies (on a peering circuit). You can, however, specify just one of those interfaces. Example of Demands Destined for a Node Versus an Interface shows an example of this difference between using nodes and interfaces. In this example, the interface destination is one of three interfaces going into the er1.atl node.
Note if using an interface as a source of a demand, the source is the inbound interface. If using an interface as the destination of a demand, the destination is the outbound interface.
Demand Meshes
Demand meshes are a time-efficient way of creating numerous demands for all or part of the network. By default, WAE Design creates a source-destination mesh among nodes, interfaces, external ASes, and external endpoints. There are also advanced options, such as the ability to use a different set of destinations to create the demand meshes.
Alternatively, you can import an existing <DemandMesh> table that contains estimated traffic. WAE Design uses these estimations to calculate a full mesh of demands.
Demand Latency Bounds
Each demand can have a latency bound, which is a policy that sets the maximum permissible latency on a demand under normal operation. These can then be used to guide the route selection of the traffic engineering tools. The Simulation Analysis tool can use these values to determine if latency bounds are violated when worse-case failures occur.
The Demands table has several Latency columns. Key ones are as follows:
-
Average Latency—Average latency over all ECMP subroutes.
-
Minimum Latency—Minimum latency over all ECMP subroutes.
-
Maximum Latency—Maximum latency over all ECMP subroutes.
-
Latency Bound—Maximum permissible latency on a demand.
-
Min Possible Latency—Total latency of the shortest path that the demand could take.
-
% Diff Min Possible Latency—Maximum latency minus the minimum possible latency expressed as a percentage of Min Possible Latency.
Visualizing Demands
To view demand paths in the network plot, select them in the Demands table. Their path highlight is blue. An “A” labels the source, and a “Z” labels the destination. If sites are nested, these “A” and “Z” labels appear in all relevant child sites.
When you select demands in the Demands table, their associated L1 circuit paths are highlighted in the network plot.
Demands are most commonly used to show how traffic reroutes around failures. A dashed line shows the rerouted demand.
Viewing Demand Plots
Demand routes can be complex because they can go through multiple sites that could hide the details of the path. For example, the network plot might not show the individual nodes traversed by the demand, as in Network View of Selected Demand. The demand plot offers an easier way to view end-to-end demands, letting you view the hops that the demands take without having to individually select sites to view them. For example, Demand Plot View shows the demand plot view of the same selected demand as in Network View of Selected Demand.
Procedure
Step 1 |
In the Demand table, select one or more demands. |
Step 2 |
Right-click and choose Plot Demands. |
Step 3 |
To move the plot horizontally or vertically, use the left/right arrows and up/down arrows. |
Step 4 |
To select all demands within the demand plot view, click Select Demands. To deselect all of these demands, click in an empty plot area. |
Step 5 |
To visualize multilayer L1 paths when plotting demands, use the following drop-down options:
|
What to do next
Viewing Shortest Paths and Shortest Latency Paths
For a description of shortest IGP paths and shortest latency paths, see IGP Simulation.
To View... |
Choose... |
Example |
---|---|---|
Shortest IGP path |
View > Demands > Shortest IGP Paths |
|
Shortest latency path |
View > Demands > Shortest Latency Paths |