Simulate Traffic Flow from Source to Destination Using Demands

Demands

A demand is a network modeling object that

  • describes the source and destination of a potential traffic flow across a network

  • determines how traffic is routed through the simulated model, and

  • contains properties and classifications that influence simulation and analysis accuracy.

Since demands determine how traffic is routed through the simulated model, creating realistic demands and demand meshes (refer to Demand meshes) is imperative to the accuracy of other information that can be derived from Cisco Crosswork Planning. As such, all defaults are set to create demands and demand meshes that best suit most network models.

A route simulation determines the routes that this traffic takes from the source to the destination, which are determined by the topology, the routing protocols, and the failure state of the network. To model IGP routing, these sources and destinations are nodes or interfaces within the topology. To model basic inter-AS routing, the sources and destinations are neighboring external ASes, peering nodes in these ASes, or interfaces to these peering nodes.

Each demand has a specified amount of traffic. The demand traffic is the basis for many of the Cisco Crosswork Planning simulation and traffic engineering tools. An accurate set of demands and demand traffic is essential for effective planning, designing, engineering, and operating of a network. Accurate knowledge of demands is essential for accurate traffic trending and traffic growth predictions. There are several methods for putting this traffic into the demands, including the Demand deduction tool, which calculates a realistic amount of per-demand traffic based on measured traffic.

Demand properties and visualization

Each demand consists of unique properties (keys) that define it, additional properties, and traffic. This table summarizes these. For a complete list of properties, refer to the available columns in the Demands table.

Table 1. Demand properties

Property

Description

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.

Commonly used properties

  • Service class: User-defined classification of traffic, such as for voice or video.

  • Latency bound: The policy that sets the maximum permissible latency on a demand during normal operation. This property is used by Cisco Crosswork Planning traffic engineering tools.

  • Topology: Demands can be assigned to a specific IGP, and only route through interfaces that belong to that IGP.

  • 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.

  • Active: Only active demands are routed during simulations.

  • Reroutable: You can enable or disable the routing of demands around failures. Disabling reroutes might be useful in some situations.

  • Require LSP: If this option is selected, Cisco Crosswork Planning 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.

Traffic

By default, demands have zero traffic. You must add simulated traffic to them.

Demand traffic belongs to the service class of the demand.

Demand traffic can be set per traffic level.

Selected demand paths are shown in blue color. An “A” labels the source and a “Z” labels the destination.

Figure 1. Demand route
Demand route example

Recommendations for demand sources and destinations

Use these recommendations when creating sources and destinations for demand routing:

  • For internal routing, use nodes as sources and destinations.

  • For external ASes, use a combination of ASes, nodes, and interfaces. Specify the exact interface on which the demand traffic enters or exits a node by using interfaces.

  • For complex routing requiring multiple sources, destinations, or failover scenarios, use external endpoints.

  • For multicast routing, use multicast destinations.

If multiple interfaces are attached to a node and a demand is sourced to or destined for that node, 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.


Note

If using an interface as a source of a demand, it refers to the inbound interface. If using an interface as the destination of a demand, it refers to the outbound interface.

Demand meshes

Demand meshes enable you to create numerous demands efficiently for the entire network. By default, Cisco Crosswork Planning 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.

Demand latency bounds

A demand latency bound is a traffic engineering policy that

  • sets the maximum permissible latency on a demand under normal operation

  • guides route selection of the traffic engineering tools, and

  • helps the Simulation analysis tool determine if latency requirements are violated in worst-case failure scenarios.

Demands table latency measurements

Each demand can have a latency bound. The Demands table provides several Latency columns. Key ones are:

  • Average latency: Average latency over all ECMP subroutes.

  • Minimum latency: Minimum latency over all ECMP subroutes.

  • Maximum latency: Maximum latency over all ECMP subroutes.

  • 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.

  • Latency bound: Maximum permissible latency on a demand.

  • Diff latency bound: Latency bound minus the Maximum latency.

Use cases of demands

Demands are used in network planning to support these use cases.

Use cases of demands

Purpose

Suggested Steps to Take

