Cisco WAE Design 7.0.1 User Guide

LSP Paths

LSPs can be assigned one or more LSP paths. Like LSPs, LSP paths have properties that vary depending on whether the path is for an RSVP LSP or SR LSP. If these properties are omitted, then they are inherited from the LSP. If these properties are set in the LSP path, they override the LSP settings. For information on these properties, see RSVP-TE Simulation and Segment Routing Simulation .

After an LSP path is created, you can use an initializer to create explicitly routed paths. For information, see Creating LSP Paths and Explicit LSP Paths Initializer.

Path Options and Active Path

Each LSP path has a Path Option property. The LSP is routed using the first LSP path that can successfully be established. LSP paths are established in increasing order of their path option, where path option 1 is established first.

Alternatively, you can choose which LSP path to use from the LSP Active Path drop-down list in the LSP Property dialog box.

Creating LSP Paths

Step 1 In the LSPs table, choose the LSP to which you are adding LSP paths.

Step 2 Right-click in the plot choose New > LSPs > LSP Paths, or choose Insert > LSPs > LSP Paths.

Step 3 In the Path Option field, enter the order in which the LSP path is activated. Lower numbers have preference over higher numbers.

Step 4 If this is an RSVP LSP path, optionally set these properties. For information on these properties, see RSVP-TE Simulation .

a. If this is a standby LSP path, check Standby, which ensures the paths are always active.

b. To set the bandwidth, specify the Setup Bandwidth for the LSP path, or specify that it should inherit the bandwidth from the LSP.

c. To create associated named paths, check this option and complete the name using $1 for the LSP name and $2 for the path option.

d. To associate the LSP path with affinities, click Edit. For example, you might want to associate a standby path with an affinity that forces it on a different path than the primary path. LSP paths can inherit the affinity from the LSP or can be assigned a specific affinity. Click OK.

Step 5 Click OK.

Visualizing LSP Shortest Paths

To view the LSP shortest paths, use one of these methods. The source is marked with an “A” and the destination is marked with a “Z”.

• Using the View > LSPs submenus, you can choose to see the shortest actual paths, shortest latency paths, or shortest TE paths each time that you choose an LSP.
• To view all shortest IGP paths, shortest TE paths, or shortest latency paths for selected LSPs, use the context menu. Choose one or more LSPs, right-click, and choose Filter To > Shortest Paths (Figure 9-2).

Figure 9-2 LSP Shortest IGP, Shortest TE, and Shortest Latency Paths

Intra-Area LSPs

Intra-area LSPs are modeled as IGP shortcuts. That is, the source of the demand using the LSP can be a node other than the ingress node into the IGP, and the destination node of the LSP can be a node other than the egress node from the IGP. A demand through intra-area LSPs does not require the LSP to traverse the full demand path.

Each intra-area LSP has a metric that helps determine which traffic is routed through the LSP. By default, autoroute LSPs have a metric equal to the shortest IGP distance from the source to the destination. However, you can configure static metrics for these LSPs that override this default. Static metrics can also be defined relative the shortest IGP distance, but these relative metrics are not currently supported in WAE Design.

Forwarding adjacency LSPs always have a metric. If not specified, the default is 10. Forwarding adjacency LSP metrics are injected into the IGP so that nodes other than the source node of the LSP are aware of the path length through the forwarding adjacency LSP, and use it in their shortest path calculations.

To edit autoroute and forwarding adjacencies, choose one or more LSPs from the LSP table; double-click to bring up the Properties dialog box and edit the values in the Routing area.

Inter-Area LSPs

Because it is not possible to define metrics distances across ISP areas, there can be no well-defined metric for inter-area LSPs. Therefore, in WAE Design, a demand only routes through an inter-area LSP if the demand’s endpoints are nodes matching the source and destination of the LSP, interfaces on these nodes, or external ASes whose ingress and egress points through the IGP are these nodes. This requirement is true regardless of the network option settings.

