Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Basic LSP Configuration

 

Configuring LSP Metrics

The LSP metric is used to indicate the ease or difficulty of sending traffic over a particular LSP. Lower LSP metric values (lower cost) increase the likelihood of an LSP being used. Conversely, high LSP metric values (higher cost) decrease the likelihood of an LSP being used.

The LSP metric can be specified dynamically by the router or explicitly by the user as described in the following sections:

Configuring Dynamic LSP Metrics

If no specific metric is configured, an LSP attempts to track the IGP metric toward the same destination (the to address of the LSP). IGP includes OSPF, IS-IS, Routing Information Protocol (RIP), and static routes. BGP and other RSVP or LDP routes are excluded.

For example, if the OSPF metric toward a router is 20, all LSPs toward that router automatically inherit metric 20. If the OSPF toward a router later changes to a different value, all LSP metrics change accordingly. If there are no IGP routes toward the router, the LSP raises its metric to 65,535.

Note that in this case, the LSP metric is completely determined by IGP; it bears no relationship to the actual path the LSP is currently traversing. If LSP reroutes (such as through reoptimization), its metric does not change, and thus it remains transparent to users. Dynamic metric is the default behavior; no configuration is required.

Configuring Static LSP Metrics

You can manually assign a fixed metric value to an LSP. Once configured with the metric statement, the LSP metric is fixed and cannot change:

You can include this statement at the following hierarchy levels:

The LSP metric has several uses:

  • When there are parallel LSPs with the same egress router, the metrics are compared to determine which LSP has the lowest metric value (the lowest cost) and therefore the preferred path to the destination. If the metrics are the same, the traffic is shared.

    Adjusting the metric values can force traffic to prefer some LSPs over others, regardless of the underlying IGP metric.

  • When an IGP shortcut is enabled (see Using Labeled-Switched Paths to Augment SPF to Compute IGP Shortcuts), an IGP route might be installed in the routing table with an LSP as the next hop, if the LSP is on the shortest path to the destination. In this case, the LSP metric is added to the other IGP metrics to determine the total path metric. For example, if an LSP whose ingress router is X and egress router is Y is on the shortest path to destination Z, the LSP metric is added to the metric for the IGP route from Y to Z to determine the total cost of the path. If several LSPs are potential next hops, the total metrics of the paths are compared to determine which path is preferred (that is, has the lowest total metric). Or, IGP paths and LSPs leading to the same destination could be compared by means of the metric value to determine which path is preferred.

    By adjusting the LSP metric, you can force traffic to prefer LSPs, prefer the IGP path, or share the load among them.

  • If router X and Y are BGP peers and if there is an LSP between them, the LSP metric represents the total cost to reach Y from X. If for any reason the LSP reroutes, the underlying path cost might change significantly, but X’s cost to reach Y remains the same (the LSP metric), which allows X to report through a BGP multiple exit discriminator (MED) a stable metric to downstream neighbors. As long as Y remains reachable through the LSP, no changes are visible to downstream BGP neighbors.

It is possible to configure IS-IS to ignore the configured LSP metric by including the ignore-lsp-metrics statement at the [edit protocols isis traffic-engineering shortcuts] hierarchy level. This statement removes the mutual dependency between IS-IS and MPLS for path computation. For more information, see the Junos OS Routing Protocols Library.

Configuring a Text Description for LSPs

You can provide a textual description for an LSP by enclosing any descriptive text that includes spaces within quotation marks (" "). The descriptive text you include is displayed in the detail output of the show mpls lsp or the show mpls container-lsp command.

Adding a text description for an LSP has no effect on the operation of the LSP. The LSP text description can be no more than 80 characters in length.

To provide a textual description for an LSP, include the description statement at any of the following hierarchy levels:

Before you begin:

  • Configure the device interfaces.

  • Configure the device for network communication.

  • Enable MPLS on the device interfaces.

  • Configure an LSP in the MPLS domain.

To add a text description for an LSP:

  1. Enter any text describing the LSP.

    For example:

  2. Verify and commit the configuration.

    For example:

  3. View the description of an LSP using the show mpls lsp detail or show mpls container-lsp detail command, depending on the type of LSP configured.
    user@host> show mpls lsp detail

Configuring MPLS Soft Preemption

Soft preemption attempts to establish a new path for a preempted LSP before tearing down the original LSP. The default behavior is to tear down a preempted LSP first, signal a new path, and then reestablish the LSP over the new path. In the interval between when the path is taken down and the new LSP is established, any traffic attempting to use the LSP is lost. Soft preemption prevents this type of traffic loss. The trade-off is that during the time when an LSP is being soft preempted, two LSPs with their corresponding bandwidth requirements are used until the original path is torn down.

MPLS soft preemption is useful for network maintenance. For example, you can move all LSPs away from a particular interface, then take the interface down for maintenance without interrupting traffic. MPLS soft preemption is described in detail in RFC 5712, MPLS Traffic Engineering Soft Preemption.

Soft preemption is a property of the LSP and is disabled by default. You configure it at the ingress of an LSP by including the soft-preemption statement:

You can include this statement at the following hierarchy levels:

You can also configure a timer for soft preemption. The timer designates the length of time the router should wait before initiating a hard preemption of the LSP. At the end of the time specified, the LSP is torn down and resignaled. The soft-preemption cleanup timer has a default value of 30 seconds; the range of permissible values is 0 through 180 seconds. A value of 0 means that soft preemption is disabled. The soft-preemption cleanup timer is global for all LSPs.

Configure the timer by including the cleanup-timer statement:

You can include this statement at the following hierarchy levels:

Note

Soft preemption cannot be configured on LSPs for which fast reroute has been configured. The configuration fails to commit. However, you can enable soft preemption in conjunction with node and link protection.

Note

The counter value for SoftPreemptionCnt initializes with a value of 0 (zero), visible in the command show rsvp interface detail output.

Configuring Priority and Preemption for LSPs

When there is insufficient bandwidth to establish a more important LSP, you might want to tear down a less important existing LSP to free the bandwidth. You do this by preempting the existing LSP.

Whether an LSP can be preempted is determined by two properties associated with the LSP:

  • Setup priority—Determines whether a new LSP that preempts an existing LSP can be established. For preemption to occur, the setup priority of the new LSP must be higher than that of the existing LSP. Also, the act of preempting the existing LSP must produce sufficient bandwidth to support the new LSP. That is, preemption occurs only if the new LSP can be set up successfully.

  • Reservation priority—Determines the degree to which an LSP holds on to its session reservation after the LSP has been set up successfully. When the reservation priority is high, the existing LSP is less likely to give up its reservation, and hence it is unlikely that the LSP can be preempted.

You cannot configure an LSP with a high setup priority and a low reservation priority, because permanent preemption loops might result if two LSPs are allowed to preempt each other. You must configure the reservation priority to be higher than or equal to the setup priority.

The setup priority also defines the relative importance of LSPs on the same ingress router. When the software starts, when a new LSP is established, or during fault recovery, the setup priority determines the order in which LSPs are serviced. Higher-priority LSPs tend to be established first and hence enjoy more optimal path selection.

To configure the LSP’s preemption properties, include the priority statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Both setup-priority and reservation-priority can be a value from 0 through 7. The value 0 corresponds to the highest priority, and the value 7 to the lowest. By default, an LSP has a setup priority of 7 (that is, it cannot preempt any other LSPs) and a reservation priority of 0 (that is, other LSPs cannot preempt it). These defaults are such that preemption does not happen. When you are configuring these values, the setup priority should always be less than or equal to the hold priority.

Configuring Administrative Groups for LSPs

Administrative groups, also known as link coloring or resource class, are manually assigned attributes that describe the “color” of links, such that links with the same color conceptually belong to the same class. You can use administrative groups to implement a variety of policy-based LSP setups.

Administrative groups are meaningful only when constrained-path LSP computation is enabled.

You can assign up to 32 names and values (in the range 0 through 31), which define a series of names and their corresponding values. The administrative names and values must be identical across all routers within a single domain.

Note

The administrative value is distinct from the priority. You configure the priority for an LSP using the priority statement. See Configuring Priority and Preemption for LSPs.

To configure administrative groups, follow these steps:

  1. Define multiple levels of service quality by including the admin-groups statement:

    You can include this statement at the following hierarchy levels:

    • [edit protocols mpls]

    • [edit logical-systems logical-system-name protocols mpls]

    The following configuration example illustrates how you might configure a set of administrative names and values for a domain:

  2. Define the administrative groups to which an interface belongs. You can assign multiple groups to an interface. Include the interface statement:

    You can include this statement at the following hierarchy levels:

    • [edit protocols mpls]

    • [edit logical-systems logical-system-name protocols mpls]

    If you do not include the admin-group statement, an interface does not belong to any group.

    IGPs use the group information to build link-state packets, which are then flooded throughout the network, providing information to all nodes in the network. At any router, the IGP topology, as well as administrative groups of all the links, is available.

    Changing the interface’s administrative group affects only new LSPs. Existing LSPs on the interface are not preempted or recomputed to keep the network stable. If LSPs need to be removed because of a group change, issue the clear rsvp session command.

    Note

    When configuring administrative groups and extended administrative groups together for a link, both the types of administrative groups must be configured on the interface.

  3. Configure an administrative group constraint for each LSP or for each primary or secondary LSP path. Include the label-switched-path statement:

    You can include the label-switched-path statement at the following hierarchy levels:

    • [edit protocols mpls]

    • [edit logical-systems logical-system-name protocols mpls]

    If you omit the include-all, include-any, or exclude statements, the path computation proceeds unchanged. The path computation is based on the constrained-path LSP computation. For information about how the constrained-path LSP computation is calculated, see How CSPF Selects a Path.

    Note

    Changing the LSP’s administrative group causes an immediate recomputation of the route; therefore, the LSP might be rerouted.