Model discovered networks

  1. Create a demand mesh based on where the traffic originates. For example, if all traffic is between edge routers, create a demand mesh between those edge routers. For more information, refer to Create a demand mesh.

  2. Set the demand traffic manually or using the Demand Deduction tool. For more information, refer to Modify demand traffic and Estimate demand traffic using demand deduction.

Model future usage in the network

  1. Create a demand mesh. For more information, refer to Create a demand mesh.

  2. After setting the traffic, use the Cisco Crosswork Planning tools for growing the traffic and then analyze the effects on the network. You can import demand growth, you can modify selected demand traffic to emulate growth, or you can use demand groupings and other forecasting tools. For more information, refer to Evaluate Impact of Traffic Growth.

Design networks

  1. Create a demand mesh. For more information, refer to Create a demand mesh.

  2. Set the demand traffic using methods described in Simulate traffic using demands.

Analyze existing plans

Use a variety of Cisco Crosswork Planning tools that rely on demand traffic.

Create demands and demand meshes

Create a demand

Use this task to add a new demand to your network plan via the Network Design page.

Before you begin

All selections and entries are optional except for identifying the source and destination.

Procedure

Step 1

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

From the toolbar, choose Actions > Insert > Demands > Demand.

Alternatively, in the Network Summary panel on the right side, click Add icon > Demands in the Demands tab.

Step 2

Enter the demand name.

Step 3

Specify the type of source and destination (node, interface, external AS, or external endpoint). Select additional Source and Destination details as needed.

Figure 2. Source and destination options
Source and destination options for demands

Step 4

Select a service class. If there are no service classes, create a new service class and select it. For instructions on creating a new service class, refer to Create service classes.

Step 5

Enter a value for the latency bound.

Step 6

Choose a topology to restrict the demand routes only to interfaces or LSPs belonging to that topology. The default is unrestricted routing.

Step 7

Retain the Active default to include the demand in Cisco Crosswork Planning simulations, or uncheck Active to exclude this demand from simulations.

Step 8

For each traffic level, click Edit to specify the amount of traffic. You can also leave it empty for the Demand deduction tool to complete. Specify the growth rate you want to use for forecasting purposes. For more information, refer to Evaluate Impact of Traffic Growth.

Step 9

Click Add to create the demand.

The new demand is created and appears in your plan, ready for simulation and analysis.

Create a demand mesh

Complete these steps to add a demand mesh to your network plan via the Network Design page.

Procedure

Step 1

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

Step 2

From the toolbar, choose Actions > Insert > Demands > Demand mesh.

Alternatively, in the Network Summary panel on the right side, click the Demands tab, and then click Add icon > Demand mesh.

Step 3

In the Demand mesh details panel:

  1. Enter a demand name. By default, no name is set to prevent the creation of many demands using the same name. If you need to identify a specific area of the network, such as a VPN, assigning names can be helpful. However, leaving demands unnamed reduces the chance of creating a large number of demands that have the same name.

  2. Select a service class.

  3. Select a topology.

Step 4

In the Source panel:

Select one or more sources from the Source check boxes. Options include Nodes, External ASes, and External Endpoints. By default, all options are selected. Also, all available nodes, external ASes, and external endpoints are selected. To customize your selection, use the Edit button next to each option.

Step 5

In the Destination panel:

  1. To create demands for destinations that differ from the sources, check the Specify separate set of destinations check box and provide the required details.

  2. To create demands in only one direction, uncheck the Also create demands from destination to source check box. This applies only when you select a different set of destinations.

Step 6

Expand the Other options panel and make the required changes.

  • Delete existing demands with same name: Deletes all existing demands before new ones are created. The default (unselected) is to keep the existing demands and add only new ones.

  • Use interface endpoints to/from external AS nodes: When creating demands for external ASes, use a source/destination type of interface, and create a demand for all interfaces connected to each node in the external AS. For information on AS relationships and routing policies, refer to Simulate BGP Routing.

  • Respect AS relationships: If checked, keep the existing AS relationships defined by the Routing Policy (default). If unchecked, recreate the AS relationships. The Routing policy property is defined in the Edit AS Relationships window. For more information about AS relationships and routing policies, refer to Simulate BGP Routing.

  • Respect external mesh settings: If checked, keep the existing External mesh settings defined for external AS meshes (default). If unchecked, recreate the external AS mesh. The External mesh property is set in the Edit AS window.

  • Include demands to self: Creates demands that have the same source and destination node (default).