To be routed, these demands must also match the privacy, tags, and class-based forwarding requirements. Autoroute, forwarding adjacency properties, and LSP metrics are ignored. For information on privacy, see Private LSPs, for information on tags, see Plan Objects , and for information on class-based forwarding, see Class-Based Forwarding.

Loadsharing

Two or more LSPs with the same source and destination (and metrics, if these are defined) loadshare traffic between them. How the load is shared between the LSPs is determined by the LSP Loadshare property. By default, LSPs have a Loadshare property of 1, and thus route traffic between them in equal proportions. Changing the Loadshare value changes the distribution of LSP traffic and interface traffic in proportion to these values.

Example: If two LSPs are parallel, and one has a Loadshare property of 2 and one has a Loadshare property of 1, there will be a 2-to-1 ratio of traffic shared between them. The top half of Figure 9-3 shows an example of two parallel LSPs that are routed using strict explicit paths. Each has a Loadshare value of 1, which means the traffic is routed using a 1:1 loadshare ratio so that each LSP carries 50% of the traffic. In contrast, the lower half shows the same parallel LSPs with a 2:1 ratio. That is, one LSP has a Loadshare value of 2, and one has a Loadshare property value of 1. The LSP with a Loadshare value of 2 carries 67% of the traffic, while the other carries 33%.

Each LSP has a path showing the percentage of traffic that crosses the LSP as a result of the Loadshare value for that LSP. The format is <path option> : <loadshare percentage> %. Although loadshare applies only to path option 1, the LSP itself might be routed along a different path.

Note that this percentage may or may not be the same as the Loadshare value in the LSPs table. This is because the Loadshare value is relative to the other Loadshare values for parallel LSPs. For this reason, if manually editing the Loadshare property, we recommend that you consider the entire set of parallel LSPs. Note also that because an LSP can be in multiple sets of parallel LSPs, the percentage on its path can differ.

To optimize these Loadshare values, use the LSP Loadshare Optimization tool. For information, see LSP Loadshare Optimization.

Figure 9-3 Example of Two Parallel LSPs with Equal Loadsharing

Class-Based Forwarding

Class-based forwarding (CBF) lets you manage differentiated service requirements by restricting or allowing demands into LSPs according to a set of user-defined mappings between demand service classes and LSPs. For example, a demand with an Assured Forwarding service class could be mapped to an LSP saved for carrying low-latency voice traffic, while a different LSP using that same demand could be used for only best-effort services, such as file transfers.

Class-Based Forwarding Simulations

Demands can be assigned a Service Class property. LSPs can be assigned a Class property. CBF is enabled by creating a table that maps the demand service class to the LSP classes. The resulting table defines a set of LSPs to which a demand with a specific service class has access.

Figure 9-4 Example Service Class LSP Class Mapping Table

• Each demand service class in the table is mapped to one or more LSP classes, or with a Drop value.
• If a demand’s service class is in the mapping table, the demand can only use LSPs with LSP classes that match that service class.

If a demand service class is not in the mapping table, it can use any LSP.

Example: There are three demand service classes: AF, BE, and EX. The mapping table contains only AF and BE (Figure 9-4). This means that the demands with EX service class can use any LSP in the plan file.

• If an LSP class does not appear in this mapping table, then any demand can use any LSP of that class.
• If multiple LSPs are sourced from one node, demands routed through that node can use any LSP to which the demand’s service class is mapped.

– If all available LSPs have LSP classes with equal priority, the traffic is load balanced between these LSPs.

– If the LSPs have prioritized LSP classes (1, 2, 3, etc.), those with the highest priority (lowest number) are routed first.

Example: A demand with an AF service class must first use LSPs with an LSPClass_AF because within the AF service class, this is the only Priority 1 LSP class. If no LSPs with LSPClass_AF are available, the demand tries to route across LSPs with an LSPClass_BE class (Figure 9-4).

• If there are no available LSPs with matching LSP classes, the demand follows these rules.

– If the demand’s service class is not mapped to a Drop value, the demand forgoes using LSPs and takes the shortest IGP path.

– If the demand’s service class is mapped to a Drop value, the demand is unrouted.