Configuring Extended Administrative Groups for LSPs

In MPLS traffic engineering, a link can be configured with a set of administrative groups (also known as colors or resource classes). Administrative groups are carried in the interior gateway protocol (IGP) (OSPFv2 and IS-IS) as a 32-bit value assigned to each link. Juniper Networks routers normally interpret this 32-bit value as a bit mask with each bit representing a group, limiting each network to a total of 32 distinct administrative groups (value range 0 through 31).

You configure extended administrative groups, represented by a 32-bit value, expanding the number of administrative groups supported in the network beyond just 32. The original range of values available for administrative groups is still supported for backwards compatibility.

The extended administrative groups configuration accepts a set of interfaces with a corresponding set of extended administrative group names. It converts the names into a set of 32-bit values and propagates this information into the IGP. The extended administrative group values are global and must be identically configured on all the supported routers participating in the network. The domain-wide extended administrative groups database, learned from other routers through IGP flooding, is used by Constrained Shortest Path First (CSPF) for path computation.

The following procedure describes how to configure extended administrative groups:

  1. Configure the admin-groups-extended-range statement:

    You can include this statement at the following hierarchy levels:

    • [edit routing-options]

    • [edit logical-systems logical-system-name routing-options]

    The admin-groups-extended-range statement includes the minimum and maximum options. The range maximum must be greater than the range minimum.

  2. Configure the admin-groups-extended statement:

    You can include this statement at the following hierarchy levels:

    • [edit routing-options]

    • [edit logical-systems logical-system-name routing-options]

    The admin-groups-extended statement enables you to configure a group name and group value for the administrative group. The group value must be within the range of values configured using the admin-groups-extended-range statement.

  3. The extended administrative groups for an MPLS interface consist of the set of extended administrative group names assigned for the interface. The interface extended administrative group names must be configured for the global extended administrative groups.

    To configure an extended administrative group for an MPLS interface, specify the administrative group name within the MPLS interface configuration using the admin-groups-extended statement:

    You can include this statement at the following hierarchy levels:

    • [edit protocols mpls interface interface-name]

    • [edit logical-systems logical-system-name protocols mpls interface interface-name]

  4. The LSP extended administrative groups define the set of include and exclude constraints for an LSP and for a path’s primary and secondary paths. The extended administrative group names must be configured for the global extended administrative groups.

    To configure extended administrative groups for an LSP, include the admin-group-extended statement at an LSP hierarchy level:

    The admin-group-extended statement includes the following options: apply-groups, apply-groups-except, exclude, include-all, and include-any. Each option enables you to configure one or more extended administrative groups.

    For the list of the hierarchy levels at which you can configure this statement, see the statement summary for this statement.

  5. To display the currently configured extended administrative groups, issue the show mpls admin-groups-extended command.
Note

When configuring administrative groups and extended administrative groups together for a link, both the types of administrative groups must be configured on the interface.

Configuring Preference Values for LSPs

As an option, you can configure multiple LSPs between the same pair of ingress and egress routers. This is useful for balancing the load among the LSPs because all LSPs, by default, have the same preference level. To prefer one LSP over another, set different preference levels for individual LSPs. The LSP with the lowest preference value is used. The default preference for RSVP LSPs is 7 and for LDP LSPs is 9. These preference values are lower (more preferred) than all learned routes except direct interface routes.

To change the default preference value, include the preference statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Disabling Path Route Recording by LSPs

The Junos implementation of RSVP supports the Record Route object, which allows an LSP to actively record the routers through which it transits. You can use this information for troubleshooting and to prevent routing loops. By default, path route information is recorded. To disable recording, include the no-record statement:

For a list of hierarchy levels at which you can include the record and no-record statements, see the statement summary section for the statement.

Achieving a Make-Before-Break, Hitless Switchover for LSPs

Adaptive label-switched paths (LSPs) might need to establish a new LSP instance and transfer traffic from an old LSP instance onto the new LSP instance before tearing down the old one. This type of configuration is referred to as a make before break (MBB).

RSVP-TE is a protocol used to establish LSPs in MPLS networks. The Junos OS implementation of RSVP-TE to achieve a hitless (no traffic loss) MBB switchover has relied on configuring the timer values in the following configuration statements:

  • optimize-switchover-delay—Amount of time to wait before switching to the new LSP instance.

  • optimize-hold-dead-delay—Amount of time to wait after switchover and before deletion of the old LSP instance.

Both the optimize-switchover-delay and optimize-hold-dead-delay statements apply to all LSPs that use the make-before-break behavior for LSP setup and teardown, not just for LSPs for which the optimize-timer statement has also been configured. The following MPLS features cause LSPs to be set up and torn down using make-before-break behavior:

  • Adaptive LSPs

  • Automatic bandwidth allocation

  • BFD for LSPs

  • Graceful Routing Engine switchover

  • Link and node protection

  • Nonstop active routing

  • Optimized LSPs

  • Point-to-multipoint (P2MP) LSPs

  • Soft preemption

  • Standby secondary paths

Both the optimize-switchover-delay and optimize-hold-dead-delay statements when configured add an artificial delay to the MBB process. The value of the optimize-switchover-delay statement varies with the size of the Explicit Route Objects (EROs). An ERO is an extension to RSVP that allows an RSVP PATH message to traverse an explicit sequence of routers that is independent of conventional shortest-path IP routing. The value of the optimize-switchover-delay statement also depends on the CPU load on each of the routers on the path. Customers set the optimize-switchover-delay statement by trial and error.

The value of the optimize-hold-dead-delay statement depends on how fast the ingress router moves all application prefixes to point to the new LSP. This is determined by the Packet Forwarding Engine load, which can vary from platform to platform. Customers have to set the optimize-hold-dead-delay statement by trial and error.

However, as of Release 15.1, Junos OS is able to achieve a hitless MBB switchover without configuring the artificial delays that such timer values introduce.

This topic summarizes the three methods of achieving a MBB switchover from an old LSP to a new LSP using Junos OS:

Specifying the Amount of Time the Router Waits to Switch Over to New Paths

To specify the amount of time the router waits to switch over LSP instances to newly optimized paths, use the optimize-switchover-delay statement. You only need to configure this statement on routers acting as the ingress for the affected LSPs (you do not need to configure this statement on transit or egress routers). The timer in this statement helps to ensure that the new optimized paths have been established before traffic is switched over from the old paths. This timer can only by enabled or disabled for all of the LSPs configured on the router.

To configure the amount of time the router waits to switch over LSP instances to newly optimized paths, specify the time in seconds by using the optimize-switchover-delay statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

Specifying the Amount of Time to Delay the Tear Down of Old Paths

To specify the amount of time to delay the tear down of old paths after the router has switched traffic to new optimized paths, use the optimize-hold-dead-delay statement. You only need to configure this statement on routers acting as the ingress for the affected LSPs (you do not need to configure this statement on transit or egress routers). The timer in this statement helps to ensure that old paths are not torn down before all routes have been switched over to the new optimized paths. This timer can be enabled for specific LSPs or for all of the LSPs configured on the router.

To configure the amount of time in seconds to delay the tear down of old paths after the router has switched traffic to new optimized paths, use the optimize-hold-dead-delay statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Achieving a Hitless, MBB Switchover Without Artificial Delays

As of Junos OS Release 15.1, there is another way to relinquish the old LSP instances after MBB switchover without relying on the arbitrary time intervals set up by the optimize-switchover-delay or optimize-hold-dead-delay statement. For example, if you use the optimize-hold-dead-delay statement, you configure a time you think it is safe to wait before tearing down the old LSP instance after MBB. However, some routes might still be in the process of shifting to the new instance. Tearing down the old LSP instance prematurely results in one of the transit nodes dropping the traffic for those routes that have not shifted to the new LSP instance.

To avoid traffic loss, instead of using the optimize-switchover-delay statement, you can use MPLS-OAM (lsp ping), which confirms that the LSP data plane is established end-to-end. Instead of using the optimize-hold-dead-delay statement, you can use a feedback mechanism from the rpd infrastructure that confirms that all prefixes referring to the old LSP have been switched over. The feedback mechanism is sourced from the Tag library and relies on the routing protocol process (rpd) infrastructure to determine when all the routes using the old LSP instance have fully shifted to the new LSP instance after MBB switchover.

The feedback mechanism is always in place, and it is optional. Configure the optimize-adaptive-teardown statement to have the feedback mechanism used during MBB switchover. This feature is not supported for RSVP point-to-multipoint (P2MP) LSP instances. Global configuration of the optimize-adaptive-teardown statement only affects the point-to-point LSPs that are configured in the system.

You only need to configure the optimize-adaptive-teardown statement on routers acting as the ingress for the affected LSPs (you do not need to configure this statement on transit or egress routers). This feedback mechanism ensures that old paths are not torn down before all routes have been switched over to the new optimized paths. The global configuration of this configuration statement affects only the point-to-point LSPs that are configured in the system.

You can include this statement at the [edit protocols mpls] hierarchy level.