Step 7

Save the changes.

Create demands for LSPs

Use this task to add demands for LSPs in a plan file.

Procedure

Step 1

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

Step 2

In the Network Summary panel on the right side, click the LSPs tab.

Step 3

Click Add icon and choose Demands for LSPs.

Step 4

Select the LSPs over which you want to run the demands.

Step 5

Select the service class for the resulting demands.

Step 6

Select the traffic for the newly created demands.

  • Traffic equal to the LSP setup bandwidth

  • Traffic equal to the LSP measurements

  • Zero, which is appropriate if you need to insert demand traffic in other ways, such as using Demand Deduction, importing it, or manually modifying it.

Step 7

To remove the restriction of setting these demands to only these LSPs, uncheck Mark LSPs as private. If you do not uncheck this check box, the LSPs will use only the resulting demands.

Step 8

Submit your changes.
Demands are created for selected LSPs and applied according to traffic settings and service class.

Set demand latency bounds

Use this task to set fixed latency bounds for demands within a network plan to control traffic latency and support performance objectives.

Use the Edit Demands page to set demand latency bounds to fixed values. All values are in milliseconds (ms).

Procedure

Step 1

Open the plan file (refer to 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 demands from the Demands table.

Step 3

Click Edit icon and select the required Demands.

Note

 

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

Step 4

To set a fixed value for the latency bound, enter a value in the Latency bound field.

To delete a latency bound, delete the text in this field.

Step 5

Save your changes.

Visualize demands in the network plot

Use this task to visualize demand paths in the network plot to understand traffic flows.

Demand paths represent specific data flows across the network. By visualizing these paths, you can quickly identify source and destination points and inspect how demands traverse through nested sites.

Procedure

Step 1

In the Network Summary panel on the right side, select the demands you want to visualize from the Demands table.

Selected demands appear as blue arrows in the network plot. The source is labeled as “A” and the destination is labeled as “Z”. If sites are nested, these “A” and “Z” labels appear in all relevant child sites.

Figure 3. Demand route
Demand route

Step 2

Hover over any selected demand in the Network Summary table to highlight its path in the network plot.

Step 3

To view only the nodes participating in the selected demand, perform these steps.

  1. Check the Participating only check box in the network plot.

    Figure 4. Participating only nodes
    Participating only nodes

  2. To return to the previous view, uncheck the Participating only check box or check the Show Groups check box.

The network plot displays selected demand paths with clear source and destination labels, allowing for rapid analysis of traffic flows.

Traffic rerouting

Traffic rerouting is a network behavior that

  • automatically redirects demands when a failure occurs, and

  • uses visual indicators to differentiate between rerouted and overlapping routes.

Demands are typically used to show how traffic reroutes around failures. In a network plot, a blue dotted line represents the rerouted demand, while a brown dotted line represents a route that overlaps with another route.

Figure 5. Rerouted demands
Rerouted demands

View shortest IGP and latency paths, and overlapped paths

Use this task to distinguish demand paths in the network plot based on IGP, latency, and path overlap.

Viewing different path types in the network plot enables quick understanding of how demands traverse the network and aids in troubleshooting.

For a description of shortest IGP paths and shortest latency paths, refer to Simulate IGP Routing Protocol.

Procedure

Step 1

In the network plot, click the Map options icon ().

Step 2

Under the Demands tab, check the relevant options:

  • Simulated paths: Displays the simulated demand paths. By default, this option is selected.

  • Shortest IGP paths: Displays the shortest IGP path for demands.

  • Shortest latency path: Displays the shortest latency path for demands.

Step 3

In the Network Summary panel, select the demands from the Demands table.

Step 4

Observe the network plot:

Figure 6. Shortest IGP and latency paths, and overlapped path
Shortest IGP and latency paths, and overlapped path
The network plot displays the selected demand's path with distinct color-coded arrows: dark green for shortest IGP, light green for shortest latency, and brown for overlapped paths.

Demand traffic

Demand traffic is the amount of traffic a demand is attempting to propagate through the network. For example, demand traffic is used to calculate interface utilizations during simulations. By default, demands have no traffic, and thus there is no simulated traffic.

The Demand deduction tool is the most complex and powerful way to add demand traffic. It estimates demand traffic from measured traffic values and enables accurate modeling in network simulations.

Traffic levels

Traffic levels are a way to represent and manage different traffic demand scenarios within the plan file. They enable flexible analysis and planning for different traffic scenarios.

You can create multiple traffic levels and associate demands with specific traffic levels. The traffic level displayed determines what is displayed in the plot and table calculations. For example, consider a totally static network that has no changes in topology or routing protocols. Throughout a day, the only thing that changes from one plan to the next is the traffic level. Thus, you can store traffic levels for different times of day all in a single plan file. Then, you can view the different states of the network from a single plan file by switching the view between different traffic levels.

Create and select traffic levels

Use this task to create traffic levels that can be globally available for an opened plan file.

Procedure

Step 1

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

Step 2

In the toolbar, select Manage traffic levels from the Traffic level drop-down list, or click Actions > Edit > Traffic > Traffic levels.

Step 3

Click Add icon to add a new traffic level.

An empty row appears.

Step 4

Enter the name and click Save.

The newly created traffic level appears in the Traffic level drop-down list in the toolbar.

Step 5

Select the traffic level from the Traffic level drop-down list.

Note

 

You can view a maximum of 200 traffic levels in the plan file.

The selected traffic level is used when visualizing the network topology and running computations in the network summary tables.

What to do next

(Optional) Assign the newly created traffic level to specific demands or use it to review network scenarios for different times of a day.

Simulate traffic using demands

In this task, we identify demand route in the network plot, determine which service classes are associated with demands, and read demand traffic and latency, and identify demand route in the network plot.

Several Cisco Crosswork Planning tables have columns that identify how much traffic is being carried or what percentage of the capacity is being utilized. For example, the Interfaces table has a Util sim column that reflects simulated traffic utilization. The two basic inputs to the simulation are the network configuration itself and a set of demands. A demand is a request for a specified amount of traffic to be sent from one node, the source, to another node, the destination. The routes taken are based on traffic, topology, network health, as well as the protocols used.

Procedure

Step 1

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

Step 2

In the Network Summary panel on the right side, click the Demands tab to show the Demands table.

Step 3

Click the demand from er1.bos to er1.hst.

The network plot shows this demand from "bos" to "hst" sites using a blue arrow to show the route, an A to show the source, and a Z to show the destination.

Figure 7. Demand route
Demand route

Step 4

Show the Service class column:

  1. Click the Show/hide table columns icon (Show/Hide Columns Icon).

  2. In the Search field, enter the word “service”. The Service class column name appears.

  3. Select the Service class check box

Step 5

Click the Service class column heading to sort demands by service class.

Step 6

Read the Traffic column values to determine how much traffic each demand is attempting to route.

Step 7

Determine the sum of the delays for all the interfaces on the longest path taken by each demand:

  1. In the Demands table, click the Maximum latency column heading and notice the values. For example, select a demand with maximum latency value of 23.

  2. Choose > Filter to interfaces. The Interfaces table opens and shows only the interfaces included in this demand.

  3. Click the Show/hide table columns icon (Show/Hide Columns Icon) and select the check box for the Delay sim column.

    The Delay sim column appears on the Interfaces table.

  4. Notice that the sum of Delay sim values of all interfaces is equal to the maximum latency of the corresponding Demand. In this case, 23.

Clear the filter once you have completed the above steps.

Step 8

In the Demands table, notice the er1.sea to er1.key demand takes four equal-cost multipath (ECMP) routes. The number 50% indicates that 50% of the split demand is flowing through each of these circuits.

Select the Participating only check box in the network plot to view the details of the demand route. When you select this option, the network plot displays only the nodes associated with the demand route.

Figure 8. ECMP demand route
ECMP demand route

Modify demand traffic

You can modify demand traffic to determine the effects such changes in traffic have on the network. These modifications can be applied to regions or sites, or they can apply uniformly over the network. For example, you might increase the demand traffic to plan for future traffic growth by simulating an overall traffic growth trend. Another example might be to determine the network impact of an anticipated increase in sales of a particular service, such as video on demand.

You have numerous options for modifying demand traffic, all from the same window. The changes that you make apply to the selected demands for the current traffic level. You can modify demand traffic to either fixed values or to their relative values.

Modify fixed demand traffic

Use this task to modify fixed demand traffic.

Procedure

Step 1

Open the plan file (refer to 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 demands from the Demands table.

Step 3

Click Edit icon.

Note

 

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

Step 4

Under the Traffic section, click Edit under the Actions column.

Figure 9. Modify demand traffic
Modify demand traffic

Step 5

For each applicable traffic level, enter the desired amount of simulated traffic in the Traffic field and click Save.

Step 6

Click Save on the Edit Demand page.

Modify fixed or relative demand traffic

Use this task to modify the demand traffic to a fixed or relative value using the Modify demand traffic initializer.

Procedure

Step 1

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

Step 2

From the Traffic level drop-down list in the toolbar, select the traffic level you want the changes to apply to.

Step 3

From the toolbar, click Actions > Initializers > Modify demand traffic to open the Modify Demand Traffic page.

Step 4

Select the demands for which you want to modify the traffic. By default, all demands are selected. Deselect all and select the required demands.

Step 5

Click Next.

Step 6

Select one of the options listed in Demand traffic modification options and choose a relevant value.

Step 7

Submit your changes.
Demand traffic modification options
This table lists the available options for modifying demand traffic. Except for the percentage option, all values are in Mbps.
Table 2. Modify demand traffic options

Option

Description

Change traffic by __ %

Change traffic by a specified percentage. Positive percentages add to the traffic, and negative percentages subtract. For example, if the traffic were 1000 Mbps and you entered –10, the traffic would be reduced to 900 Mbps.

Add

  • Add __ Mbps in total, proportionally: Add a set amount of traffic spread over all demands in proportion to their current traffic. For example, if one demand had 1000 Mbps of traffic and the other had 2000 Mbps, and if you added 50 Mbps proportionally, one would have 1016.67 Mbps and the other would have 2033.33 Mbps.

  • Add __ Mbps in total, uniformly: Add a set amount of traffic uniformly to all the demands. For example, if one demand had 1000 Mbps of traffic and the other had 2000 Mbps, and if you added 50 Mbps uniformly, one would have 1025 Mbps and the other would have 2025 Mbps.

Set traffic to

  • Set traffic to __ Mbps each: Set traffic to a fixed value.

  • Set traffic to __ Mbps in total, proportionally: Set traffic to a specific value that is spread proportionally over all demands. For example, if one demand had 1000 Mbps of traffic and the other had 2000 Mbps, and if you set them to 4000 Mbps proportionally, one would have 1333.33 Mbps and the other would have 2666.67 Mbps.

  • Set traffic to __ Mbps in total, uniformly: Set a specified amount of traffic, in Mbps, uniformly to all the demands. For example, if one demand had 1000 Mbps of traffic and the other had 2000 Mbps, and if you set them to 4000 Mbps uniformly, they would both be 2000 Mbps.

Demand traffic modification example

This example details the effects of modifying the demand traffic of the selected demands by 50%.

Note the values in the Traffic column for the demands: 35.62, 50.31, and 63.12 Mbps.

Figure 10. Demand traffic
Demand traffic

To increase the demand traffic by 50%, enter 50 in the Change traffic by ___ % field. Notice that the values in the Traffic column have increased by 50% to 53.43, 75.46, and 94.68 Mbps.

Figure 11. Demand traffic increased by 50%
Demand traffic increased by 50%

Demand deduction

A demand deduction is a Cisco Crosswork Planning tool that

  • estimates demand traffic based on available measurements from network interfaces, queues, and LSPs, and

  • adjusts results for accuracy depending on the type and availability of measurements.

Network models contain traffic measurements on the discovered network. Traffic can be measured on interfaces, interface queues, and RSVP LSPs, as well as on general traffic flows, such as from LDP LSPs. You can use the Demand deduction tool to estimate demand traffic based on any of these measurements.

The accuracy and usefulness of the results depend on factors such as the amount and type of available measured traffic. For example, interface measurements are most often available, but LSP measurements might provide more information. The results also depend on the accuracy of the demand mesh and the routing model.

Typically, you only have interface traffic measurements. In this case, the individual demands estimated by Demand deduction are not necessarily accurate. However, aggregates of demands can be highly accurate. For example, you can predict the overall utilization after a failure, a topology change, or a metric change, even if the underlying demands individually are not reliable.

For more accuracy of individual demands, include point-to-point measurements, such as for RSVP LSPs or LDP flow measurements. Also, it is useful to combine different types of measurements together for use in Demand Deduction. Interface measurements are generally the most accurate measurements available, and if included in a Demand deduction, can correct for missing or inaccurate LSP or flow measurements.

Note that you can also use Demand deduction to set Traffic balance (%) values for external endpoint members that are set to a Deduce Traffic type.

Differences in measured and simulated traffic

Demand deduction relies on accurate topologies, demand meshes, and traffic measurements. These factors influence whether simulated traffic matches measured traffic and affect demand deduction accuracy.

You can see how close these values are by showing the Abs meas diff and Meas diff/cap (%) columns in the Interfaces table.

  • Abs meas diff: The difference between measured traffic (Traff meas) and simulated traffic (Traff sim).

  • Meas diff/cap (%): The absolute measured difference expressed as a percentage of capacity.

Causes for discrepancies between measured and simulated traffic

If these columns show large values, one of these situations likely exists:

  • Inaccurate measurements: Different measurements, for example of traffic through different interfaces, can be made at slightly different points in time. Fluctuations in traffic levels might take place between the times that measurements are being taken. This means that measurements could be inconsistent with one another. Usually, these inconsistencies are small and do not seriously affect the Demand deduction results.

  • Insufficient measurements: A network typically contains more demands than measurements. As a result, many solutions will fit the observed data well. Demand deduction chooses between possible solutions using knowledge of typical behavior of point-to-point traffic.

  • Incorrect network configurations: If the network topology is incorrect in the plan file, the simulated routes would naturally be incorrect and measurements would not be adequately interpreted.

  • Unbalanced ECMP: ECMP hashing can result in imperfect load balancing. Demand deduction, however, distributes traffic evenly across ECMPs.

  • Static routes: Cisco Crosswork Planning does not model static routes. If these are present, demands routes might be simulated incorrectly, leading to deduction errors.

  • Incomplete demand meshes: Demand meshes do not contain nodes even though traffic is routed between those nodes.

  • Inappropriate priorities: In the Demand Deduction window, you have the option to set the priority for calculations as 1 or 2. Cisco Crosswork Planning first uses the measurements identified as Priority 1 to calculate the demands. Therefore, if the priority settings do not match the consistency of the traffic measurements in the network, the simulated traffic measurements will be less than optimal.

Demand deduction warnings

Demand deduction displays warnings for misleading or undesirable results.

  • AS “(AS name)” contains both dynamic LSPs and interface traffic. Interface traffic in AS has been ignored.

    Routing of dynamic LSPs is non-deterministic. So it is not possible to make use of both measured interface traffic and measured dynamic LSP traffic for LSPs that may (or may not) traverse these interfaces. If the network contains an AS with both dynamic LSPs and interface traffic, this warning is issued. The interface traffic is not used.

  • Some interface measurements exceed capacities by as much as (percent).

    This warning is issued if a specified measurement exceeds the corresponding circuit capacity.

Strategies for minimizing differences between measured and simulated traffic

Demand deduction estimates demands that predict interface utilizations under incremental changes to the topology, including failures, metric changes, or design changes, such as adding a new express route. If only interface measurements are available, you might fine-tune the Demand deduction calculations to get better results, especially for site-to-site traffic.

To enhance the accuracy of Demand deduction results, consider these suggestions:

  • Include RSVP LSP or LDP measurements in the network discovery process.

  • Restrict demand meshes to exclude demands that are known to be zero.

    For example, if you know that core nodes do not source traffic, then exclude core nodes when creating the demand mesh.

  • Check the Nodes table to see if there is a node where the measured traffic going into it (Dest traff meas) and out of it (Source traff meas) are very different. Ensure these nodes are included in the demand mesh because they are either sources or destinations for traffic.

  • On the Demand Deduction page, set the most consistent measurements to a Priority 1. The most reliable measurements are usually interface measurements. Likewise, LSP measurements are end-to-end, and thus also generally highly reliable. You can set multiple measurements to priority 1.

    For example, if flow measurements are inconsistent and interface measurements are very consistent, set interface measurements to Priority 1 and the flow measurements to Priority 2.

  • If only a few measurements are available or if there are many inaccurate measurements, the tool sometimes estimates more traffic in a circuit than its capacity. To prevent this, on the Demand Deduction page, select the option to keep the interface utilization below 100%. This forces the resulting simulated calculations to be below the given percentage of circuit capacity.

Flow measurements for demand deduction

Besides node, interface, and LSP traffic measurements, Demand deduction allows more general flow measurements. These flow measurements can be flows from (or through) a specified node, to (or through) another node. You can also use combinations of these node-to-node flows. This measurement format can be used to enter, for example, peer-to-peer flow measurements, or traffic measurements obtained from LDP routing or from NetFlow.


Note

You can only view the Flows table if is already present in your plan file. You cannot create, edit, or delete the Flows in the UI.

Flow measurements are entered in the plan file in the <Flows> table. They appear in the UI in the Flows table. Table 1 lists some of the useful columns in the Flows table. The included traffic is defined by the From type and To type columns.

Table 3. Flows table columns

Column

Description

From

Specifies the source node.

From type

  • Source: Traffic originating at the From node is included in the flow.

  • Interior: Traffic is included that passes through the From node, entering that node from another node in the same AS

  • Border: Traffic is included that passes through the From node, entering that node from another node in a different AS.

To

Specifies the destination node.

To type

  • Dest: Traffic that is destined for the To node.

  • Interior: Traffic that passes through the To node to another node in the same AS.

  • Border: Traffic that passes through the To node to another node in a different AS.

Traff meas

Measured traffic used by Demand deduction in its calculations. If more than one node is included in either the From or To columns, this measurement is the sum of the traffic over all flows between individual pairs of From and To nodes.

Estimate demand traffic using demand deduction

The Demand deduction tool calculates demand traffic when traffic measurements are available.

The options available can significantly affect the calculations. For information on improving accuracy of results, refer to Strategies for minimizing differences between measured and simulated traffic. For information on setting up external endpoint members to be included in Demand deduction calculations, refer to Simulate Advanced Routing with External Endpoints.

Complete these steps to estimate the demand traffic using the Demand deduction tool.

Procedure

Step 1

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

Step 2

From the Traffic level drop-down list in the toolbar, select the traffic level on which you are creating simulated traffic. The measurements used come from this traffic level, and the simulated traffic for each demand is placed in this traffic level.

Step 3

From the toolbar, choose Actions > Tools > Demand deduction.

  1. (Optional) Modify the traffic measurements for one or more demands by clicking the Edit button in the Measurements (measurements / total) section. In the window that appears, you can modify measured traffic of interfaces.You can further change these measurements for a traffic level and interface queue.

    Another option in this window is to enter growth percents for use with the Create growth plans tool. For more information on creating growth plans, refer to Evaluate Impact of Traffic Growth.

  2. Identify one or more types of measurements used in the calculations: Nodes (source and destination), Interfaces, LSPs, and Flows.

  3. For each type, set its priority. Select Priority 1 for high priority and Priority 2 for lower priority. You can have multiple measurements of the same priority. Like priorities are calculated simultaneously with equal consideration for the measurements.

    By default, all available measurements in the selected traffic set are used, and the interface measurements have priority over node, LSP, and flow measurements.

  4. Choose the required Fitting parameters.

  5. If you need to keep the traffic utilization below a different percentage than 100% (default), check the Keep interface utilization below __ % check box and enter a value.

  6. Click Next.

Step 4

Select the demands for use in constructing the demand calculations.

  • Use existing: Calculates demands using the existing demands only. This option is useful when simulating a pattern of demands that cannot be represented as a simple mesh between nodes. If you did not select one or more demands before opening this window, use this option.

  • Use selected: Calculates demands for the selected rows in the Demands table. This option is helpful when you want to recalculate some of the demands, for example, such as a VPN submesh.

Step 5

Determine whether to fix multicast demands. If selected, the multicast demands are fixed at their current traffic value.

Step 6

Determine whether to remove demands with zero traffic. The default is to remove them because Demand deduction typically estimates a significant percentage of the simulated traffic to be zero when a large number of point-to-point utilizations in a mesh are extremely small. Using this default can substantially improve simulation and optimization performance in large plans. Do not remove demands with zero traffic if all demand routes are of interest, irrespective of traffic. Click Next.

Step 7

On the Run Settings page, choose whether to execute the task now or schedule it for a later time. Choose one of these Execute options:

  • Now: Choose this option to execute the job immediately. The tool runs and changes are applied to the network model immediately. A summary report appears. You can access the report any time later using Actions > Reports > Generated reports option.

  • As a scheduled job: Choose this option to execute the task as an asynchronous job. Set these options:

    • Priority: Select the priority of the task.

    • Engine profiles: Select the engine profile as needed. This section lists all the available asynchronous engine profiles.

    • Schedule: Set the time at which you want to run the tool.

    The tool runs at the scheduled time using the selected engine profile. You can track the status of the job at any time using the Job Manager page (from the main menu, choose Job Manager). Once the job completes, import the output plan file into user space to visualize it. For more information, refer to Access output plan files from job manager.

    Note

     
    Ensure that you save the plan file before you schedule the job. Any unsaved changes in the plan file are not considered when you run the tool as a scheduled job.

Step 8

Submit your changes.

The Demand deduction tool calculates the simulated traffic and lists the results in a Demand Deduction report.

Demand deduction example

This example demonstrates results when using the Demand Deduction tool on a simple network.

Scenario overview

Network containing two demands and no demand traffic shows the routes of two demands in a network. These demands split between the two parallel core circuits due to an ECMP, and they have a common routing until the last hop. The Traffic column in the Demands table shows 0, as these demands do not contain any traffic yet.

Figure 12. Network containing two demands and no demand traffic
Network containing two demands and no demand traffic
Measured interface traffic

Measured traffic view and interfaces associated with the demands shows the Measured traffic view and the five interfaces associated with the two demands, three of which have measured traffic.

  • Edge1 to Core1 has 470 Mbps of measured traffic.

  • One Core1 to Core2 interface has 210 Mbps, and the other has 240 Mbps, making a total of 450 Mbps. This unequal split results from imperfect load balancing of the ECMP.

  • There is no traffic from Core2 to Edge2 or from Core2 to Edge3.

Figure 13. Measured traffic view and interfaces associated with the demands
Measured traffic view and interfaces associated with the demands
Demand deduction simulation

Upon running Demand deduction with its default options, the Simulated traffic view appears. Other than the measured interface traffic, there is no other information about the demand traffic. So, Demand deduction first splits the difference between the measured 470 Mbps of traffic (Edge1 to Core1) and the measured traffic of 450 Mbps (Core1 to Core2) to get an estimated total demand traffic of 460 Mbps. In the absence of any other information, it divides this 460 equally to give 230 Mbps of traffic to each demand (Simulated view showing demand traffic). In the Interfaces table, the Traff sim column now has values and the network plot shows simulated traffic percentages on all five interfaces associated with the demands.

  • Edge1 to Core1 has 460 Mbps of simulated traffic.

  • Both Core1 to Core2 interfaces have 230 Mbps.

  • Core2 to Edge2 and Core2 to Edge3 both have 230 Mbps.

    The Abs meas diff and Meas diff/cap (%) columns in the Interfaces table show mismatches between measured and simulated values.

  • Edge1 to Core1 has a difference of 10 Mbps, or 1%.

  • One Core1 to Core2 has a difference of 20 Mbps, or 2%, while the other has a difference of 10 Mbps, or 1%.

  • Neither the Core2 to Edge2, nor the Core2 to Edge3 interfaces have values because they had no measured traffic.

Figure 14. Simulated view showing demand traffic
Simulated view showing demand traffic
Alternate scenario

In this same example, if the Core2 to Edge2 interface had 50 Mbps traffic, the results would have been different. Because this interface is used only by the one demand, the measured 50 Mbps of traffic would be used as an estimate only for that one demand. Using the same logic as before, the demands should total to 460 Mbps, so the other demand is set to the difference, which is 410 Mbps.