Example: If there are no available LSPs for the AF demand to route across, it will not route due to the Drop value associated with it (Figure 9-4). If the BE demand cannot route across an LSP that has a class of LSPClass_BE, it will route across the shortest IGP path available.

Example Simulations

In these examples, we want to route the assured-forwarding (AF) Europe-to-Japan traffic directly over the more expensive, but lower latency, circuits through Russia. We want to route the best-effort (BE) traffic along the cheaper, but higher latency, circuits through the US.

In these example simulations, there are only two demands and two LSPs. Both demands and both LSPs go from London to Tokyo.

• Lon-Tok-D1 demand uses an AF service class.
• Lon-Tok-D2 demand uses an BE service class.
• The LSPs are named LSP_A and LSP_B. Each LSP is explicitly routed to reach Tokyo via a different path.

– LSP_A is assigned to LSPClass_AF.

– LSP_B is assigned to LSPClass_BE.

Figure 9-5 shows a simple one-to-one mapping between a service class and an LSP class.

• The AF service class is mapped to LSPClass_AF.
• The BE service class is mapped to LSPClass_BE.
• If the circuit between London and Tokyo fails, the Lon-Tok-D1 demand reroutes using the shortest IGP path. The reason is because there are no alternative LSPs available.

Figure 9-5 Example Reroute Around Failure Using IGP Path

Figure 9-6 shows that the AF service class is mapped to both LSPClass_AF and LSPClass_BE. The Lon-Tok-D1 demand now reroutes around a failure between London and Tokyo by using LSP_B. This is because the AF service class now has a Priority 2 mapping to the LSPClass_BE class, and the fact that LSP_B is assigned to this LSPClass_BE class.

Figure 9-6 Example Reroute Around Failure Using Alternative LSP Class

Figure 9-7 shows that the AF service class is mapped to both LSPClass_AF and a Drop value. The Lon-Tok-D1 demand now does not reroute around a failure between London and Tokyo. This is because demands using AF service class are mapped so that if an LSP with an LSPClass_AF class is not available, the traffic is dropped.

Figure 9-7 Example of Not Rerouting Based on Drop LSP Class

Workflow for Creating Service Class and LSP Class Mappings

The workflow for creating mappings between service classes and LSP classes is as follows (Figure 9-8).

Step 1 Create the service classes using the Manage QoS dialog box. For information, see Quality of Service Simulation .

Step 2 Assign demands to the service classes. To assign this property, use the Service Class menu in the demand’s Properties dialog box. (Right-click one or more selected demands and choose Properties.)

Step 3 Create the LSP classes using the Manage QoS dialog box. For information, see Creating LSP Classes.

Step 4 Assign LSPs to the LSP classes. For information, see Assigning LSP Classes to LSPs.

Step 5 As needed, assign a service class to one or more LSP classes using the Manage QoS dialog box. This creates a mapping table between the demands with a given service class and LSPs with a given LSP class. Optionally, prioritize multiple LSP classes within a service class. For information, see Creating Mappings Between Service Classes and LSP Classes.

Figure 9-8 Workflow Process for Creating Service Class to LSP Class Mappings

Creating LSP Classes

Step 1 Open the Manage QoS dialog box in one of two ways:

• Choose Edit > Manage QoS.
• Choose Manage QoS from the QoS drop-down menu in the Visualization toolbar.

Step 2 Click the LSP Class tab.

Step 3 In the LSP Classes area, click New.

Step 4 Enter the name of the LSP class, and click OK.

Step 5 Click OK in the Manage QoS dialog box.

Assigning LSP Classes to LSPs

Step 1 Choose one or more LSPs.

Step 2 Right-click one of the LSPs and choose Properties.

Step 3 Choose the LSP class from the Class drop-down list and click OK.

Creating Mappings Between Service Classes and LSP Classes

Step 1 Open the Manage QoS dialog box in one of two ways:

• Choose Edit > Manage QoS.
• Choose Manage QoS from the QoS drop-down menu in the Visualization toolbar.

Step 2 Click the LSP Class tab.

Step 3 In the Service Class LSP Class Mapping area, click New.