Optimizing Signaled LSPs

Once an LSP has been established, topology or resources changes might, over time, make the path suboptimal. A new path might have become available that is less congested, has a lower metric, and traverses fewer hops. You can configure the router to recompute paths periodically to determine whether a more optimal path has become available.

If reoptimization is enabled, an LSP can be rerouted through different paths by constrained-path recomputations. However, if reoptimization is disabled, the LSP has a fixed path and cannot take advantage of newly available network resources. The LSP is fixed until the next topology change breaks the LSP and forces a recomputation.

Reoptimization is not related to failover. A new path is always computed when topology failures occur that disrupt an established path.

Because of the potential system overhead involved, you need to carefully control the frequency of reoptimization. Network stability might suffer when reoptimization is enabled. By default, the optimize-timer statement is set to 0 (that is, it is disabled).

LSP optimization is meaningful only when constrained-path LSP computation is enabled, which is the default behavior. For more information about constrained-path LSP computation, see Disabling Constrained-Path LSP Computation. Also, LSP optimization is only applicable to ingress LSPs, so it is only necessary to configure the optimize-timer statement on the ingress router. The transit and egress routers require no specific configuration to support LSP optimization (other than to have MPLS enabled).

To enable path reoptimization, include the optimize-timer statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Once you have configured the optimize-timer statement, the reoptimization timer continues its countdown to the configured value even if you delete the optimize-timer statement from the configuration. The next optimization uses the new value. You can force the Junos OS to use a new value immediately by deleting the old value, committing the configuration, configuring the new value for the optimize-timer statement, and then committing the configuration again.

After reoptimization is run, the result is accepted only if it meets the following criteria:

  1. The new path is not higher in IGP metric. (The metric for the old path is updated during computation, so if a recent link metric changed somewhere along the old path, it is accounted for.)
  2. If the new path has the same IGP metric, it is not more hops away.
  3. The new path does not cause preemption. (This is to reduce the ripple effect of preemption causing more preemption.)
  4. The new path does not worsen congestion overall.

    The relative congestion of the new path is determined as follows:

    1. The percentage of available bandwidth on each link traversed by the new path is compared to that for the old path, starting from the most congested links.

    2. For each current (old) path, the software stores the four smallest values for bandwidth availability for the links traversed in ascending order.

    3. The software also stores the four smallest bandwidth availability values for the new path, corresponding to the links traversed in ascending order.

    4. If any of the four new available bandwidth values are smaller than any of the corresponding old bandwidth availability values, the new path has at least one link that is more congested than the link used by the old path. Because using the link would cause more congestion, traffic is not switched to this new path.

    5. If none of the four new available bandwidth values is smaller than the corresponding old bandwidth availability values, the new path is less congested than the old path.

When all the above conditions are met, then:

  1. If the new path has a lower IGP metric, it is accepted.
  2. If the new path has an equal IGP metric and lower hop count, it is accepted.
  3. If you choose least-fill as a load balancing algorithm, LSPs are load balanced as follows:

    1. The LSP is moved to a new path that is utilized at least 10% less than the current path. This might reduce congestion on the current path by only a small amount. For example, if an LSP with 1 MB of bandwidth is moved off a path carrying a minimum of 200 MB, congestion on the original path is reduced by less than 1%.

    2. For random or most-fill algorithms, this rule does not apply.

    The following example illustrates how the least-fill load balancing algorithm works.
    Figure 1: least-fill Load Balancing Algorithm Example
    least-fill Load Balancing Algorithm
Example

    As shown in Figure 1, there are two potential paths for an LSP to traverse from router A to router H, the odd links from L1 through L13 and the even links from L2 through L14. Currently, the router is using the even links as the active path for the LSP. Each link between the same two routers (for example, router A and router B) has the same bandwidth:

    • L1, L2 = 10GE

    • L3, L4 = 1GE

    • L5, L6 = 1GE

    • L7, L8 = 1GE

    • L9, L10 = 1GE

    • L11, L12 = 10GE

    • L13, L14 = 10GE

    The 1GE links are more likely to be congested. In this example, the odd 1GE links have the following available bandwidth:

    • L3 = 41%

    • L5 = 56%

    • L7 = 66%

    • L9 = 71%

    The even 1GE links have the following available bandwidth:

    • L4 = 37%

    • L6 = 52%

    • L8 = 61%

    • L10 = 70%

    Based on this information, the router would calculate the difference in available bandwidth between the odd links and the even links as follows:

    • L4 - L3 = 41% - 37% = 4%

    • L6 - L5 = 56% - 52% = 4%

    • L8 - L7 = 66% - 61% = 5%

    • L10 - L9 = 71% - 70% = 1%

    The total additional bandwidth available over the odd links is 14% (4% + 4% + 5% + 1%). Since 14% is greater than 10% (the least-fill algorithm minimum threshold), the LSP is moved to the new path over the odd links from the original path using the even links.

  4. Otherwise, the new path is rejected.

You can disable the following reoptimization criteria (a subset of the criteria listed previously):

  • If the new path has the same IGP metric, it is not more hops away.

  • The new path does not cause preemption. (This is to reduce the ripple effect of preemption causing more preemption.)

  • The new path does not worsen congestion overall.

  • If the new path has an equal IGP metric and lower hop count, it is accepted.

To disable them, either issue the clear mpls lsp optimize-aggressive command or include the optimize-aggressive statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

Including the optimize-aggressive statement in the configuration causes the reoptimization procedure to be triggered more often. Paths are rerouted more frequently. It also limits the reoptimization algorithm to the IGP metric only.

Configuring the Smart Optimize Timer for LSPs

Because of network and router resource constraints, it is typically inadvisable to configure a short interval for the optimize timer. However, under certain circumstances, it might be desirable to reoptimize a path sooner than would normally be provided by the optimize timer.

For example, an LSP is traversing a preferred path that subsequently fails. The LSP is then switched to a less desirable path to reach the same destination. Even if the original path is quickly restored, it could take an excessively long time for the LSP to use it again, because it has to wait for the optimize timer to reoptimize the network paths. For such situations, you might want to configure the smart optimize timer.

When you enable the smart optimize timer, an LSP is switched back to its original path so long as the original path has been restored within 3 minutes of going down. Also, if the original path goes down again within 60 minutes, the smart optimize timer is disabled, and path optimization behaves as it normally does when the optimize timer alone is enabled. This prevents the router from using a flapping link.

The smart optimize timer is dependant on other MPLS features to function properly. For the scenario described here in which an LSP is switched to an alternate path in the event of a failure on the original path, it is assumed that you have configured one or more of the MPLS traffic protection features, including fast reroute, link protection, and standby secondary paths. These features help to ensure that traffic can reach its destination in the event of a failure.

At the least, you must configure a standby secondary path for the smart optimize timer feature to work properly. Fast reroute and link protection are more temporary solutions to a network outage. A secondary path ensures that there is a stable alternate path in the event the primary path fails. If you have not configured any sort of traffic protection for an LSP, the smart optimize timer by itself does not ensure that traffic can reach its destination. For more information about MPLS traffic protection, see MPLS and Traffic Protection.

When a primary path fails and the smart optimize timer switches traffic to the secondary path, the router might continue to use the secondary path even after the primary path has been restored. If the ingress router completes a CSPF calculation, it might determine that the secondary path is the better path.

This might be undesirable if the primary path should be the active path and the secondary path should be used as a backup only. Also, if the secondary path is being used as the active path (even though the primary path has been reestablished) and the secondary path fails, the smart optimize timer feature will not automatically switch traffic back to the primary path. However, you can enable protection for the secondary path by configuring node and link protection or an additional standby secondary path, in which case, the smart optimize timer can be effective.

Specify the time in seconds for the smart optimize timer using the smart-optimize-timer statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

Limiting the Number of Hops in LSPs

By default, each LSP can traverse a maximum of 255 hops, including the ingress and egress routers. To modify this value, include the hop-limit statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

The number of hops can be from 2 through 255. (A path with two hops consists of the ingress and egress routers only.)

Configuring the Bandwidth Value for LSPs

Each LSP has a bandwidth value. This value is included in the sender’s Tspec field in RSVP path setup messages. You can specify a bandwidth value in bits per second. If you configure more bandwidth for an LSP, it should be able to carry a greater volume of traffic. The default bandwidth is 0 bits per second.

A nonzero bandwidth requires that transit and egress routers reserve capacity along the outbound links for the path. The RSVP reservation scheme is used to reserve this capacity. Any failure in bandwidth reservation (such as failures at RSVP policy control or admission control) might cause the LSP setup to fail. If there is insufficient bandwidth on the interfaces for the transit or egress routers, the LSP is not established.

To specify a bandwidth value for a signaled LSP, include the bandwidth statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Automatic Bandwidth Allocation for LSPs

Automatic bandwidth allocation allows an MPLS tunnel to automatically adjust its bandwidth allocation based on the volume of traffic flowing through the tunnel. You can configure an LSP with minimal bandwidth; this feature can dynamically adjust the LSP’s bandwidth allocation based on current traffic patterns. The bandwidth adjustments do not interrupt traffic flow through the tunnel.

