Dynamic LSP Routing and CSPF
If an LSP contains no LSP paths, it is routed dynamically using CSPF. The weights used for the CSPF calculation are the TE metrics per interface. If the TE metric is not configured for an interface, the IGP metric is used. These and other properties affecting LSP routes are defined in the LSP and interface Properties dialog boxes.
If there are equal-cost routes, the following selection criteria apply in this order.
- Bandwidth available—The route with the greatest reservable bandwidth is chosen.
- Hop count—The route with the fewest hops is chosen.
- Random—If neither of the above criteria can be used, the route is randomly chosen.
CSPF properties are set in the LSP Properties dialog box and are viewable from the LSPs table.
- Setup Bandwidth—The amount of traffic the source node is requesting for this LSP in Mbps. The requested bandwidth is available from the reservable bandwidth of each interface in the path.
- Autobandwidth—Dynamically update the Setup BW Sim value when using the Autobandwidth Convergence mode. For information, see the Advanced RSVP-TE LSP Simulations section.
- Setup Priority—A priority for allocating reservable bandwidth. This is the order in which the LSPs are signaled. The lower the number, the higher the priority.
- Hold Priority—Priority that can preempt LSPs that are on the shortest path. This is typically set for a particular service or traffic type. The lower the number, the higher the priority.
- Hop Limit—The maximum number of hops permitted in the LSP route. If no path is available with this number of hops or fewer, the LSP is not routed.
- TE Metric Disabled—If selected, the LSP is routed using IGP metrics. If unselected (default), the LSP is routed using TE metrics.
Interface MPLS Properties
Related MPLS properties are set in the MPLS tab of the interface or circuit Properties dialog box, and are viewable in the Interfaces table.
- TE Metric—Determines which path an LSP takes.
- TE Metric Sim—Derived column that shows the effective TE metric. If the TE Metric is empty, this is set to the IGP metric.
- TE Enabled—Identifies whether an LSP can be routed over the interface. If selected, the value is set to T (True), and TE metrics are used in routing the LSP provided the LSP’s TE Metric Disabled is unselected (False).
- Resv BW—Shows the amount of bandwidth that can be reserved by LSPs routed over the interface.
- Resv BW Percent—Shows the percentage of bandwidth that can be reserved by LSPs routed over the interface.
- Resv BW Sim—Derived column.
– If a Resv BW value is entered, this is copied to the Resv BW Sim column.
– If Resv BW and Resv BW Percent are “na,” the Resv BW Sim is copied from the Capacity Sim column.
– If Resv BW is “na,” but Resv BW Percent has a value, the Resv BW Sim value is derived by this formula.
Capacity Sim * (Resv BW Percent / 100)
If needed, you can change this behavior so that reserved bandwidth constraints are not used during simulations, which could be useful for planning purposes. For information, see the Ignore Reservable Bandwidths for Capacity Planning section.
- Affinities—Lists which affinities are set. For more information, see the Affinities section.
- Loadshare—Value for redistributing either traffic across LSPs based on the ratio of this value with other LSPs that are parallel (have the same source and destination). For more information, see the see the LSP Loadshare Optimization chapter.
- FRR Enabled—Designated interface to be avoided by the FRR LSP. Only interfaces with this property set are used by the FRR LSPs initializer when creating FRR LSPs. This property does not affect FRR LSPs that are manually created. For more information, see the Fast Reroute Simulations section.
To determine how much of the interface traffic is contained in LSPs, show these columns in the Interfaces table. The total of the two equals Traff Sim.
- Traff Sim LSP—The total amount of LSP traffic on the interface.
- Traff Sim Non LSP—The total amount of non-LSP traffic on the interface.
To determine which interfaces carry LSP traffic, sort the columns. To determine the demands associated with one or more selected interfaces based on whether or not they have LSP traffic, right-click one and select Filter to Demands Through Interfaces. Then select either In LSP or Not in LSP.
View LSP Reservations
To view the LSP reservations on the interfaces, select LSP Reservations from the Network Plot View menu in the Visualization toolbar (Figure 11-1). The width of the circuit displayed in the network plot is set according to the Resv BW Sim column in the Interfaces table, rather than the Capacity column as in other views. The utilization colors are based on the LSP Util column in the Interfaces table. The LSP Util is the sum of all setup bandwidths for all LSPs through the interface, as a percentage of the Resv BW Sim.
Figure 11-1 LSP Reservations View
LSP Setup BW Initializer
The LSP Setup BW Initializer calculates the setup bandwidth for existing RSVP-TE LSPs. The setup bandwidth is set to the maximum amount of demand traffic passing through the LSP for the traffic levels selected.
If using only one traffic level, the best practice is to use the Autobandwidth Convergence mode. For information, see the Advanced RSVP-TE LSP Simulations section.
Step 1 Select one ore more LSPs from the LSPs table.
Step 2 Either select the Initializers->LSP Setup BW menu, or right-click one of the selected LSPs and select LSP Setup BW Initializer from the context menu.
Step 3 Select which traffic levels to use for demand traffic.
Step 4 Select whether to set the load share values to be equal to the setup bandwidth.
Step 5 Click OK.
RSVP LSP Paths
Like LSPs, LSP paths have CSPF properties, such as Setup Priority and Hop Limits. For a description of LSP properties, see the Dynamic LSP Routing and CSPF section.
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. Note, however, if operating in the Autobandwidth Convergence simulation mode and if the LSP has Autobandwidth set to T (true), the LSP path Setup BW property (like the LSP Setup BW) is ignored, and the LSP’s Setup BW Sim value is calculated and used. For more information, see the Advanced RSVP-TE LSP Simulations section.
If an LSP path does not have an associated named path, it is routed dynamically. However, you can use named paths to fully or partially describe a path from the LSP source to destination. For information on named paths, see the Named Paths and Explicit LSP Routing section.
Note This chapter refers to LSPs and LSP paths as dynamic, explicit, or loose explicit, depending on whether their associated named paths have no defined hops, all hops defined, or only some hops defined, respectively.
An LSP path can be defined as a “hot” standby path. Standby paths are always established even if the associated LSP is routed using a path with a different path option. For RSVP LSPs, setup bandwidth, if any, is reserved for them. These standby LSP paths are then immediately available should the currently routed path become unavailable, for example, through failure.
Example Response to Failures
Figure 11-2 shows an RSVP LSP (cr1.lon_cr2.fra) that uses four LSP paths. The cr1.lon_cr2.fra LSP has a primary and standby secondary path options (100 and 200), each with a setup bandwidth of 0. They are both established, using their defined named paths. Both primary and secondary LSP paths have associated named paths, which appear in the Named Path column. The other two paths do not have associated named paths, and so are dynamically routed.
Figure 11-2 Example RSVP LSP and Associated LSP Paths
Following is how this example LSP responds to failures.
1. If the primary path (cr1.lon_cr2.fra_100) fails, the secondary path (cr1.lon_cr2.fra_200) is used.
2. If both paths with associated name paths fail, a dynamic path is established with a reserved bandwidth of 125 Mbps, which it inherits from the LSP. This path is not set up initially because it not a standby.
3. If all these paths fail, the path of last resort is a dynamic path with zero bandwidth. This ensures that there is always an LSP up so that services relying on the LSP are always available.
4. The simulation changes if the LSP Active Path has been set. For example, if cr1.lon_cr2.fra_200 is the active path (that is, 200 appears in the LSP's Active Path column), WAE Design uses cr1.lon_cr2.fra_200 first, and then goes through the previous sequence.
Named Paths and Explicit LSP Routing
Named paths specify a route though the network using an ordered list of adjacencies. The route is defined by named path hops, which can be nodes or interfaces, and each hop type specifies whether the route should be strict, loose, or excluded. Named path hops can be nodes or interfaces. The hop type is identified visually on the plot, as well as listed in the Type column of the Named Path Hops table.
- Strict—The LSP must reach the named path hop directly from the previous one, with no intermediate interfaces.
- Loose—The LSP is routed to this hop from the previous hop using CSPF. Intermediate interfaces can be used.
- Exclude—The node or interface is excluded from the LSP path. This hop type cannot be combined with strict or loose hops in the same named path.
The named paths and their hops are listed and selectable from the Named Paths and Named Path Hops tables, respectively. The advantage of having separate tables for these is that you can have named paths that have missing or unresolved hops. Also, the path name can be reserved even if it is not part of the WAE Design simulation.
Named Path Hops Example
Figure 11-3 extends the earlier example (Figure 11-2), showing two named paths for the cr1.lon_cr2.fra LSP. This shows that the first two LSP paths each have a named path. The naming convention is <LSP Name>_<Path Option>, which in this case is cr1.lon_cr2.fra_100 and cr1.lon_cr2.fra_200.
Figure 11-3 Example Named Paths the cr1.lon_cr2.fra LSP
The hops for each named path are defined in a separate table called Named Path Hops. Figure 11-4 shows the named path hops for the cr1.lon_cr2.fra_100 named path. The Steps column shows the order of the hops.
- The first hop is an interface hop: a strict hop on the interface from cr1.par to cr2.par.
- The second is a node hop, also strict, to cr2.par.
- The third hop is an interface hop: a strict hop on the interface from cr1.fra to cr2.fra.
Hops for cr1.lon_cr2.fra_200 are defined similarly.
Figure 11-4 Example Named Path Hops for cr1.lon_cr2.fra_100
Create Named Paths and Their Hops
Named paths can be created in the WAE Design GUI in several ways.
- Select the “Create associated named paths” option when creating LSP paths. Using this option does not create hops. For information, see the MPLS Simulation chapter.
- Use the Explicit LSP Paths Initializer. Using this initializer creates named paths with strict hops. For information, see the MPLS Simulation chapter.
- Optimize LSP paths using the Explicit RSVP-TE LSP Optimization tool or RSVP-TE Optimization tool. See the Explicit and Tactical RSVP-TE LSP Optimization chapter and RSVP-TE Optimization chapter, respectively.
Edit Named Paths and Named Path Hops
Once the named paths are created, you can create, edit, or delete their named path hops. Note that discovered named paths can contain unresolved hops, which are nodes and interfaces that are not in the plan file. For information on resolving named paths, see the Unresolved LSP Destinations and Hops section.
The recommended method of editing the named path hop type is to access it directly from the Named Path table as described in the following steps. This is the most efficient way of viewing the entire path. However, if needed, you can double-click a named path hop in the Named Path Hops table, which takes you directly to the named path hops Properties dialog box, which is described in Step 4.
Step 1 In the Named Paths table, either double-click a named path or right-click one and select Properties from the context menu. The Properties dialog box appears with a list of all named path hops.
Step 2 Named path options
- To change the name, enter it in the Name field.
- To change the source site or source nodes, select them from the drop-down lists.
- To activate or de-activate, select the Active option. For information on active and inactive states, see the Simulation chapter.
Step 3 Hop options
- To add a new hop, select an existing hop (if applicable) from the Hops list, and then click either the Insert Before or Insert After button to determine where the new hop goes sequentially. Go to step 4.
- To edit an existing hop, select it from the Hops list and then select the Edit button. This opens the Properties dialog box for named path hops. Go to step 4.
- To delete an existing hop, select it from the Hops list, select the Delete button, and then press OK. You need not continue.
- To resolve nodes and interfaces that do not exist in the plan file, click the Resolve button. For information, see the Resolve Plan File to Objects section.
Step 4 To continue creating or editing the named path hop, use the following options and then click OK in the named path hops Properties dialog box.
- As needed, select the site, node, and interface. For node hops, do not select an interface.
- Select the named path hop type as Loose, Strict, or Exclude. See the Named Paths and Explicit LSP Routing section for a description of each.
In WAE Design, actual paths are the actual route that routed LSP paths are taking. They are read from the live network, per LSP path, using WAE Collector network discovery tools. RSVP-TE routing is not always completely predictable because it depends on the order in which LSPs are established and reserve their bandwidth on the network. WAE Design uses actual paths in LSP routing simulations to match the current LSP routing state of a network as accurately as possible.
When an LSP path is routed, the actual route is attempted first. If this routing fails due to CSPF constraints, such as not enough reservable bandwidth or affinity restrictions, WAE Design reverts to the standard CSPF routing algorithm.
Example: WAE Design routes all LSPs in its simulation according to the actual paths read from the network, and the routings completely match the network. If a circuit fails, only the LSPs through this circuit are rerouted. Since they cannot be established along their actual paths, standard CSPF is used. The result is a prediction of incremental routing changes that would occur on the current network if such a failure were to occur.
It might be desirable to simulate a network without taking actual paths into account, for example, for long-term planning. To achieve this, actual paths should simply be deleted. To delete an actual path, right-click an LSP or LSP path and select Delete Actual Paths from the context menu.
Note that an LSP or an LSP path might have a corresponding actual path. An LSP path with no actual path inherits its LSP actual path, if available.
Actual paths are represented as a series of interface hops in the Actual Path Hops table. A hop is shown in the network plot as a brown circle on the interface. To view an entire actual path of an LSP, select the View->LSP->Actual Paths menu; all hops are displayed when the LSP is selected.
Two columns in the LSP table are useful to see the result of actual paths on LSP routing.
The simulation can only use actual paths if they are resolved. If the network discovery was incomplete, this might not be possible.
- T = true; the simulation converted the actual path hops into a complete path from source to destination of the LSP
- F = false; the simulation did not convert the actual path hops into a complete path
- na = not applicable; no actual path was available.
- Actual = The LSP follows an actual path.
- Simulated = The LSP does not follow an actual path.
- Unrouted = Routing was not possible.
De-Activate Actual Paths for Simulations
WAE Design uses network state in its MPLS simulation, routing LSPs on actual paths where possible and using LSP active path settings. For planning purposes, when state is not relevant, you can change this behavior to disregard actual paths.
Step 1 Either select the Edit->Network Options menu or click the Network Options icon in the Visualization toolbar.
Step 2 Select the Simulation tab.
Step 3 To use or disregard actual paths and active paths in MPLS simulation, select or deselect the “Use LSP actual paths, active paths” option accordingly. Then click OK.
Affinities provide a mechanism for implementing LSP path diversity. By assigning affinities to physical circuits and associating LSPs with affinities, you can implement a variety of routing policies. For example, you can use affinities to restrict certain traffic to specific topological regions. Or you can force primary and backup LSP paths onto different routes so they do not simultaneously fail.
WAE Design supports an unlimited number of 64-bit affinities, each of which is defined by a number and an optional name. Named affinities are sometimes called administrative groups or link coloring.
The default plan files have 0-31 unnamed and unassigned affinities.
1. Create and Edit Affinities.
2. Assign Affinities to Interfaces.
3. Associate LSPs With Affinities.
Create and Edit Affinities
Step 1 Select the Edit->Admin Groups menu; the Edit Admin Groups dialog box appears.
Step 2 Either modify an existing affinity number and name, or click the New button to add the number and name.
Affinity numbers must be unique. Affinity names are optional and must also be unique.
Then click OK.
Assign Affinities to Interfaces
To use affinities, you must assign them to interfaces in a way that encourages favorable routes and discourages others. For example, continental paths might have one affinity and international paths have another.
Step 1 From the Interfaces table, select one or more interfaces to which you are assigning the affinities.
Step 2 Either double-click the selection or select the Edit->Properties menu; the Properties dialog box appears.
Step 3 Select the MPLS tab.
a. Click the Affinities Edit button; the Edit Affinities dialog box is displayed.
b. In the Assigned column, select the boxes for the affinities that you want to associate with the selected circuits. T = true; associate the affinity with the circuit. F = false; do not associate the affinity.
c. Click OK.
Step 4 Click OK to exit the Properties dialog box. Note, if you close without clicking OK again, the changes are not saved.
Note You can follow the above procedure to assign affinities to interfaces through a circuit Properties dialog box. However, you must select and assign the affinity twice: once to each interface.
Associate LSPs With Affinities
For affinities to influence LSP routing, you must associate LSPs with the affinities assigned to interfaces that you want to include or exclude in the routing process. If no affinity is specified, the LSP can be routed through any path. Explicit routes can also have affinities for hops with a Loose relationship. (See Named Paths and Explicit LSP Routing.)
Inclusion and Exclusion Rules
- Include—Only use interfaces that include all affinities.
- Include Any—Use interfaces that include at least one affinity.
- Exclude—Do not use interfaces with this affinity.
LSP paths inherit the LSP affinities. However, you can edit LSP path affinities to have priority over the LSP affinities as shown in Figure 11-5.
Figure 11-5 LSP Path Affinities
This example (Figure 11-6) demonstrates how affinities affect the routing of two LSPs with the same source and destination nodes.
- The to_cr1.nyc interface between wdc and nyc is assigned to both affinities 0 (Gold) and 1 (Silver). No other interfaces are assigned affinities.
- LSP A is configured to exclude all interfaces assigned to affinity 0. While it cannot take the shortest path using the to_cr1.nyc interface, it can route around it.
- LSP B is not associated with any affinities. Its LSP path is configured to include any interfaces assigned to affinity 1 (Silver) and to exclude interfaces assigned to affinity 2 (Bronze). Since the to_cr1.nyc interface is assigned to both of these affinities, LSP B cannot route.
Figure 11-6 Example Affinities
Assign LSPs to Affinities
Step 1 From the LSPs table, select one or more LSPs to which you are associating the affinities.
Step 2 Either double-click the selection or select the Edit->Properties menu; the Properties dialog box appears.
Step 3 Click the Affinities tab.
Step 4 Select the inclusion or exclusion rule for each affinity you are associating with the selected LSPs.
Step 5 Click OK.
Assign LSP Paths to Affinities
Step 1 From the LSP Paths table, select one or more LSP paths to which you are associating the affinities.
Step 2 Either double-click the selection or select the Edit->Properties menu; the Properties dialog box appears.
a. Click the Affinities Edit button. An Edit Affinities dialog box appears. For each rule (Include, Include Any, Exclude), select whether the LSP path should inherit the LSP affinity rule or whether it should be based on rules defined in the table below these options.
b. If you chose to use the table, select the rule for each affinity you are associating with the LSP path.
c. Click OK.
Step 3 Click OK to exit the Properties dialog box. Note, if you close without clicking OK this second time, the changes are not saved.
Assign Affinities When Creating LSP Meshes
You can associate affinities with LSPs when creating a new LSP mesh.
Step 1 Select the Insert->LSP Mesh menu, or right-click in the plot and select New->LSPs->LSP Mesh from the context menu. The LSP Mesh Creator dialog box appears.
Step 2 Click the Affinities Edit button. An Edit Affinities dialog box appears. Select the inclusion or exclusion rule for each affinity you are associating with all LSPs in the mesh, and click OK.
Step 3 Click OK to exit the LSP Mesh Creator dialog box. Note, if you close without clicking OK this second time, the changes are not saved.
WAE Design enables you to set several global parameters that affect how LSPs are routed or rerouted. To access these options, either select the Edit->Network Options menu or click the Network Options icon in the Visualization toolbar. Then select the Simulation tab.
WAE Design supports four simulation modes for RSVP-TE LSPs.
- A Fast Reroute (FRR) mode using FRR LSPs, which is a common failure restoration mechanism used by RSVP-TE LSPs. In a live network, FRR restoration typically occurs within milliseconds. See the Fast Reroute Simulations section.
- By default, WAE Design simulates the state of the network once it has fully responded to a failure. Specifically, this is the network state after LSPs have re-established new routes around the failure, and the IGP has fully reconverged. This is called the IGP and LSP Reconvergence simulation mode. The Optimization tools only work in IGP and LSP Reconvergence mode.
- In the Autobandwidth Convergence mode, the network is simulated after the traffic (Traff Sim) has been rerouted to other LSPs, but before the Setup BW Sim values have been reset. See the Autobandwidth Simulations section.
- In the Autobandwidth Convergence Including Failures mode, the network is simulated after the Setup BW Sim values have been reset. See the Autobandwidth Simulations section.
The status bar in the lower, left of the GUI identifies which simulation modes you are currently using. Note that unless specified otherwise, the documentation describes behavior in the IGP and LSP Reconvergence mode.
Fast Reroute Simulations
WAE Design simulates a Fast Reroute convergence mode using FRR LSPs. If a failure occurs in the route of a protected RSVP-TE LSP, a pre-signaled FRR LSP (or bypass tunnel) forwards traffic locally around the point of failure, typically from the node just before the failure to a node downstream. This restoration mechanism gives the source node (head-end) of the FRR LSP time to re-establish an alternate route around the failure. This period is sometimes described as the 50 millisecond behavior of the network since FRR restoration ideally becomes effective within approximately 50 milliseconds of a failure occurring.
Routing of LSPs and demands differ in FRR simulations compared to full convergence simulations, as follows.
- The source node of the protected LSP does not reroute the traffic. If a failure occurs on a node or circuit (link) within the LSP path, then the following routing occurs.
– If an FRR LSP exists to protect a failed node or circuit, the protected LSP continues to be routed, but its new path includes the FRR LSP route that redirects the traffic around the failure. This traffic enters the FRR LSP’s source node just prior to the failure and rejoins the protected LSP path after the failure at the FRR LSP’s destination node.
– If the LSP is not protected by an FRR LSP, then the LSP traffic is not routed.
- Since there is no IGP reconvergence, demands through unrouted LSPs are unrouted. Additionally, demands through failures outside of these LSPs will not be routed.
This section summarizes key properties and terms, and how FRR LSPs are visualized in the network plot. More details about these are further explained throughout the following sections. Note that FRR LSPs appear in the same table as do regular LSPs and are identified in the Metric Type column as FRR.
Objects and Properties
Designated interface to be avoided by the FRR LSP.
Type of FRR protection: Link or Node.
Marks an LSP to be protected by FRR LSPs.
Marks an interface to be protected by FRR LSPs. This property is required if an interface is to be used when running the FRR LSPs initializer.
- Protected interface—An interface that is avoided when using FRR LSPs.
- Protected LSP—An LSP that would be rerouted through FRR LSPs in the event of failures. In WAE Design, this requires the Fast Reroute simulation mode. To turn this mode on, access the Network Options dialog box. For more information, see the Run Fast Reroute Simulation section.
- Protected SRLG—An SRLG that contains a protected interface.
An unused FRR LSP path highlights in magenta when it is selected from the LSPs table. When routed, FRR LSPs appear as a dashed magenta line.
FRR LSP Routing
The source and destination of an FRR LSP can be any pair of nodes, although in practice the source and destination nodes are usually one hop (link protection) or two hops (node protection) apart. The source node for the FRR LSP has a designated interface that is configured so that it is avoided during Fast Reroute simulations. (This is the protected interface.)
This is configured using the FRR Interface property, which is set in the LSP Properties dialog box when manually creating the FRR LSP, or it is automatically created when running the FRR LSPs initializer. The initializer derives it from interface FRR Enabled property.
Example: This figure shows an FRR LSP sourced at sjc, destined for nyc, and whose protected interface (FRR Interface) is to_cr1.okc. Therefore, the FRR LSP path routes towards chi and away from okc. If this FRR Interface property were to_cr1.chi instead, the FRR LSP path would route sjc-okc-nyc, away from chi.
Like other LSPs, FRR LSPs can use actual and named paths. Unlike other LSPs, they do not use setup bandwidth when routing and they only use one LSP path.
Link and Node Protection
WAE Design supports both link (circuit) and node protection FRR LSPs. The type of protection shows in the FRR Type column of the LSPs table.
- Link-protection LSPs—Protect an LSP from a circuit failure by routing an FRR LSP around the failed circuit. The source node of the FRR LSP is the local node of the failed circuit, and if configured correctly, the destination of the FRR LSP is the remote node of the failed circuit. Figure 11-7 shows an example of an LSP from sjc to nyc with a failure on the circuit between slc and hst. The top portion shows the Full Convergence mode where the source node of the LSP is signaled to reroute the traffic. The lower portion shows that a link-protection FRR LSP was set up for the slc-hst interface, and that the simulation is operating in Fast Reroute mode. Here, slc reroutes the LSP traffic around the failed circuit.
- Node-protection LSPs—Protect an LSP from a node failure by routing an FRR LSP from the node one hop prior to the failed node in the protected LSP path to the node one hop after the failed node. Figure 11-8 shows an example of an LSP from sjc to nyc with a failure on the hst node. The top portion shows the Full Convergence mode where the source node of the LSP is signaled to reroute the traffic. The lower portion shows that a node-protection FRR LSP was set up to protect the hst node, and that the simulation is operating in Fast Reroute mode. Here, the slc node reroutes the LSP traffic around the node failure.
Figure 11-7 Example Full Convergence vs. Fast Reroute with Link Protection
Figure 11-8 Example Full Convergence vs. Fast Reroute with Node Protection
In a network, if a group of interfaces are sourced from the same node (router) and are configured as an SRLG, an FRR LSP protecting one of these interfaces can be configured to reroute around that interface. If possible, the FRR LSP avoids all other interfaces in the SRLG. In WAE Design, FRR LSPs can be configured to avoid all objects defined in the SRLG, not just interfaces on the source node of the FRR LSP.
Example: Figure 11-9 shows an example of how this works using the following setup.
- A protected LSP from cr2.hst to cr2.wdc.
- The protected interface is to_cr2.atl, and its source node is cr2.hst.
- An SRLG containing three circuits: cr2.hst_cr2.chi, cr2.hst_cr2.atl, and cr2.hst_cr2.mia.
- This SRLG has been configured on the cr2.hst node.
When the cr2.hst_cr2.atl circuit fails and there is no SRLG protection, circuits within the SRGL can be used to reroute the LSP. When there is SRLG protection in place, the LSP is rerouted to avoid all circuits within the SRLG.
Figure 11-9 Example Fast Reroute without and with SRLG Protection
Routing Around Failures
Assuming one or more failures have occurred, the following series of decisions determine which FRR LSP is taken.
Step 1 For each such interface on the LSP path, WAE Design checks for an FRR LSP protecting that interface whose destination is a node further down the path of the LSP.
Step 2 If more than one of these FRR LSPs exist, WAE Design selects the one that is farthest down that path of the protected LSP, thus simulating standard FRR behavior where node protection is preferred over link protection.
If more than one eligible FRR LSP has the same destination farthest down the protected LSP path, then the FRR LSP is chosen arbitrarily amongst them.
Step 3 If more failed circuits or nodes occur after this destination, further FRR LSPs are selected in the same manner.
Identify LSPs for Protection
To be marked for Fast Reroute protection, LSPs must have two properties set in the LSP Properties dialog box (Figure 11-10).
- Routing type must be Autoroute or Forwarding Adjacency. The type appears as “autoroute” or “FA” in the Metric Type column of the LSPs table.
- FRR Enabled must be selected. This appears as T (true) in the FRR Enabled column of the LSPs table. If this is F (false), the LSP is not protected.
Figure 11-10 Protected LSP Properties
Identify SRLGs for Protection
To simulate a router’s “exclude protect” configuration, associate the source node of the protected circuit with the SRLG. If that circuit fails, the FRR LSP reroutes around all circuits within that SRLG. For an example, see Figure 11-9.
Step 1 Right-click the source node of a circuit within an SRLG that you want to protect, and select Properties.
Step 2 Select the SRLG tab.
Step 3 Select one or more SRLGs with which you want to associate this node, and click OK.
FRR LSPs Initializer
The FRR LSPs initializer automatically creates link-protection and/or node-protection FRR LSPs provided two conditions are met, as follows.
- One or more LSPs have their FRR Enabled property set. (See the Identify LSPs for Protection section.)
- One or more interfaces on the path of these LSPs have their FRR Enabled property set. This tells the FRR LSPs initializer how to create the FRR LSPs so that in the event of a failure, the interface would be avoided when the LSP is being rerouted.
– This property is set in the MPLS tab of the interface Properties dialog box. The FRR Enabled column in the Interfaces table shows T (true) if the interface is included or F (false) if it is not.
– Once the FRR LSPs are created, this interface is listed in the FRR Interface column of the LSPs table.
The initializer creates the FRR LSPs based on these FRR Enabled properties and based on whether you select to create link or node protection.
- Link protection—WAE Design creates FRR LSPs for each pair of next-hop nodes (two connected nodes) in the protected LSP path where the egress interface of the first hop has its FRR Enabled property set (Figure 11-11).
- Node protection—WAE Design creates FRR LSPs between each set of next next-hop nodes (three connected nodes) in the protected LSP path where the egress interface by of the first hop has its FRR Enabled property set (Figure 11-12).
These newly created FRR LSPs are named as FRR_<source>_<destination>_<postfix>, where postfix is optional and set in the initializer’s dialog box.
Figure 11-11 Example Link-Protection FRR LSPs Automatically Created
Figure 11-12 Example Node-Protection FRR LSPs Automatically Created
Run FRR LSPs Initializer
Step 1 Select one or more nodes. If you do not select any nodes, the initializer uses all nodes in the plan file.
Step 2 Select the Initializers->FRR LSPs menu.
Step 3 Select whether to create FRR LSPs that protect links (circuits), nodes, or both.
Step 4 Optional: Enter a postfix to add to the end of the names of the newly created FRR LSPs.
Step 5 Click OK.
Manually Create FRR LSPs
This section describes the required properties for an FRR LSP. It does not describe all the options available when creating an LSP.
Step 1 Either select the Insert->LSPs->LSP menu, or right-click in an empty area and select New->LSPs->LSP from the context menu. Alternatively, you can select an existing LSP to modify to be an FRR LSP. If so, right-click the LSP and select Properties.
Step 2 Select the Source site and node of the FRR LSP.
Step 3 Either select the Destination site and node, or enter a NetInt Destination IP address. For information on NetInt Destination IP addresses, see the Unresolved LSP Destinations and Hops section.
Step 4 In the Routing section, select Fast Reroute as the LSP type
Step 5 Specify the interface that is to be avoided during routing by selecting it from the FRR Interface drop-down list or by entering its IP address in the NetInt FRR Interface field. Then press OK.
Run Fast Reroute Simulation
FRR LSPs are routed only when simulating failures in the Fast Reroute simulation mode. To enable the Fast Reroute simulation mode, follow these steps.
Step 1 Either select the Edit->Network Options menu or click the Network Options icon in the Visualization toolbar.
Step 2 Select the Simulation tab.
Step 3 Select the Layer 3 Fast Reroute option, and click OK.
In a network, autobandwidth-enabled LSPs reset their setup bandwidth periodically based on the configured autobandwidth timers, and establish new routes if necessary. In networks with constrained bandwidth, changes in LSP routes can make other LSPs unroutable, which can then affect the amount of traffic in each LSP, the setup bandwidth settings, and the routes taken, without ever converging.
While WAE Design does not simulate this instability, it does simulate autobandwidth-enabled LSPs. In this simulation mode, internally WAE Design first routes the autobandwidth-enabled LSPs with a setup bandwidth of zero. Then, demands are routed to determine the simulated traffic (Traff Sim) through each LSP. The result in the plan file and GUI is that the Traff Sim value is copied to the Setup BW Sim for each autobandwidth-enabled LSP, and these LSPs are then routed using their new Setup BW Sim value. Note that if some LSPs cannot be routed, the Traff Sim and Setup BW Sim values resulting from this process might not match one another for all autobandwidth-enabled LSPs.
There are two autobandwidth simulation modes available. Prior to simulating failures or running Simulation Analysis on autobandwidth-enabled LSPs, select the appropriate mode depending on which state you need to simulate.
- In the Autobandwidth Convergence mode, the network is simulated after the traffic (Traff Sim) has been rerouted to other LSPs, but before the Setup BW Sim values have been reset. This simulates the immediate, less optimal response to failures.
- In the Autobandwidth Convergence Including Failures mode, the network is simulated after the Setup BW Sim values have been reset. This simulates the longer, more optimal response to failures.
Note The Autobandwidth Convergence and Autobandwidth Convergence Including Failures simulation modes are only available in plan files with a single traffic level.
These autobandwidth simulations require that the LSPs have their Autobandwidth property set to T (True), and that one of the two autobandwidth modes be selected from the Network Options dialog box.
Example Autobandwidth Convergence without and with Failures
The network in this example has the following parameters.
- One demand from er1.chi to cr1.wdc.
- Two LSPs: LSP-A from cr1.chi to cr1.wdc and LSP-B from cr2.chi to cr1.wdc.
- Neither of these LSPs has a Setup BW.
- All circuits have a 10,000 Mbps capacity except for one (between cr2.chi and cr1.wdc), which is only 1,000 Mbps.
- Figure 11-13 shows that in the IGP and LSP Reconvergence mode, the Setup BW Sim value for both LSPs is 0.
– In the Autobandwidth Convergence mode, the Setup BW Sim value for LSP-A is copied from its Traff Sim value, which is 5,000.
– There are no failures, and each LSP follows the same route in both convergence modes.
- Figure 11-14 shows the Autobandwidth Convergence mode when there is a failure.
– Failing the circuit between cr1.chi and cr1.wdc causes LSP-A to reroute through cr2.chi.
– The shortest path from er1.chi through cr1.chi is now longer than the shortest path from er1.chi through cr2.chi, and so the demand moves ("sloshes") over to LSP-B. This is shown in the LSPs table where the traffic (Traff Sim) of LSP-A is moved to LSP-B.
– Since the smaller of the two circuits is congested, LSP-A uses the larger circuit, which has enough capacity to carry the traffic.
– LSP-B continues to route on the lower capacity circuit, thus causing congestion.
– The Setup BW Sim value is not updated for either LSP because the Autobandwidth Convergence mode does not update setup bandwidth as a result of traffic shifts due to failure.
- Figure 11-15 shows the same failure in Autobandwidth Convergence Including Failures mode.
– The LSP-B Setup BW Sim is updated to the Traff Sim value, forcing it to take the larger circuit to reach its destination. Note that the plot shows both the normal (solid) and failure (dashed) route for LSP-B, indicating that it has rerouted under the failure, even though the failure did not interrupt its path.
– The demand continues to route on LSP-B, but since the LSP has found a path with sufficient capacity, there is no more congestion.
Figure 11-13 Example LSP Routing Using IGP and LSP Reconvergence and Using Autobandwidth Convergence
Figure 11-14 Example Autobandwidth Convergence with Failures
Figure 11-15 Example Autobandwidth Convergence Including Failures
Advanced RSVP-TE LSP Simulations
Ignore Reservable Bandwidths for Capacity Planning
When using WAE Design for capacity planning, it is common to increase the demand traffic to a level expected at a future date. Various simulations are then performed, such as failures and worst-case analysis, to determine which circuits will likely experience over-utilization.
In MPLS networks using RSVP-TE LSPs, a setup bandwidth is configured for each LSP. If the demand traffic is increased, LSP setup bandwidths are usually increased correspondingly (for example, by using the LSP Setup Bandwidth initializer). When these LSP setup bandwidths become too large, some LSPs might not be routable, thus rendering an improbable view of the future network. When this occurs, you have the option to temporarily remove the reservable bandwidth constraints for a more realistic view into future capacity requirements. While this is not a routing method that actually exists on routers, it is a convenient WAE Design simulation that can assist you when planning networks.
When you enable this routing mode, WAE Design routes LSPs in the order they appear in the plan file LSPs table, as described in the following steps. Note that static order of the LSPs table in the plan file likely differs from the order of LSPs in the GUI, which changes frequently due to user interaction. For information on tables in plans files, see the WAE Design Integration and Development Guide.
This operates only on LSPs that do not have autobandwidth enabled (the Autobandwidth property is set to False).
Step 1 Route LSPs as usual. (For information, see the Dynamic LSP Routing and CSPF section.)
Step 2 If an LSP is not routable (call it “LSP-A”), attempt to route it with zero setup bandwidth.
- If LSP-A cannot be routed, leave it unrouted and attempt to route the next LSP in the LSPs table. If this LSP cannot be routed, attempt to route the next LSP listed in the LSPs table in the plan file.
- If LSP-A can be routed, then there will be one or more interfaces on its route whose reservable bandwidth is exceeded. These interfaces are marked as having unlimited reservable bandwidth during the simulation of all subsequent LSPs, thus allowing for the routing of LSP-A and other LSPs that would otherwise exceed the reservable bandwidth on these interfaces. Note that actual Resv BW and Resv BW Sim values in the Interfaces table do not change.
On completion of the simulation, a number of interfaces will have their reserved bandwidth greater than their configured reservable bandwidth. The circuits containing these interfaces are candidates for capacity expansion.
In this example, there are four LSPs, each with a setup bandwidth (Setup BW) of 600 Mbps. All interfaces have a reservable bandwidth (Resv BW) of 1,000 Mbps.
– LSP-1, LSP-2, and LSP-3 go from LON to FRA.
– LSP-4 goes from LON to ROM.
– Interfaces between PAR and FRA, and interfaces between FRA and ROM have an IGP metric of 2.
– All other interfaces have an IGP metric of 1.
Figure 11-16 shows the LSP Reservations view of this simple network in both simulations modes: the usual where reservable bandwidths are observed and the capacity planning version wherein they are ignored. In this latter mode, the two purple circuits indicate they are being over utilized and likely need their capacity increased. (For information on the LSP Reservations view, see the View LSP Reservations section.)
Figure 11-16 Comparison of Reservable Bandwidth Being Used vs Not Being Used
Figure 11-17 demonstrates routing simulations where reservable bandwidth constraints are applied, which is the default behavior.
- LSP-1 routes across LON-AMS-FRA, leaving circuits LON-AMS and AMS-FRA each with only 400 Mbps of available bandwidth.
- LSP-2 routes across LON-PAR-FRA, leaving circuits LON-PAR and PAR-FRA each with only 400 Mbps of available bandwidth.
- LSP-3 cannot be routed because there is not enough available bandwidth on LON-AMS or LON-PAR. Its Setup BW Sim value in the LSPs table is set to “na” and the Routed column is set to “Unrouted.”
- LSP-4 cannot be routed, again because there is not enough available bandwidth. Its Setup BW Sim value in the LSPs table is set to “na” and the Routed column is set to “Unrouted.”
Figure 11-17 Simulated Routing Using Reservable Bandwidth Constraints
In Figure 11-18, the use of reservable bandwidth constraints has been disabled. The LSP routes are now as follows.
- As with the default behavior, LSP-1 routes across LON-AMS-FRA and LSP-2 routes across LON-PAR-FRA.
- Once it is determined that there is not enough reservable bandwidth for LSP-3 to route, it takes the shortest path, LON-AMS-FRA. The reservable bandwidth on interfaces LON-to-AMS and AMS-to-FRA is ignored for the remainder of this simulation. LSP-3’s Setup BW Sim value in the LSPs table is set to 600.
- LSP-4 routes across LON-AMS-FRA-ROM because these reservable bandwidth constraints have been removed and because it is the only route available. Even though LON-PAR-MAD-ROM is the shortest path, there is not enough reservable bandwidth on LON-to-PAR or PAR-to-FRA. LSP-4’s Setup BW Sim value in the LSPs table is set to 600.
Figure 11-18 Simulated Routing Without Using Reservable Bandwidth Constraints
If, however, LSP-4 were routed before LSP-3, then LSP-4 would route across its shortest path of LON-PAR-MAD-ROM, and the LON-to-PAR interface would have its reservable bandwidth constraint ignored. With this routing, LSP-3 would still route LON-AMS-FRA, and the interfaces LON-to-AMS and AMS-to-FRA would still be set to remove their reservable bandwidth constraint.
Enable Capacity Planning Mode for LSPs
To ignore reservable bandwidth constraints in routing simulations, follow these steps.
Step 1 Either select the Edit->Network Options menu or click the Network Options icon in the Visualization toolbar.
Step 2 Select the Simulation tab.
Step 3 Select the option to use the LSP capacity planning mode, thus ignoring reservable bandwidth constraints, and click OK.
Point-to-multipoint (P2MP) LSPs offer an MPLS alternative to IP multicast for setting up multiple paths to multiple locations from a single source. In live networks, the signal is sent once across the network and packets are replicated only at the relevant or designated branching MPLS nodes.
A P2MP LSP consists of two or more sub-LSPs that have the same source node. Most of WAE Design refers to sub-LSPs as LSPs, and there is no distinction between the two.
To view the P2MP LSPs or their associated sub-LSPs, select them from the P2MP LSPs and LSPs tables.
- To determine if an LSP belongs to a P2MP LSP, you can show the P2MP LSP column in the LSPs table. You can also right-click an LSP, and select Filter to P2MP LSPs.
- To determine which LSPs belong to a P2MP LSP, you can visually see them by selecting the P2MP LSP from the P2MP LSPs table. You can also right-click a P2MP LSP, and select Filter to sub LSPs.
Figure 11-19 P2MP LSP with chi as the Source for Three Destinations
P2MP LSP Bandwidth
All sub-LSPs within a given P2MP LSP share bandwidth and therefore, common circuits between these sub-LSPs have the same bandwidth, rather than an aggregate. Common practice is to set all sub-LSPs within a P2MP LSP to the same bandwidth. If you do not, the bandwidth for the shared circuit will be the highest bandwidth set.
To see the reserved LSP bandwidth, show the LSP Resv column in the Interfaces table. You can also view the associated traffic by selecting LSP Reservations in the Network Plot pull-down menu located in the Visualization toolbar. For more information, see the View LSP Reservations section.
Example: If A-C LSP and A-D LSP each have a bandwidth 400 Mbps, the A-B circuit has an aggregate bandwidth of 800 Mbps (Figure 11-20). However, if A-C and A-D are sub-LSPs within a P2MP LSP, the A-B circuit has a bandwidth of 400 Mbps (Figure 11-21).
Figure 11-20 Bandwidth Behavior without a P2MP LSP
Figure 11-21 Bandwidth Behavior with a P2MP LSP
P2MP LSP Demands
Demands routed through P2MP LSPs must have the same source as the P2MP LSP; the demand then terminates at each of the P2MP LSP destinations. No other demands can go through the P2MP LSP except for the one created for it. If the P2MP LSP fails, its demand cannot be routed. (See the Create Demands for P2MP LSPs section for information on creating these demands.)
Demands must be private to the P2MP LSP. This privacy is automatically created when you insert a demand for a P2MP LSP. For information on private LSPs, see the MPLS Simulation chapter.
For complex P2MP LSP demands, filter to the demand, right-click on the demand, and select Plot Demand. Figure 11-22 shows an example of a demand plot for the P2MP LSP shown in Figure 11-19.
Figure 11-22 Example Demand Plot for P2MP LSP
Explicit P2MP LSP Path Initializer
The Explicit P2MP LSP Paths Initializer automates the process of creating explicitly routed sub-LSP paths, as follows.
- Convert a set of dynamically routed sub-LSPs to explicitly routed sub-LSPs along their current paths.
- Create disjoint paths. Two PSMP LSP paths are disjoint if they do not route over common objects. These objects are configurable and may be circuits, nodes, sites, SRLGs, or L1 links.
– Create disjoint paths between sub-LSPs that have the same destination and whose P2MP LSPs belong to the same disjoint P2MP LSP group. This is useful for creating an alternate path if one of the sub-LSP paths becomes unavailable.
Example: Figure 11-23 shows two P2MP LSPs (Region A and Region B) that are in the same disjoint group. Their sub-LSPs share two common destinations: bos and atl. Upon choosing this option, the sub-LSPs in Region B are rerouted such that they arrive at the common destinations using different explicit paths.
– Create disjoint primary and secondary paths for selected sub-LSPs.
Figure 11-23 Example Disjoint Paths for P2MP LSPs
WAE Design creates named paths and named path hops for the sub-LSP paths. After running the initializer, you can verify the named paths and their hops in the Named Paths and Named Path Hops table, respectively.
- If you choose a disjoint option that creates secondary paths, the secondary named path follows the shortest alternate sub-LSP path that is disjoint from the primary path, according to rules that you specify.
- Orphaned named paths are deleted.
- The explicit paths are named <Sub-LSP Name>_<Path Option>.
- The plan file must already contain the LSP paths.
- If creating disjoint paths between P2MP LSPs in the same disjoint group, the P2MP LSPs must first be added to the disjoint group in the P2MP LSP Properties dialog box. Here, you can also assign priorities to P2MP LSPs within these groups. Higher priority P2MP LSPs are assigned shorter routes based on the TE metric. The higher the number, the lower the priority.
Step 1 From the P2MP LSPs table, select the P2MP LSPs to initialize with explicit named paths. If you do not select any P2MP LSPs, all sub-LSP paths are used for creating he named paths.
Step 2 Select the Initializers->P2MP LSP Explicit Paths menu, or right-click a selected P2MP LSP and select Explicit Path Initializer from the context menu. The P2MP LSP Explicit Path Initializer dialog box appears.
Step 3 Select how to create the explicitly routed named paths, and then click OK.
- To create named paths for all currently simulated primary or standby sub-LSP paths, select the “Follow currently simulated routes” option.
- To create disjoint paths, select whether to create them between disjoint PSMP LSPs that have sub-LSPs with the same destination, or between disjoint primary and secondary sub-LSP paths.
- To modify the disjoint priorities that determine which objects are considered in the paths, click Edit. A dialog box appears enabling you to specify priorities as 1, 2, 3, or Ignore, where the lower the number, the higher the priority. Click OK.
Example: If you give circuits a priority of 1, SRLGs a priority of 2, and ignore the other objects, then when the disjoint paths are created, WAE Design first creates paths with disjoint circuits. Then, if there are common SRLGs in those paths, it further creates paths such that the SRLGs are disjoint. The remaining objects are not considered in the disjoint path creating.
Create P2MP LSPs and Sub-LSPs
Rules and Guidelines
- All sub-LSPs within a given P2MP LSP must have the same source site and source node.
- Since sub-LSPs within a P2MP LSP share setup bandwidth, typically bandwidth is set to the same value for each sub-LSP.
Create P2MP LSPs
Step 1 Create an empty P2MP LSP.
a. Either select the Insert->LSPs-> P2MP LSP menu, or right-click in the plot and select New->LSPs->P2MP LSP from the context menu. A P2MP LSP dialog box appears.
b. Enter a unique P2MP LSP name. If you do not enter a name, WAE Design creates one using the format p2mp_lsp_<source_node>.
c. Select both the source site and node. This selection is the root for all sub-LSPs contained within this P2MP LSP.
d. Optional: Enter or select a disjoint group and disjoint priority for WAE Design to consider when using the Explicit P2MP LSP Path Initializer. For more information, see the Explicit P2MP LSP Path Initializer section.
Step 2 If you have not done so, create sub-LSPs for the P2MP LSP. See the Create Sub-LSPs section.
Step 3 Associate the sub-LSPs to the P2MP LSP. You can follow these steps individually, or you can select multiple sub-LSPs and edit them collectively.
a. Double-click the sub-LSPs from the LSP table. The LSP Properties dialog box appears.
b. In the Sub-LSP of P2MP LSP list (at the bottom), select the P2MP LSP to which you want these LSPs to belong. Then click OK.
Step 1 Either select the Insert->LSPs->LSP menu, or right-click in the plot and select New->LSPs->LSP from the context menu. An LSP dialog box appears.
Step 2 In the Source fields, select the site and node that will be the source of the P2MP LSP. All sub-LSPs within a P2MP LSP must have the same source site and source node.
Step 3 In the Destination fields, select the site and node that are the final destination for the sub-LSP.
Step 4 Complete the remaining optional fields and tabs, as needed. Since sub-LSPs share bandwidth, typically the CSPF Setup Bandwidth field is set to the same value for each sub-LSP in the P2MP LSP.
Step 5 If you have already created the P2MP LSP to which this sub-LSP will belong, select that P2MP LSP from the Sub-LSP of P2MP LSP list (at the bottom). Then click OK.
Create a Mesh of Sub-LSPs
Step 1 For each node that will be the egress node of the P2MP LSP, create the same tag name.
a. In the Nodes table, select and then double-click all nodes that will be included in the P2MP LSP. The Properties dialog box appears.
b. Select the Tags tab.
Click New Tag.
Enter a name that collectively identifies the sub-LSPs you are creating.
c. Click OK in the Properties dialog box. Note if you close without clicking OK again, the above changes are not saved.
Step 2 In the Nodes table, select the node you will be designating as the source for the P2MP LSP.
Step 3 Either select the Insert->LSPs->LSP Mesh menu, or right-click in the plot and select New->LSPs->LSP Mesh from the context menu. An LSP Mesh Creator dialog box appears.
Step 4 Deselect these two fields.
- Same Destinations as Sources
- Also create LSPs from destination to source
Step 5 In the Source Nodes menu, select the Selected in table (#/#) option. All sub-LSPs within a P2MP LSP must have the same source node. A P2MP LSP cannot have multiple source nodes.
Step 6 In the Destination Nodes menu, select the newly created tag name.
Step 7 To set the bandwidth to be the same for all sub-LSPs in this mesh, enter that value in the Fixed Value___Mbps field.
To use the autobandwidth feature so that these LSPs have their Setup BW Sim value automatically calculated and used in autobandwidth simulations, select the Autobandwidth option.
Step 8 Complete the remaining optional fields as needed, and then click OK.
Create Demands for P2MP LSPs
To simulate traffic routing through a P2MP LSP, create a demand for it.
Step 1 If you want to create demands for selected P2MP LSPs, select one or more P2MP LSPs from the P2MP LSP table.
Step 2 Either select the Insert->LSPs->Demands for P2MP LSPs menu, or right-click in the plot and select New->LSPs->Demands for P2MP LSPs from the context menu. A Create Demands for P2MP LSPs dialog box appears.
a. Select the P2MP LSPs through which you are routing traffic.
b. Optional: Select a service class for the newly created demand.
c. Select the desired bandwidth: Minimum sub-LSP Setup BW or Zero. Then click OK.
Delete P2MP LSPs and Sub-LSPs
Note Deleting a P2MP LSP also deletes all sub-LSPs within it. If you do not want all the sub-LSPs deleted, then disassociate them first.
Disassociate Sub-LSPs from their P2MP LSPs
Step 1 In the LSPs table, select one or more sub-LSPs.
Step 2 Double-click to open the Properties dialog box.
Step 3 In the Sub-LSP of P2MP LSP list, either
- Select the empty row to disassociate the sub-LSP and change it to an LSP, or
- Select a different P2MP LSP to associate the sub-LSP with a different P2MP LSP.
Step 4 Click OK.
Delete Sub-LSPs or P2MPs
Delete Sub-LSPs but Keep P2MP LSP
Delete P2MP LSP and Associated Sub-LSPs
Right-click one or more sub-LSPs from the LSPs table.
Select Yes to continue.
Right-click one or more P2MP LSPs from the P2MP LSP table.
Select Yes to continue.
Unresolved LSP Destinations and Hops
RSVP-TE LSP configurations and state are read using network discovery from the source node of the LSP, through SNMP, the Parse Configs tool, or other methods. These configurations might reference nodes or interfaces that do not exist in the plan file, so they are referred to as being unresolved. For example, the LSP destination node, read from the configuration on the source, might not be in the plan file. There are several reasons for these differences.
- The plan file was modified to contain fewer nodes than are in the IGP.
- WAE Collector discovery tools have not been able to read all the nodes, or not able to obtain the IP addresses of all the nodes.
- The LSPs themselves are not configured correctly.
References that might not be resolved are as follows.
- Destination nodes of the LSPs.
- Hops in named paths configured on the source node.
- Hops in the actual paths read from the source node.
WAE Collector discovery tools attempt to resolve as many of these references as possible. Following is how the related tables and columns are updated.
- If the LSP destinations are resolved, they are updated in the Destination column of the LSPs table. If they are not resolved, the column remains empty. The original IP address remains in the NetInt Destination column regardless of whether the destination is resolved or not.
- If the hops are resolved, they are updated in the Node and Interface columns in the Named Path Hops and Actual Path Hops tables. If they are not resolved, the columns remain empty. The original IP address remains in the NetIntHop column regardless of whether the destination is resolved or not.
WAE Design does not make further attempts to resolve these references unless you explicitly make the request. There are special cases in which this might be useful. For example, if additional nodes are added to a network from a second network discovery procedure and if LSPs in the original network have unresolved references to these nodes, it is useful to resolve the LSPs again.
Resolve Plan File to Objects
If plan files have configurations that are not matched or refer to objects outside the modeled network, there are three ways to resolve these differences.
- Resolve LSP destinations, hops in named paths, or hops in actual paths using the Resolve Plan Initializer.
- Resolve named path hops in the named paths Properties dialog box.
- Resolve named path hops in the named path hops Properties dialog box.