Step 4 In the Service Class drop-down list, select the service class to which you are mapping LSP classes.

Step 5 Enter a priority (number) for the LSP class. This determines the order in which the demand routes available LSPs. The lower the number, the higher the priority.

Step 6 Click one of the following radio buttons:

• To map the selected service class to an LSP class, click LSP Class and select the class from the drop-down list.
• To set the mapping so the demand doesn’t reroute if LSPs are unavailable, click Drop. Drop should only be used on the lowest priorities.

Step 7 Click OK, and then click OK again in the Manage QoS dialog box.

Private LSPs

WAE Design provides two ways to route selected traffic demands through specific LSPs. One way is to dedicate the traffic for specific demands to a private LSP, which is a special LSP that carries those demands only. This type of LSP models an MPLS Layer 2 VPN, providing an exclusive route for the associated demands. If the LSP goes down, all traffic associated with the LSP is interrupted.

The other way to dedicate traffic to an LSP is to filter the demands that the LSP can carry. You can do this by using the WAE Design tag feature to identify the desired demands, and then configuring the LSP with a list of tagged values. This type of LSP makes it possible to route specific types of traffic over the LSP, and the type of traffic is any arbitrary group that you define.

To configure LSPs that simulate Layer 2 VPNs, use one of these two tools.

• One tool creates dedicated demands for existing LSPs. The created demands will match the LSPs in source and destination.
• One tool creates private LSPs from existing demands. The created LSPs will match the existing demands in source and destination.

The LSP Private property is set to T (true) in the LSPs table, and the Private LSP Node and Private LSP Name properties in the Demands table are set.

Creating Private Demands for Existing LSPs

LSPs must currently exist in the plan file.

Step 1 If you are creating demands for only selected LSPs, select those LSPs from the LSP table. If they are tagged, you can skip this step and specify the tag value in Step 3 instead. If you are creating demands for all LSPs, you can skip this step.

Step 2 Choose Insert > LSPs > Demands for LSPs, or right-click in the plot and choose New > LSPs > Demands for LSPs.

Step 3 In the LSPs list, choose All, Selected in table (Step 1), or Tag name.

Step 4 Select the service class to which these LSPs belong.

Step 5 Set the demand traffic to equal the LSP setup bandwidth, the LSP traffic measurements, or zero.

Step 6 Check Mark LSPs as private.

Step 7 Click OK. The newly created demands are highlighted in the Demands table.

Creating Private LSPs for Demands

Demands must currently exist in the plan file. See Traffic Demand Modeling .

Step 1 If you are creating LSPs for only selected demands, select those demands from the Demands table. If they are tagged, you can skip this step and specify the tag value in Step 3 instead.

Step 2 Choose Insert > LSPs > LSPs for Demands, or right-click in the plot and choose New > LSPs > LSPs for Demands.

Step 3 In the Demands list, choose All, Selected in table (Step 1), or Tag name.

Step 4 Set the bandwidth traffic to a specific traffic level or to zero.

Step 5 Check Mark LSPs as private.

Step 6 Click OK. The newly created LSPs are highlighted in the LSPs table.

Configuring LSPs to Transport Specific Traffic Types

This section describes how to configure LSPs that only route specific types of traffic. For example, you might want to route traffic for a voice service class through an LSP with a low latency, and route traffic for an Internet service class through another LSP with best-effort only. Such LSPs only carry the specified demands, but those demands might also be routed elsewhere.

Step 1 In the Demands table, select and double-click the demands that you want to group.

a. Click the Tags tab.

If a tag exists that you want to use, toggle its F (false) value to T (true) to enable the tag for the selected demands. If a tag does not exist that you want to use, click New Tag.

Enter the name of the tag.

Click OK.

b. Click OK to save and exit the Properties dialog box.

Step 2 In the LSP table, select and double-click the LSPs that are to transport demands that were tagged (Step 1).

a. In the Include Any Demands Tags field, enter a list of demand tags and separate each entry with a semicolon.

b. Click OK.

Order of Routing Through Areas