You set a sampling interval on an LSP configured with automatic bandwidth allocation. The average bandwidth is monitored during this interval. At the end of the interval, an attempt is made to signal a new path for the LSP with the bandwidth allocation set to the maximum average value for the preceding sampling interval. If the new path is successfully established and the original path is removed, the LSP is switched over to the new path. If a new path is not created, the LSP continues to use its current path until the end of the next sampling interval, when another attempt is made to establish a new path. Note that you can set minimum and maximum bandwidth values for the LSP.

During the automatic bandwidth allocation interval, the router might receive a steady increase in traffic (increasing bandwidth utilization) on an LSP, potentially causing congestion or packet loss. To prevent this, you can define a second trigger to prematurely expire the automatic bandwidth adjustment timer before the end of the current adjustment interval.

Configuring Automatic Bandwidth Allocation for LSPs

Automatic bandwidth allocation allows an MPLS tunnel to automatically adjust its bandwidth allocation based on the volume of traffic flowing through the tunnel. You can configure an LSP with minimal bandwidth, and this feature can dynamically adjust the LSP’s bandwidth allocation based on current traffic patterns. The bandwidth adjustments do not interrupt traffic flow through the tunnel.

At the end of the automatic bandwidth allocation time interval, the current maximum average bandwidth usage is compared with the allocated bandwidth for the LSP. If the LSP needs more bandwidth, an attempt is made to set up a new path where bandwidth is equal to the current maximum average usage. If the attempt is successful, the LSP’s traffic is routed through the new path and the old path is removed. If the attempt fails, the LSP continues to use its current path.

Note

In calculating the value for Max AvgBW (relative to the ingress LSP), the sample collected during make before break (MBB) is ignored to prevent inaccurate results. The first sample after a bandwidth adjustment, or after a change in the LSP ID (regardless of path change), is also ignored.

If you have configured link and node protection for the LSP and traffic has been switched to the bypass LSP, the automatic bandwidth allocation feature continues to operate and take bandwidth samples from the bypass LSP. For the first bandwidth adjustment cycle, the maximum average bandwidth usage taken from the original link and node-protected LSP is used to resignal the bypass LSP if more bandwidth is needed. (Link and node protection are not supported on QFX Series switches.)

If you have configured fast-reroute for the LSP, you might not be able to use this feature to adjust the bandwidth. Because the LSPs use a fixed filter (FF) reservation style, when a new path is signaled, the bandwidth might be double-counted. Double-counting can prevent a fast-reroute LSP from ever adjusting its bandwidth when automatic bandwidth allocation is enabled. (Fast reroute is not supported on QFX Series switches.)

To configure automatic bandwidth allocation, complete the steps in the following sections:

Note

On the QFX10000 switches, you can only configure automatic bandwidth allocation at the edit protocols mpls hierarchy level. Logical systems are not supported.

Configuring Automatic Bandwidth Allocation on LSPs

To enable automatic bandwidth allocation on an LSP, include the auto-bandwidth statement:

If an LSP has an automatic bandwidth configuration, you can disable automatic bandwidth adjustments on a particular path (either primary or secondary) by configuring a static bandwidth value and by disabling the CSPF computation (using the no-cspf statement).

For example:

The statements configured at the [edit protocols mpls label-switched-path label-switched-path-name auto-bandwidth] hierarchy level are optional and explained in the following sections:

Configuring the Automatic Bandwidth Allocation Interval

At the end of the automatic bandwidth allocation interval, the automatic bandwidth computation and new path setup process is triggered.

Note

To prevent unnecessary resignaling of LSPs, it is best to configure an LSP adjustment interval that is at least three times longer than the MPLS automatic bandwidth statistics interval. For example, if you configure a value of 30 seconds for the MPLS automatic bandwidth statistics interval (interval statement at the [edit protocols mpls statistics] hierarchy level), you should configure a value of at least 90 seconds for the LSP adjustment interval (adjust-interval statement at the [edit protocols mpls label-switched-path label-switched-path-name auto-bandwidth] hierarchy level). See also Configuring Reporting of Automatic Bandwidth Allocation Statistics for LSPs.

To specify the bandwidth reallocation interval in seconds for a specific LSP, include the adjust-interval statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols mpls label-switched-path lsp-name auto-bandwidth]

  • [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name auto-bandwidth]

Configuring the Maximum and Minimum Bounds of the LSP’s Bandwidth

You can maintain the LSP’s bandwidth between minimum and maximum bounds by specifying values for the minimum-bandwidth and maximum-bandwidth statements.

Note

For a label-swtiched path (LSP) that has both bandwidth and minimum-bandwidth for autobandwidth configured under the [edit protocols mpls label-switched-path lsp-name] hierarchy level, the LSP bandwidth is adjusted differently.

The LSP is initiated with the bandwidth value configured under the bandwidth statement at the [edit protocols mpls label-switched-path lsp-name] hierarchy level. At the expiry of the adjust-interval timer, the LSP bandwidth gets adjusted based on the traffic flow.

If the bandwidth to be signaled is less than the value configured under the minimum-bandwidth statement at the [edit protocols mpls label-switched-path lsp-name autobandwidth] hierarchy level, then the LSP is signaled only using the minimum bandwidth.

If the bandwidth to be signaled is greater than the value configured under the maximum-bandwidth statement at the [edit protocols mpls label-switched-path lsp-name autobandwidth] hierarchy level, then the LSP is signaled only using the maximum bandwidth.

To specify the minimum amount of bandwidth allocated for a specific LSP, include the minimum-bandwidth statement:

You can include this statement at the following hierarchy levels:

To specify the maximum amount of bandwidth allocated for a specific LSP, include the maximum-bandwidth statement:

You can include this statement at the following hierarchy levels:

Configuring the Automatic Bandwidth Adjustment Threshold

Use the adjust-threshold statement to specify the sensitivity of the automatic bandwidth adjustment of an LSP to changes in bandwidth utilization. You can set the threshold for when to trigger automatic bandwidth adjustments. When configured, bandwidth demand for the current interval is determined and compared to the LSP’s current bandwidth allocation. If the percentage difference in bandwidth is greater than or equal to the specified adjust-threshold percentage, the LSP’s bandwidth is adjusted to the current bandwidth demand.

For example, assume that the current bandwidth allocation is 100 megabits per second (Mbps) and that the percentage configured for the adjust-threshold statement is 15 percent. If the bandwidth demand increases to 110 Mbps, the bandwidth allocation is not adjusted. However, if the bandwidth demand increases to 120 Mbps (20 percent over the current allocation) or decreases to 80 Mbps (20 percent under the current allocation), the bandwidth allocation is increased to 120 Mbps or decreased to 80 Mbps, respectively.

To configure the threshold for automatic bandwidth adjustment, include the adjust-threshold statement:

You can include this statement at the following hierarchy levels:

Configuring a Limit on Bandwidth Overflow and Underflow Samples

The automatic bandwidth adjustment timer is a periodic timer which is triggered every adjust interval to determine whether any bandwidth adjustments are required on the LSP's active path. This interval is typically configured as a long period of time, usually hours. If, at the end of adjust interval, the change in bandwidth is above a certain adjust threshold, the LSP is resignaled with the new bandwidth.

During the automatic bandwidth adjustment interval, the router might receive a steady increase in traffic (increasing bandwidth utilization) on an LSP, potentially causing congestion or packet loss. To prevent this, you can define a second trigger to prematurely expire the automatic bandwidth adjustment timer before the end of the current adjustment interval.

Every statistics interval, the router samples the average bandwidth utilization of an LSP and if this has exceeded the current maximum average bandwidth utilization, the maximum average bandwidth utilization is updated.

During each sample period, the following conditions are also checked:

  • Is the current average bandwidth utilization above the active bandwidth of the path?

  • Has the difference between the average bandwidth utilization and the active bandwidth exceeded the adjust threshold (bandwidth utilization has changed significantly)?

If these conditions are true, it is considered to be one bandwidth overflow sample. Using the adjust-threshold-overflow-limit statement, you can define a limit on the number of bandwidth overflow samples such that when the limit is reached, the current automatic bandwidth adjustment timer is expired and a bandwidth adjustment is triggered. Once this adjustment is complete, the normal automatic bandwidth adjustment timer is reset to expire after the periodic adjustment interval.

To specify a limit on the number of bandwidth overflow samples before triggering an automatic bandwidth allocation adjustment, configure the adjust-threshold-overflow-limit statement:

Similarly, if the current average bandwidth utilization is below the active bandwidth of the path by the configured adjusted threshold (meaning that bandwidth utilization has gone down significantly), the sample is considered to be an underflow sample. The adjusted (new signaling) bandwidth after an adjustment due to underflow is the maximum average bandwidth among the underflow samples. Starting in Junos OS Release 14.1R9, 15.1R7, 16.1R5, 16.1X2, 16.2R3, and 17.2R2, all zero value bandwidth samples are considered as underflow samples, except for the zero value samples that arrive after an LSP comes up for the first time, and the zero value samples that arrive first after a Routing Engine switchover.

You can specify a limit on the number of bandwidth underflow samples before triggering an automatic bandwidth allocation adjustment by configuring the adjust threshold-underflow-limit statement:

These statements can be configured at the following hierarchy levels:

You must configure the adjust-threshold and minimum-bandwidth statements whenever you configure the adjust-threshold-underflow-limit statement. You must configure the adjust-threshold and maximum-bandwidth statements whenever you configure the adjust-threshold-overflow-limit statement

  • You must configure a nonzero value for the adjust-threshold statement if you configure the adjust-threshold-overflow-limit or adjust-threshold-underflow-limit statement.

  • Any bandwidth increase or decrease below the value configured for the adjust-threshold statement does not constitute an overflow or underflow condition.

  • To prevent unlimited increases in LSP bandwidth (to limit overflow beyond a certain bandwidth), you must also configure the maximum-bandwidth statement when you configure the adjust-threshold-overflow-limit statement.

The following describes the other aspects of the adjust-threshold-overflow-limit statement:

  • It only applies to bandwidth overflows. If the bandwidth is decreasing, the normal automatic bandwidth adjustment interval is used.

  • It does not affect manually triggered automatic bandwidth adjustment.

  • It applies to single-class DiffServ-TE LSPs.

  • Because the adjust-threshold-overflow-limit statement can trigger a bandwidth adjustment, it cannot be enabled at the same time as the monitor-bandwidth statement (for information about that statement, see Configuring Passive Bandwidth Utilization Monitoring).

  • You cannot configure automatic bandwidth adjustments to occur more often than every 300 seconds. The adjust-threshold-overflow-limit statement is subject to the same minimum value with regard to the minimum frequency of adjustment allowed. Overflow condition based adjustments can occur no sooner than 300 seconds from the start of the overflow condition. Therefore it is required that:

    sample interval x adjust-threshold-overflow-limit >= 300s

    These values are checked during the commit operation. An error is returned if the value is less than 300 seconds.

  • If you change the value of the adjust-threshold-overflow-limit statement on a working router, you can expect the following behavior:

    • If you increase the current value of the adjust-threshold-overflow-limit statement, the old value is replaced with the new one.

    • If you decrease the current value of the adjust-threshold-overflow-limit statement and the current bandwidth overflow count is less than the new value, the old value is replaced with the new one.

    • If you decrease the current value of the adjust-threshold-overflow-limit statement and the current bandwidth overflow count is greater than the new value, the adjustment timer is immediately expired and a bandwidth adjustment is initiated.

Configuring Passive Bandwidth Utilization Monitoring

Use the monitor-bandwidth statement to switch to a passive bandwidth utilization monitoring mode. In this mode, no automatic bandwidth adjustments are made, but the maximum average bandwidth utilization is continuously monitored and recorded.

To configure passive bandwidth utilization monitoring, include the monitor-bandwidth statement:

You can include this statement at the following hierarchy levels:

If you have configured an LSP with primary and secondary paths, the automatic bandwidth allocation statistics are carried over to the secondary path if the primary path fails. For example, consider a primary path whose adjustment interval is half complete and whose maximum average bandwidth usage is currently calculated as 50 Mbps. If the primary path suddenly fails, the time remaining for the next adjustment and the maximum average bandwidth usage are carried over to the secondary path.

Requesting Automatic Bandwidth Allocation Adjustment

For MPLS LSP automatic bandwidth allocation adjustment, the minimum value for the adjustment interval is 5 minutes (300 seconds). You might find it necessary to trigger a bandwidth allocation adjustment manually, for example in the following circumstances:

  • When you are testing automatic bandwidth allocation in a network lab.

  • When the LSP is configured for automatic bandwidth allocation in monitor mode (the monitor-bandwidth statement is included in the configuration as described in Configuring Passive Bandwidth Utilization Monitoring), and want to initiate an immediate bandwidth adjustment.

To use the request mpls lsp adjust-autobandwidth command, the following must be true:

  • Automatic bandwidth allocation must be enabled on the LSP.

  • The criteria required to trigger a bandwidth adjustment have been met (the difference between the adjust bandwidth and the current LSP path bandwidth is greater than the threshold limit).

A manually triggered bandwidth adjustment operates only on the active LSP path. Also, if you have enabled periodic automatic bandwidth adjustment, the periodic automatic bandwidth adjustment parameters (the adjustment interval and the maximum average bandwidth) are not reset after a manual adjustment.

For example, suppose the periodic adjust interval is 10 hours and there are currently 5 hours remaining before an automatic bandwidth adjustment is triggered. If you initiate a manual adjustment with the request mpls lsp adjust-autobandwidth command, the adjust timer is not reset and still has 5 hours remaining.

To manually trigger a bandwidth allocation adjustment, you need to use the request mpls lsp adjust-autobandwidth command. You can trigger the command for all affected LSPs on the router, or you can specify a particular LSP:

user@host> request mpls lsp adjust-autobandwidth

Once you execute this command, the automatic bandwidth adjustment validation process is triggered. If all the criteria for adjustment are met, the LSP’s active path bandwidth is adjusted to the adjusted bandwidth value determined during the validation process.

Configuring Reporting of Automatic Bandwidth Allocation Statistics for LSPs