Regardless of the LSP type and whether explicit hops are required, inter-area LSPs route through the backbone areas, as follows, where “backbone” means area 0 for OSPF or the Level 2 area for IS-IS.

• If there are three or more areas, backbone areas must be between the source and destination nodes. Typically, there are no more than three areas and therefore, the backbone area must be in the middle. For example, an OSPF inter-area LSP would route from area 1 to area 0 (backbone) and then to area 2 (Figure 9-9).
• If there are only two areas, there can only be one backbone area, and either the source or the destination node must be in the backbone area.

Explicit Versus Dynamic Inter-Area LSP Routing

An OSPF ABR is a node that belongs to both area 0 and other OSPF areas. An IS-IS ABR is a node that belongs to both the Level 2 area and another IS-IS level.

There are two modes of routing inter-area LSPs. One requires that explicit hops be set on ABR nodes. This mode correctly simulates actual router behavior where ABR explicit hops are required. The other mode does not require explicit hops at ABR nodes and can route an LSP fully dynamically across multiple areas. While this mode does not simulate actual router behavior, it is useful for planning inter-area LSP routes. For example, you can use a fully dynamic simulation to find an appropriate path, which can then be converted into a (routable) fully explicit path using other tools such as the Explicit LSP Paths initializer. These modes are specified using the network option labeled “LSP routing requires ABR explicit hops.”

If this option is selected, inter-area LSPs are routed based on explicit hops set on the ABR nodes.

• An inter-area RSVP LSP must contain a named path, and the named path must contain explicit hops at ABRs for each required area crossing.
• An inter-area SR LSP must contain a segment list, and the segment list must contain explicit node hops at ABRs for each required area crossing.

If this option is not selected, inter-area LSPs are routed dynamically and explicit hops at ABRs are not required. To leave one area and enter another, the inter-area LSP routes to the closest ABR in the current area that also borders the area it is entering.

Example: Figure 9-9 shows two inter-area LSPs selected, although only the LSP with explicit hops set on ABR nodes routes. The reason is because the network option is set to require ABR hops when routing inter-area LSPs. Figure 9-10 shows that by deselecting this network option, the inter-area LSP that does not have hops set at ABRs can dynamically route.

Figure 9-9 Example Inter-Area Routing Requiring Hops at ABRs

Figure 9-10 Example Inter-Area Routing Without Requiring ABRs

LSP Path Reports

You can create reports on the LSP path routes that the LSP is actually taking across both L3 and L1 topologies. Each report identifies the complete path route, as well as disjointness information, including whether it contains common nodes or common circuits. Additionally, the report contains all other columns in an LSP Paths table, though they are initially hidden.

Step 1 Select one or more LSP paths. If you do not select one, all LSP paths are used.

Step 2 Choose Tools > Reports > LSP Path Routes.

Step 3 Check one or both hop options, and click OK.

Step 4 To export the report, right-click the Routes report name in the left Reports navigation pane, and choose Export Routes.

Simulation Diagnostics

To help troubleshoot RSVP LSP and LSP path simulations, WAE Design analyzes simulation routes and provides reasons for certain types of routing behavior. The Simulation Diagnostics tool identifies why an LSP is not routed, why an LSP is routed away from its actual path, and why an LSP is not following the shortest TE path.

These routing diagnostics assume that all other LSPs, except for the one being tested, have been routed. That is, WAE Design calculates whether an LSP can route on the actual path after all other routed LSPs have had their bandwidth reserved.

Note that running a report overwrites the previous report of the same type. For example, an LSPs diagnostic report would overwrite the previous LSPs report, but not the LSP Path diagnostic report.

Using Simulation Diagnostics to Troubleshoot

The following information is provided to help you troubleshoot LSP and LSP path issues.

Running LSP Simulation Diagnostics

Step 1 Choose one or more LSPs or LSP paths from their respective tables.

Step 2 Open the diagnostics information in one of two ways:

• Choose Tools > Diagnostics > LSP Simulation or LSP Path Simulation.
• Right-click the selection in the table and choose Simulation Diagnostics.