Automatic bandwidth allocation allows an MPLS tunnel to automatically adjust its bandwidth allocation based on the volume of traffic flowing through the tunnel. You can configure the device to collect statistics related to automatic bandwidth allocation by completing the following steps:

  1. To collect statistics related to automatic bandwidth allocation, configure the auto-bandwidth option for the statistics statement at the [edit protocols mpls] hierarchy level. These settings apply to all LSPs configured on the router on which you have also configured the auto-bandwidth statement at the [edit protocols mpls label-switched-path label-switched-path-name] hierarchy level.
  2. Specify the filename for the files used to store the MPLS trace operation output using the file option. All files are placed in the directory /var/log. We recommend that you place MPLS tracing output in the file mpls-log.
  3. Specify the maximum number of trace files using the files number option. When a trace file named trace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1, and so on, until the maximum number of trace files is reached. Then the oldest trace file is overwritten.
  4. Specify the interval for calculating the average bandwidth usage by configuring a time in seconds using the interval option. You can also set the adjustment interval on a specific LSP by configuring the interval option at the [edit protocols mpls label-switch-path label-switched-path-name statistics] hierarchy level.Note

    To prevent unnecessary resignaling of LSPs, it is best to configure an LSP adjustment interval that is at least three times longer than the MPLS automatic bandwidth statistics interval. For example, if you configure a value of 30 seconds for the MPLS automatic bandwidth statistics interval (interval statement at the [edit protocols mpls statistics] hierarchy level), you should configure a value of at least 90 seconds for the LSP adjustment interval (adjust-interval statement at the [edit protocols mpls label-switched-path label-switched-path-name auto-bandwidth] hierarchy level).

  5. To trace automatic bandwidth allocation, include the autobw-state flag for the MPLS traceoptions statement at the [edit protocols mpls] hierarchy level.

    The following configuration enables the MPLS traceoptions for automatic bandwidth allocation. The trace records are stored in a file called auto-band-trace (the filename is user configurable):

  6. Using the show log command, you can display the automatic bandwidth allocation statistics file generated when you configure the auto-bandwidth (MPLS Statistics) statement. The following shows sample log file output taken from an MPLS statistics file named auto-band-stats on a router configured with an LSP named E-D. The log file shows that LSP E-D is operating over its reserved bandwidth limit initially. Before Oct 30 17:14:57, the router triggered an automatic bandwidth adjustment (you might see two sessions for an LSP undergoing an automatic bandwidth adjustment). By Oct 30 17:16:57, the LSP has been reestablished at a higher bandwidth and is now shown using less than 100 percent of its Reserved Bw (reserved bandwidth).

  7. Issue the show mpls lsp autobandwidth command to display current information about automatic bandwidth allocation. The following shows sample output from the show mpls lsp autobandwidth command taken at about the same time as the log file shown previously:

  8. Issue the file show command to display the MPLS trace file. You need to specify the file location and file name (the file is located in /var/log/. The following shows sample trace file output is taken from an MPLS trace file named auto-band-trace.0.gz on a router configured with an LSP named E-D. The trace file shows that LSP E-D is operating over its reserved bandwidth limit initially. At Oct 30 17:15:26, the router triggers an automatic bandwidth adjustment (you might see two sessions for an LSP undergoing an automatic bandwidth adjustment). By Oct 30 17:15:57, the LSP has been reestablished at a higher bandwidth and is now shown using less than 100 percent of its Reserved Bw (reserved bandwidth).

Configuring an LSP Across ASs

You can configure an LSP to traverse multiple areas in a network by including the inter-domain statement as a part of the LSP configuration. This statement allows the router to search for routes in the IGP database. You need to configure this statement on routers that might be unable to locate a path using intra-domain CSPF (by looking in the traffic engineering database (TED)). When you configure inter-area LSPs, the inter-domain statement is required.

Before you begin:

  • Configure the device interfaces with family MPLS.

  • Configure the device router ID and autonomous system number.

  • Enable MPLS and RSVP on the router and transit interfaces.

  • Configure your IGP to support traffic engineering.

  • Set up an LSP from the ingress to the egress router.

To configure an LSP across multiple ASs on the ingress label-switched router (LER):

  1. Enable MPLS on all the interfaces (excluding the management interface).
  2. Enable RSVP on all the interfaces (excluding the management interface).
  3. Configure the inter-area LSP.
  4. Verify and commit the configuration.

Damping Advertisement of LSP State Changes

When an LSP changes from being up to being down, or from down to up, this transition takes effect immediately in the router software and hardware. However, when advertising LSPs into IS-IS and OSPF, you may want to damp LSP transitions, thereby not advertising the transition until a certain period of time has transpired (known as the hold time). In this case, if the LSP goes from up to down, the LSP is not advertised as being down until it has remained down for the hold-time period. Transitions from down to up are advertised into IS-IS and OSPF immediately. Note that LSP damping affects only the IS-IS and OSPF advertisements of the LSP; other routing software and hardware react immediately to LSP transitions.

To damp LSP transitions, include the advertisement-hold-time statement:

seconds can be a value from 0 through 65,535 seconds. The default is 5 seconds.

You can include this statement at the following hierarchy levels:

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

Configuring Corouted Bidirectional LSPs

A corouted bidirectional packet LSP is a combination of two LSPs sharing the same path between a pair of ingress and egress nodes, as shown in Figure 2. It is established using the GMPLS extensions to RSVP-TE. This type of LSP can be used to carry any of the standard types of MPLS-based traffic, including Layer 2 VPNs, Layer 2 circuits, and Layer 3 VPNs. You can configure a single BFD session for the bidirectional LSP (you do not need to configure a BFD session for each LSP in each direction). You can also configure a single standby bidirectional LSP to provide a backup for the primary bidirectional LSP. Corouted bidirectional LSPs are supported for both penultimate hop popping (PHP) and ultimate hop popping (UHP).

High availability is available for bidirectional LSPs. You can enable graceful restart and nonstop active routing. Graceful restart and nonstop active routing are supported when the restarting router is the ingress, egress, or transit router for the bidirectional LSP.

Figure 2: Corouted Bidirectional LSP
Corouted Bidirectional LSP

To configure a corouted bidirectional LSP:

  1. In configuration mode, configure the ingress router for the LSP and include the corouted-bidirectional statement to specify that the LSP be established as a corouted bidirectional LSP.

    The path is computed using CSPF and initiated using RSVP signaling (just like a unidirectional RSVP signaled LSP). Both the path to the egress router and the reverse path from the egress router are created when this configuration is committed.

  2. (Optional) For a reverse path, configure an LSP on the egress router and include the corouted-bidirectional-passive statement to associate the LSP with another LSP.

    No path computation or signaling is used for this LSP since it relies on the path computation and signaling provided by the ingress LSP. You cannot configure both the corouted-bidirectional statement and the corouted-bidirectional-passive statement on the same LSP.

    This statement also makes it easier to debug corouted bidirectional LSPs. If you configure the corouted-bidirectional-passive statement (again, on the egress router), you can issue ping mpls lsp-end-point, ping mpls ldp, ping mpls rsvp, traceroute mpls ldp, and traceroute mpls rsvp commands to test the corouted bidirectional LSP from the egress router.

  3. Use the show mpls lsp extensive and the show rsvp session extensive commands to display information about the bidirectional LSP.

    The following shows output for the show rsvp session extensive command when run on an ingress router with a bidirectional LSP configured:

    user@PE1> show rsvp session extensive

Configuring the Entropy Label for LSPs

The insertion of entropy labels for an LSP enables transit routers to load-balance MPLS traffic across ECMP paths or Link Aggregation groups using just the MPLS label stack as a hash input without having to rely on deep packet inspection. Deep packet inspection requires more of the router’s processing power and different routers have differing deep-packet inspection capabilities.

To configure the entropy label for an LSP, complete the following steps:

  1. On the ingress router, include the entropy-label statement at the [edit protocols mpls labeled-switched-path labeled-switched-path-name] hierarchy level or at the [edit protocols mpls static-labeled-switched-path labeled-switched-path-name ingress] hierarchy level. The entropy label is added to the MPLS label stack and can be processed in the forwarding plane.

    Note

    This is only applicable for RSVP and static LSPs.

  2. On the ingress router, you can configure an ingress policy for LDP-signaled LSPs:

    Configure the ingress policy at the [edit policy-options] hierarchy level:

    The following shows an example of an entropy label ingress policy.

  3. (Optional) By default, routers that support the pushing and popping of entropy labels are configured with the load-balance-label-capability statement at the [edit forwarding-options] hierarchy level to signal the labels on a per-LSP basis. If the peer router is not equipped to handle load-balancing labels, you can prevent the provider edge (PE) router from signaling the entropy label capability by configuring the no-load-balance-label-capability statement at the [edit forwarding-options] hierarchy level.

Transit routers require no configuration. The presence of the entropy label indicates to the transit router to load balance based solely on the MPLS label stack.

Penultimate hop routers pop the entropy label by default.

Example: Configuring an Entropy Label for a BGP Labeled Unicast LSP

This example shows how to configure an entropy label for a BGP labeled unicast to achieve end-to-end load balancing using entropy labels. When an IP packet has multiple paths to reach its destination, Junos OS uses certain fields of the packet headers to hash the packet to a deterministic path. This requires an entropy label, a special load-balancing label that can carry the flow information. LSRs in the core simply use the entropy label as the key to hash the packet to the correct path. An entropy label can be any label value between 16 to 1048575 (regular 20-bit label range). Since this range overlaps with the existing regular label range, a special label called entropy label indicator (ELI) is inserted before the entropy label. ELI is a special label assigned by IANA with the value of 7.

BGP labeled unicasts generally concatenate RSVP or LDP LSPs across multiple IGP areas or multiple autonomous systems. RSVP or LDP entropy labels are popped at the penultimate hop node, together with the RSVP or LDP label. This feature enables the use of entropy labels at the stitching points to bridge the gap between the penultimate hop node and the stitching point, in order to achieve end-to-end entropy label load balancing for BGP traffic.

Requirements

This example uses the following hardware and software components:

  • Seven MX Series routers with MPCs

  • Junos OS Release 15.1 or later running on all the devices

Before you configure an entropy label for BGP labeled unicast, make sure you:

  1. Configure the device interfaces.
  2. Configure OSPF or any other IGP protocol.
  3. Configure BGP.
  4. Configure RSVP.
  5. Configure MPLS.

Overview

When BGP labeled unicasts concatenate RSVP or LDP LSPs across multiple IGP areas or multiple autonomous systems, RSVP or LDP entropy labels are popped at the penultimate hop node, together with the RSVP or LDP label. However, there are no entropy labels at the stitching points, that is, the routers between two areas. Therefore, the routers at the stitching points used the BGP labels to forward packets.

Beginning with Junos OS Release 15.1, you can configure an entropy label for BGP labeled unicast to achieve end-to-end entropy label load balancing. This feature enables the use of an entropy label at the stitching points in order to achieve end-to-end entropy label load balancing for BGP traffic. Junos OS allows the insertion of entropy labels at the BGP labeled unicast LSP ingress.

By default, routers that support entropy labels are configured with the load-balance-label-capability statement at the [edit forwarding-options] hierarchy level to signal the labels on a per-LSP basis. If the peer router is not equipped to handle load-balancing labels, you can prevent the signaling of entropy label capability by configuring the no-load-balance-label-capability at the [edit forwarding-options] hierarchy level.

Note

You can explicitly disable advertising entropy label capability at egress for routes specified in the policy with the no-entropy-label-capability option at the [edit policy-options policy-statement policy name then] hierarchy level.

Topology

In Figure 3 , Router PE1 is the ingress router and Router PE2 is the egress router. Routers P1 and P2 are the transit routers. Router ABR is the area bridge router between Area 0 and Area 1. LAG is configured on the provider routers for load balancing the traffic. Entropy label capability for BGP labeled unicast is enabled on the ingress Router PE1.

Figure 3: Configuring an Entropy Label for BGP Labeled Unicast
Configuring an Entropy Label
for BGP Labeled Unicast

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Router PE1

Router P1

Router ABR

Router P2

Router PE2

Configuring Router PE1

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Router PE1:

Note

Repeat this procedure for Router PE2 after modifying the appropriate interface names, addresses, and other parameters.

  1. Configure the interfaces with IPv4 and IPv6 addresses.
  2. Configure the loopback interface.
  3. Set the router ID and the autonomous system number.
  4. Configure RSVP protocol for all interfaces.
  5. Enable MPLS on all the interfaces of Router PE1 and specify the LSP.
  6. Configure IBGP on the internal routers.
  7. Enable entropy label capability for BGP labeled unicast for internal BGP group ibgp.
  8. Enable the OSPF protocol on all the interfaces of the area border router (ABR).
  9. Define prefix lists to specify the routes with entropy label capability.
  10. Define a policy EL to specify the routes with entropy label capability.
  11. Define another policy EL-2 to specify the routes with entropy label capability.
  12. Define a policy to export BGP routes to the OSPF routing table.
  13. Define a policy to export OSPF routes to the BGP routing table.
  14. Define a policy to export static routes to the BGP routing table.
  15. Configure a VPN target for the VPN community.
  16. Configure the Layer 3 VPN routing instance VPN-l3vpn.
  17. Assign the interfaces for the VPN-l3vpn routing instance.
  18. Configure the route distinguisher for the VPN-l3vpn routing instance.
  19. Configure a VPN routing and forwarding (VRF) target for the VPN-l3vpn routing instance.
  20. Configure a static route to Device CE1 using the Layer 3 VPN protocol for the VPN-l3vpn routing instance.
  21. Export the BGP routes to the OSPF routing table for the VPN-l3vpn routing instance.
  22. Assign the OSPF interface for the VPN-l3vpn routing instance.

Configuring Router P1

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Router P1:

Note

Repeat this procedure for Router P2 after modifying the appropriate interface names, addresses, and other parameters.

  1. Configure the interfaces with IPv4 and IPv6 addresses.
  2. Configure link aggregation on the interfaces.
  3. Configure the loopback interface.
  4. Configure MPLS labels that the router uses for hashing the packets to its destination for load balancing.
  5. Set the router ID and the autonomous system number.
  6. Enable per packet load balancing.
  7. Configure the RSVP protocol for all interfaces.
  8. Enable MPLS on all the interfaces of Router P1 and specify the LSP.
  9. Enable the OSPF protocol on all the interfaces of Router P1 excluding the management interface.
  10. Define a policy for per packet load balancing.

Configuring Router ABR

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Router ABR:

  1. Configure the interfaces with IPv4 and IPv6 addresses.
  2. Configure the loopback interface.
  3. Configure link aggregation on the interfaces.
  4. Configure MPLS labels that the router uses for hashing the packets to its destination for load balancing.
  5. Set the router ID and the autonomous system number.
  6. Enable per packet load balancing.
  7. Configure the RSVP protocol for all interfaces.
  8. Enable MPLS on all the interfaces of Router P1 and specify the LSP.
  9. Configure IBGP on the internal routers.
  10. Enable the OSPF protocol on all the interfaces of ABR.
  11. Define a policy to specify the routes with entropy label capability.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show routing-options, show forwarding options, and show policy-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

Confirm that the configuration is working properly.

Verifying That the Entropy Label Capability Is Being Advertised from Router PE2

Purpose

Verify that the entropy label capability path attribute is being advertised from the upstream Router PE2 at egress.

Action

From operational mode, run the show route 10.255.101.200 advertising-protocol bgp 10.255.102.102 command on Router PE2.

user@PE2> show route 10.255.101.200 advertising-protocol bgp 10.255.102.102

Meaning

The output shows that the host PE2 with the IP address of 10.255.101.200 has the entropy label capability. The host is advertising the entropy label capability to its BGP neighbors.

Verifying That Router ABR Receives the Entropy Label Advertisement

Purpose

Verify that Router ABR receives the entropy label advertisement at ingress from Router PE2.

Action

From operational mode, run the show route 10.255.101.200 receiving-protocol bgp 10.255.101.200 command on Router ABR.

user@ABR> show route 10.255.101.200 receiving-protocol bgp 10.255.101.200

Meaning

Router ABR receives the entropy label capability advertisement from its BGP neighbor PE2.

Verifying That the Entropy Label Flag Is Set

Purpose

Verify that the entropy label flag is set for the label elements at the ingress.

Action

From operational mode, run the show route protocol bgp detail command on Router PE1.

user@PE1> show route protocol bgp detail

Meaning

An entropy label is enabled on Router PE1. The output shows that the entropy label is being used for the BGP labeled unicast to achieve end-to-end load balancing.

Configuring Ultimate-Hop Popping for LSPs

By default, RSVP-signaled LSPs use penultimate-hop popping (PHP). Figure 4 illustrates a penultimate-hop popping LSP between Router PE1 and Router PE2. Router CE1 forwards a packet to its next hop (Router PE1), which is also the LSP ingress. Router PE1 pushes label 1 on the packet and forwards the labeled packet to Router P1. Router P1 completes the standard MPLS label swapping operation, swapping label 1 for label 2, and forwards the packet to Router P2. Since Router P2 is the penultimate-hop router for the LSP to Router PE2, it first pops the label and then forwards the packet to Router PE2. When Router PE2 receives it, the packet can have a service label, an explicit-null label, or just be a plain IP or VPLS packet. Router PE2 forwards the unlabeled packet to Router CE2.

Figure 4: Penultimate-Hop Popping for an LSP
Penultimate-Hop Popping for an LSP

You can also configure ultimate-hop popping (UHP) (as shown in Figure 5) for RSVP-signaled LSPs. Some network applications can require that packets arrive at the egress router (Router PE2) with a non-null outer label. For an ultimate- hop popping LSP, the penultimate router (Router P2 in Figure 5) performs the standard MPLS label swapping operation (in this example, label 2 for label 3 ) before forwarding the packet to egress Router PE2. Router PE2 pops the outer label and performs a second lookup of the packet address to determine the end destination. It then forwards the packet to the appropriate destination (either Router CE2 or Router CE4).

Figure 5: Ultimate-Hop Popping for an LSP
Ultimate-Hop Popping for an LSP

The following network applications require that you configure UHP LSPs:

  • MPLS-TP for performance monitoring and in-band OAM

  • Edge protection virtual circuits

The following features do not support the UHP behavior:

  • LDP-signaled LSPs

  • Static LSPs

  • Point-to-multipoint LSPs

  • CCC

  • traceroute command

For more information about UHP behavior, see Internet draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt, Non PHP behavior and Out-of-Band Mapping for RSVP-TE LSPs.

For point-to-point RSVP-signaled LSPs, UHP behavior is signaled from the LSP ingress. Based on the ingress router configuration, RSVP can signal the UHP LSP with the non-PHP flag set. RSVP PATH messages carry the two flags in the LSP-ATTRIBUTES object. When the egress router receives the PATH message, it assigns a non-null label to the LSP. RSVP also creates and installs two routes in the mpls.0 routing table. S refers to the S bit of the MPLS label, which indicates whether or not the bottom of the label stack has been reached.

  • Route S=0—Indicates that there are more labels in the stack. The next hop for this route points to the mpls.0 routing table, triggering a chained MPLS label lookup to discover the remaining MPLS labels in the stack.

  • Route S=1—Indicates that there are no more labels. The next hop points to the inet.0 routing table if the platform supports chained and multi-family lookup. Alternatively, the label route can point to a VT interface to initiate IP forwarding.

If you enable UHP LSPs, MPLS applications such as Layer 3 VPNs, VPLS, Layer 2 VPNs, and Layer 2 circuits can use the UHP LSPs. The following explains how UHP LSPs affect the different types of MPLS applications:

  • Layer 2 VPNs and Layer 2 circuits—A packet arrives at the PE router (egress of the UHP LSP) with two labels. The outer label (S=0) is the UHP label, and the inner label (S=1) is the VC label. A lookup based on the transport label results in a table handle for the mpls.0 routing table. There is an additional route in the mpls.0 routing table corresponding to the inner label. A lookup based on the inner label results in the CE router next hop.

  • Layer 3 VPN—A packet arrives at the PE router (egress of the UHP LSP) with two labels. The outer label (S=0) is the UHP label, and the inner label is the VPN label (S=1). A lookup based on the transport label results in the table handle for the mpls.0 routing table. There are two cases in this scenario. By default, Layer 3 VPNs advertise the per-next hop label. A lookup based on the inner label results in the next hop toward the CE router. However, if you have configured the vrf-table-label statement for the Layer 3 VPN routing instance, the inner LSI label points to the VRF routing table. An IP lookup is also completed for the VRF routing table.

    Note

    UHP for Layer 3 VPNs configured with the vrf-table-label statement is supported on MX Series 5G Universal Routing Platforms only.

  • VPLS—A packet arrives at the PE router (egress of the UHP LSP) with two labels. The outer label is the transport label (S=0) and the inner label is the VPLS label (S=1). A lookup based on the transport label results in the table handle for the mpls.0 routing table. A lookup based on the inner label in mpls.0 routing table results in the LSI tunnel interface of the VPLS routing instance if tunnel-services is not configured (or a VT interface not available). MX 3D Series routers support chained lookup and multi-family lookup.

    Note

    UHP for VPLS configured with the no-tunnel-service statement is supported on MX 3D Series routers only.

  • IPv4 over MPLS—A packet arrives at the PE router (egress of the UHP LSP) with one label (S=1). A lookup based on this label returns a VT tunnel interface. Another IP lookup is completed on the VT interface to determine where to forward the packet. If the routing platform supports multi-family and chained lookups (for example, MX 3D routers and PTX Series Packet Transport Routers), lookup based on label route (S=1) points to the inet.0 routing table.

  • IPv6 over MPLS—For IPv6 tunneling over MPLS, PE routers advertise IPv6 routes to each other with a label value of 2. This is the explicit null label for IPv6. As a result, the forwarding next hops for IPv6 routes that are learned from remote PE routers normally push two labels. The inner label is 2 (it could be different if the advertising PE router is from another vendor), and the router label is the LSP label. Packets arrive at the PE router (egress of the UHP LSP) with two labels. The outer label is the transport label (S=0), and the inner label is the IPv6 explicit-null label (label 2). Lookup based on the inner label in the mpls.0 routing table redirects back to the mpls.0 routing table. On MX 3D Series routers, the inner label (label 2) is stripped off and an IPv6 lookup is done using the inet6.0 routing table.

  • Enabling both PHP and UHP LSPs—You can configure both PHP and UHP LSPs over the same network paths. You can separate PHP and UHP traffic by selecting forwarding LSP next hops using a regular expression with the install-nexthop statement. You can also separate traffic by simply naming the LSPs appropriately.

The following statements enable ultimate-hop popping for an LSP. You can enable this feature on a specific LSP or for all of the ingress LSPs configured on the router. Configure these statements on the router at the LSP ingress.

  1. To enable ultimate-hop popping, include the ultimate-hop-popping statement:

    Include this statement at the [edit protocols mpls label-switched-path label-switched-path-name] hierarchy level to enable ultimate-hop popping on a specific LSP. Include this statement at the [edit protocols mpls] hierarchy level to enable ultimate-hop popping on all of the ingress LSPs configured on the router. You can also configure the ultimate-hop-popping statement under the equivalent [edit logical-routers] hierarchy levels.Note

    When you enable ultimate-hop popping, RSVP attempts to resignal existing LSPs as ultimate-hop popping LSPs in a make-before-break fashion. If an egress router does not support ultimate-hop popping, the existing LSP is torn down (RSVP sends a PathTear message along an LSP’s path, removing the path state and dependent reservation state and releasing the associated networking resources).

    If you disable ultimate-hop popping, RSVP resignals existing LSPs as penultimate-hop popping LSPs in a make-before-break fashion.

  2. If you want to enable both ultimate-hop-popping and chained next hops on MX 3D Series routers only, you also need to configure the enhanced-ip option for the network-services statement:

    You configure this statement at the [edit chassis] hierarchy level. Once you have configured the network-services statement, you need to reboot the router to enable UHP behavior.

Configuring Explicit-Path LSPs

If you disable constrained-path label-switched path (LSP) computation, as described in Disabling Constrained-Path LSP Computation, you can configure LSPs manually or allow the LSPs to follow the IGP path.

When explicit-path LSPs are configured, the LSP is established along the path you specified. If the path is topologically not feasible, either because the network is partitioned or insufficient resources are available along some parts of the path, the LSP will fail. No alternative paths can be used. If the setup succeeds, the LSP stays on the defined path indefinitely.

To configure an explicit-path LSP, follow these steps:

  1. Configure the path information in a named path, as described in Creating Named Paths. To configure complete path information, specify every router hop between the ingress and egress routers, preferably using the strict attribute. To configure incomplete path information, specify only a subset of router hops, using the loose attribute in places where the path is incomplete.

    For incomplete paths, the MPLS routers complete the path by querying the local routing table. This query is done on a hop-by-hop basis, and each router can figure out only enough information to reach the next explicit hop. It might be necessary to traverse a number of routers to reach the next (loose) explicit hop.

    Configuring incomplete path information creates portions of the path that depend on the current routing table, and this portion of the path can reroute itself as the topology changes. Therefore, an explicit-path LSP that contains incomplete path information is not completely fixed. These types of LSPs have only a limited ability to repair themselves, and they tend to create loops or flaps depending on the contents of the local routing table.

  2. To configure the LSP and point it to the named path, use either the primary or secondary statement, as described in Configuring Primary and Secondary LSPs.

  3. Disable constrained-path LSP computation by including the no-cspf statement either as part of the LSP or as part of a primary or secondary statement. For more information, see Disabling Constrained-Path LSP Computation.

  4. Configure any other LSP properties.

Using explicit-path LSPs has the following drawbacks:

  • More configuration effort is required.

  • Configured path information cannot take into account dynamic network bandwidth reservation, so the LSPs tend to fail when resources become depleted.

  • When an explicit-path LSP fails, you might need to manually repair it.

Because of these limitations, we recommend that you use explicit-path LSPs only in controlled situations, such as to enforce an optimized LSP placement strategy resulting from computations with an offline simulation software package.

Example: Configuring an Explicit-Path LSP

On the ingress router, create an explicit-path LSP, and specify the transit routers between the ingress and egress routers. In this configuration, no constrained-path computation is performed. For the primary path, all intermediate hops are strictly specified so that its route cannot change. The secondary path must travel through router 14.1.1.1 first, then take whatever route is available to reach the destination. The remaining route taken by the secondary path is typically the shortest path computed by the IGP.

LSP Bandwidth Oversubscription Overview

LSPs are established with bandwidth reservations configured for the maximum amount of traffic you expect to traverse the LSP. Not all LSPs carry the maximum amount of traffic over their links at all times. For example, even if the bandwidth for link A has been completely reserved, actual bandwidth might still be available but not currently in use. This excess bandwidth can be used by allowing other LSPs to also use link A, oversubscribing the link. You can oversubscribe the bandwidth configured for individual class types or specify a single value for all of the class types using an interface.

You can use oversubscription to take advantage of the statistical nature of traffic patterns and to permit higher utilization of links.

The following examples describe how you might use bandwidth oversubscription and undersubscription:

  • Use oversubscription on class types where peak periods of traffic do not coincide in time.

  • Use oversubscription of class types carrying best-effort traffic. You take the risk of temporarily delaying or dropping traffic in exchange for making better utilization of network resources.

  • Give different degrees of oversubscription or undersubscription of traffic for the different class types. For instance, you configure the subscription for classes of traffic as follows:

    • Best effort—ct0 1000

    • Voice—ct3 1

When you undersubscribe a class type for a multiclass LSP, the total demand of all RSVP sessions is always less than the actual capacity of the class type. You can use undersubscription to limit the utilization of a class type.

The bandwidth oversubscription calculation occurs on the local router only. Because no signaling or other interaction is required from other routers in the network, the feature can be enabled on individual routers without being enabled or available on other routers which might not support this feature. Neighboring routers do not need to know about the oversubscription calculation, they rely on the IGP.

The following sections describe the types of bandwidth oversubscription available in the Junos OS:

LSP Size Oversubscription

For LSP size oversubscription, you simply configure less bandwidth than the peak rate expected for the LSP. You also might need to adjust the configuration for automatic policers. Automatic policers manage the traffic assigned to an LSP, ensuring that it does not exceed the configured bandwidth values. LSP size oversubscription requires that the LSP can exceed its configured bandwidth allocation.

Policing is still possible. However, the policer must be manually configured to account for the maximum bandwidth planned for the LSP, rather than for the configured value.

You can increase the maximum reservable bandwidth on the link and use the inflated values for bandwidth accounting. Use the subscription statement to oversubscribe the link. The configured value is applied to all class type bandwidth allocations on the link. For more information about link size oversubscription, see Configuring the Bandwidth Subscription Percentage for LSPs.

Class Type Oversubscription and Local Oversubscription Multipliers

Local oversubscription multipliers (LOMs) allow different oversubscription values for different class types. LOMs are useful for networks where the oversubscription ratio needs to be configured differently on different links and where oversubscription values are required for different classes. You might use this feature to oversubscribe class types handling best-effort traffic, but use no oversubscription for class types handling voice traffic. An LOM is calculated locally on the router. No information related to an LOM is signaled to other routers in the network.

An LOM is configurable on each link and for each class type. The per-class type LOM allows you to increase or decrease the oversubscription ratio. The per-class-type LOM is factored into all local bandwidth accounting for admission control and IGP advertisement of unreserved bandwidths.

The LOM calculation is tied to the bandwidth model (MAM, extended MAM, and Russian dolls) used, because the effect of oversubscription across class types must be accounted for accurately.

Note

All LOM calculations are performed by the Junos OS and require no user intervention.

The formulas related to the oversubscription of class types are described in the following sections:

Configuring the Bandwidth Subscription Percentage for LSPs

By default, RSVP allows all of a class type’s bandwidth (100 percent) to be used for RSVP reservations. When you oversubscribe a class type for a multiclass LSP, the aggregate demand of all RSVP sessions is allowed to exceed the actual capacity of the class type.

If you want to oversubscribe or undersubscribe all of the class types on an interface using the same percentage bandwidth, configure the percentage using the subscription statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section.

To undersubscribe or oversubscribe the bandwidth for each class type, configure a percentage for each class type (ct0, ct1, ct2, and ct3) option for the subscription statement. When you oversubscribe a class type, an LOM is applied to calculate the actual bandwidth reserved. See Class Type Oversubscription and Local Oversubscription Multipliers for more information.

For a list of hierarchy levels at which you can include this statement, see the statement summary section.

percentage is the percentage of class type bandwidth that RSVP allows to be used for reservations. It can be a value from 0 through 65,000 percent. If you specify a value greater than 100, you are oversubscribing the interface or class type.

The value you configure when you oversubscribe a class type is a percentage of the class type bandwidth that can actually be used. The default subscription value is 100 percent.

You can use the subscription statement to disable new RSVP sessions for one or more class types. If you configure a percentage of 0, no new sessions (including those with zero bandwidth requirements) are permitted for the class type.

Existing RSVP sessions are not affected by changing the subscription factor. To clear an existing session, issue the clear rsvp session command. For more information on the clear rsvp session command, see the CLI Explorer.

Constraints on Configuring Bandwidth Subscription

Be aware of the following issues when configuring bandwidth subscription:

  • If you configure bandwidth constraints at the [edit class-of-service interface interface-name] hierarchy level, they override any bandwidth configuration you specify at the [edit protocols rsvp interface interface-name bandwidth] hierarchy level for Diffserv-TE. Also note that either of the CoS or RSVP bandwidth constraints can override the interface hardware bandwidth constraints.

  • If you configure a bandwidth subscription value for a specific interface that differs from the value configured for all interfaces (by including different values for the subscription statement at the [edit protocols rsvp interface interface-name] and [edit protocols rsvp interface all] hierarchy levels), the interface-specific value is used for that interface.

  • You can configure subscription for each class type only if you also configure a bandwidth model. If no bandwidth model is configured, the commit operation fails with the following error message:

    user@host# commit check
  • You cannot include the subscription statement both in the configuration for a specific class type and the configuration for the entire interface. The commit operation fails with the following error message:

    user@host# commit check

Related Documentation

Release History Table
Release
Description
Starting in Junos OS Release 14.1R9, 15.1R7, 16.1R5, 16.1X2, 16.2R3, and 17.2R2, all zero value bandwidth samples are considered as underflow samples, except for the zero value samples that arrive after an LSP comes up for the first time, and the zero value samples that arrive first after a Routing Engine switchover.