Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

RSVP Configuration

 

Minimum RSVP Configuration

To enable RSVP on a single interface, include the rsvp statement and specify the interface using the interface statement. This is the minimum RSVP configuration. All other RSVP configuration statements are optional.

You can include these statements at the following hierarchy levels:

  • [edit protocols]

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

To enable RSVP on all interfaces, substitute all for the interface-name variable.

If you have configured interface properties on a group of interfaces and want to disable RSVP on one of the interfaces, include the disable statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name ]

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

Configuring RSVP and MPLS

The primary purpose of the Junos RSVP software is to support dynamic signaling within label-switched paths (LSPs). When you enable both MPLS and RSVP on a router, MPLS becomes a client of RSVP. No additional configuration is required to bind MPLS and RSVP.

You can configure MPLS to set up signaled paths by using the label-switched-path statement at the [edit protocols mpls] hierarchy level. Each LSP translates into a request for RSVP to initiate an RSVP session. This request is passed through the internal interface between label switching and RSVP. After examining the request information, checking RSVP states, and checking the local routing tables, RSVP initiates one session for each LSP. The session is sourced from the local router and is destined for the target of the LSP.

When an RSVP session is successfully created, the LSP is set up along the paths created by the RSVP session. If the RSVP session is unsuccessful, RSVP notifies MPLS of its status. It is up to MPLS to initiate backup paths or continue retrying the initial path.

To pass label-switching signaling information, RSVP supports four additional objects: Label Request object, Label object, Explicit Route object, and Record Route object. For an LSP to be set up successfully, all routers along the path must support MPLS, RSVP, and the four objects. Of the four objects, the Record Route object is not mandatory.

To configure MPLS and make it a client of RSVP, do the following:

  • Enable MPLS on all routers that will participate in the label switching (this is, on all routers that might be part of a label-switching path).

  • Enable RSVP on all routers and on all router interfaces that form the LSP.

  • Configure the routers at the beginning of the LSP.

Example: Configuring RSVP and MPLS

The following shows a sample configuration for a router at the beginning of an LSP:

The following shows a sample configuration for all the other routers that form the LSP:

Configuring RSVP Interfaces

The following sections describe how to configure RSVP interfaces:

Configuring RSVP Refresh Reduction

You can configure RSVP refresh reduction on each interface by including the following statements in the interface configuration:

  • aggregate and reliable—Enable all RSVP refresh reduction features: RSVP message bundling, RSVP message ID, reliable message delivery, and summary refresh.

    In order to have refresh reduction and reliable delivery, you must include the aggregate and reliable statements.

  • no-aggregate—Disable RSVP message bundling and summary refresh.

  • no-reliable—Disable RSVP message ID, reliable message delivery, and summary refresh.

For more information on RSVP refresh reduction, see RSVP Refresh Reduction.

If the no-reliable statement is configured on the router (reliable message delivery is disabled), the router accepts RSVP messages that include the Message ID object but ignores the Message ID object and continues performing standard message processing. No error is generated in this case, and RSVP operates normally.

However, not all combinations between two neighbors with different refresh reduction capabilities function correctly. For example, a router is configured with either the aggregate statement and no-reliable statement or with the reliable and no-aggregate statements. If an RSVP neighbor sends a Summary Refresh object to this router, no error is generated, but the Summary Refresh object cannot be processed. Consequently, RSVP states can time out on this router if the neighbor is relying only on Summary Refresh to refresh those RSVP states.

We recommend, unless there are specific requirements, that you configure RSVP refresh reduction in a similar manner on each RSVP neighbor.

To enable all RSVP refresh reduction features on an interface, include the aggregate statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name]

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

To disable RSVP message bundling and summary refresh, include the no-aggregate statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name]

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

To enable RSVP message ID and reliable message delivery on an interface, include the reliable statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name]

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

To disable RSVP message ID, reliable message delivery, and summary refresh, include the no-reliable statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name]

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

Determining the Refresh Reduction Capability of RSVP Neighbors

To determine the RSVP refresh reduction capability of an RSVP neighbor, you need the following information:

  • The RR bit advertised by the neighbor

  • The local configuration of RSVP refresh reduction

  • The actual RSVP messages received from the neighbor

To obtain this information, you can issue a show rsvp neighbor detail command. Sample output follows:

user@host> show rsvp neighbor detail

For more information on the show rsvp neighbor detail command.

Configuring the RSVP Hello Interval

RSVP monitors the status of the interior gateway protocol (IGP) (IS-IS or OSPF) neighbors and relies on the IGP protocols to detect when a node fails. If an IGP protocol declares a neighbor down (because hello packets are no longer being received), RSVP also brings down that neighbor. However, the IGP protocols and RSVP still act independently when bringing a neighbor up.

For Juniper Networks routers, configuring a shorter or longer RSVP hello interval has no impact on whether or not an RSVP session is brought down. RSVP sessions are kept up even if RSVP hello packets are no longer being received. RSVP sessions are maintained until either the router stops receiving IGP hello packets or the RSVP Path and Resv messages time out. However, starting from Junos OS Release 16.1, when RSVP hello messages time-out, the RSVP sessions are brought down.

The RSVP hello interval might also be impacted when another vendor’s equipment brings down an RSVP session. For example, a neighboring non-Juniper Networks router might be configured to monitor RSVP hello packets.

To modify how often RSVP sends hello packets, include the hello-interval statement:

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

Configuring RSVP Authentication

All RSVP protocol exchanges can be authenticated to guarantee that only trusted neighbors participate in setting up reservations. By default, RSVP authentication is disabled.

RSVP authentication uses a Hashed Message Authentication Code (HMAC)-MD5 message-based digest. This scheme produces a message digest based on a secret authentication key and the message contents. (The message contents also include a sequence number.) The computed digest is transmitted with RSVP messages. Once you have configured authentication, all received and transmitted RSVP messages with all neighbors are authenticated on this interface.

MD5 authentication provides protection against forgery and message modification. It also can prevent replay attacks. However, it does not provide confidentiality, because all messages are sent in clear text.

By default, authentication is disabled. To enable authentication, configure a key on each interface by including the authentication-key statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols rsvp interface interface-name]

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

Configuring the Bandwidth Subscription for Class Types

By default, RSVP allows 100 percent of the bandwidth for a class type 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.

For detailed instructions on how to configure the bandwidth subscription for class types, see Configuring the Bandwidth Subscription Percentage for LSPs.

Configuring the RSVP Update Threshold on an Interface

The interior gateway protocols (IGPs) maintain the traffic engineering database, but the current available bandwidth on the traffic engineering database links originates from RSVP. When a link’s bandwidth changes, RSVP informs the IGPs, which can then update the traffic engineering database and forward the new bandwidth information to all network nodes. The network nodes then know how much bandwidth is available on the traffic engineering database link (local or remote), and CSPF can correctly compute the paths.

However, IGP updates can consume excessive system resources. Depending on the number of nodes in a network, it might not be desirable to perform an IGP update for small changes in bandwidth. By configuring the update-threshold statement at the [edit protocols rsvp] hierarchy level, you can adjust the threshold at which a change in the reserved bandwidth triggers an IGP update.

You can configure a value of from 0.001 percent through 20 percent (the default is 10 percent) for when to trigger an IGP update. If the change in the reserved bandwidth is greater than or equal to the configured threshold percentage of the static bandwidth on that interface, then an IGP update occurs. For example, if you have configured the update-threshold statement to be 15 percent and the router discovers that the reserved bandwidth on a link has changed by 10 percent of the link bandwidth, RSVP does not trigger an IGP update. However, if the reserved bandwidth on a link changes by 20 percent of the link bandwidth, RSVP triggers an IGP update.

You can also configure the threshold as an absolute value using the threshold-value option under the update-threshold statement.

If the threshold-value is configured to greater than 20% of bandwidth on that link, the threshold-value is capped at 20% of bandwidth.

For instance, if bandwidth on an interface is 1Gbps, and the threshold-value is configured greater than 200Mbps, the threshold-value is capped at 200Mbps. The threshold-percent is displayed as 20.000% and the threshold-value as 200Mbps.

Note

The two options, threshold-percent and threshold-value, are mutually exclusive. You can configure only one option at a given point in time to generate an IGP update for lower bandwidth reservations. As a result, when one option is configured, the other option is calculated and displayed on the CLI.

For instance, on a link of 1Gbps, if the threshold-percent is configured to 5%, the threshold-value is calculated and displayed as 50Mbps. Similarly, if the threshold-value is configured to 50m, then the threshold-percent is calculated and displayed as 5%.

To adjust the threshold at which a change in the reserved bandwidth triggers an IGP update, include the update-threshold statement. Because of the update threshold, it is possible for Constrained Shortest Path First (CSPF) to compute a path using outdated traffic engineering database bandwidth information on a link. If RSVP attempts to establish an LSP over that path, it might find that there is insufficient bandwidth on that link. When this happens, RSVP triggers an IGP traffic engineering database update, flooding the updated bandwidth information on the network. CSPF can then recompute the path by using the updated bandwidth information, and attempt to find a different path, avoiding the congested link. Note that this functionality is the default and does not need any additional configuration.

You can configure the rsvp-error-hold-time statement at the [edit protocols mpls] hierarchy level or the [edit logical-systems logical-system-name protocols mpls] hierarchy level to improve the accuracy of the traffic engineering database (including the accuracy of bandwidth estimates for LSPs) using information provided by PathErr messages. See Improving Traffic Engineering Database Accuracy with RSVP PathErr Messages.

Configuring RSVP for Unnumbered Interfaces

The Junos OS supports RSVP traffic engineering over unnumbered interfaces. Traffic engineering information about unnumbered links is carried in the IGP traffic engineering extensions for OSPF and IS-IS as described in RFC 4203, OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), and RFC 4205, Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS). Unnumbered links can also be specified in the MPLS traffic engineering signaling as described in RFC 3477, Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE). This feature allows you avoid having to configure IP addresses for each interface participating in the RSVP-signaled network.

To configure RSVP for unnumbered interfaces, you must configure the router with a router ID using the router-id statement specified at the [edit routing-options] hierarchy level. The router ID must be available for routing (you can typically use the loopback address). The RSVP control messages for the unnumbered links are sent using the router ID address (rather than a randomly selected address).

To configure link protection and fast reroute on a router with unnumbered interfaces enabled, you must configure at least two addresses. We recommend that you configure a secondary interface on the loopback in addition to configuring the router ID.

Configuring RSVP Node-ID Hellos

You can configure node-ID based RSVP hellos to ensure that Juniper Networks routers can interoperate with the equipment of other vendors. By default, Junos OS uses interface-based RSVP hellos. Node-ID based RSVP hellos are specified in RFC 4558, Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement. RSVP node-ID hellos are useful if you have configured BFD to detect problems over RSVP interfaces, allowing you to disable interface hellos for these interfaces. You can also use node-ID hellos for graceful restart procedures.

Node-ID hellos can be enabled globally for all RSVP neighbors. By default, node-ID hello support is disabled. If you have not enabled RSVP node IDs on the router, the Junos OS does not accept any node-ID hello packets.

To enable RSVP node-ID hellos globally on the router, include the node-hello statement at the following hierarchy levels:

  • [edit protocols rsvp]

  • [edit logical-systems logical-systems-name protocols rsvp]

You can also explicitly disable RSVP interface hellos globally. This type of configuration might be necessary in networks where the Juniper Networks router has numerous RSVP connections with equipment from other vendors. However, if you disable RSVP interface hellos globally, you can also configure a hello interval on an RSVP interface using the hello-interval statement. This configuration disables RSVP interface hellos globally, but enables RSVP interface hellos on the specified interface (the RSVP interface you configure the hello-interval statement on). This configuration might be necessary in a heterogeneous network in which some devices support RSVP node-ID hellos and other devices support RSVP interface hellos.

To disable RSVP interface hellos globally on the router, include the no-interface-hello statement at the following hierarchy levels:

  • [edit protocols rsvp]

  • [edit logical-systems logical-systems-name protocols rsvp]

Example: Configuring RSVP-Signaled LSPs

This example shows how to create an LSP between routers in an IP network using RSVP as the signaling protocol.

Requirements

Before you begin, delete security services from the device. See Example: Deleting Security Services.

Overview and Topology

Using RSVP as a signaling protocol, you can create LSPs between routers in an IP network. In this example, you configure a sample network as shown in Figure 1.

Figure 1: Typical RSVP-Signaled LSP
Typical RSVP-Signaled LSP

To establish an LSP between routers, you must individually enable the MPLS family and configure RSVP on each of the transit interfaces in the MPLS network. This example shows how to enable MPLS and configure RSVP on the ge-0/0/0 transit interface. Additionally, you must enable the MPLS process on all of the MPLS interfaces in the network.

This example shows how to define an LSP from R1 to R7 on the ingress router (R1) using R7’s loopback address (10.0.9.7). The configuration reserves 10 Mbps of bandwidth. Additionally, the configuration disables the CSPF algorithm, ensuring that Hosts C1 and C2 use the RSVP-signaled LSP that correspond to the network IGP's shortest path.

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, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

The following example requires you to 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 RSVP:

  1. Enable the MPLS family on all transit interfaces in the MPLS network.
  2. Enable RSVP on each transit interface in the MPLS network.
  3. Enable the MPLS process on the transit interface in the MPLS network.
  4. Define the LSP on the ingress router.
  5. Reserve 10 Mbps of bandwidth on the LSP.

Results

Confirm your configuration by entering the show command from configuration mode. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

For brevity, this show command output includes only the configuration that is relevant to this example. Any other configuration on the system has been replaced with ellipses (...).

If you are done configuring the device, enter commit from configuration mode.

Verification

To confirm that the configuration is working properly, perform these tasks:

Verifying RSVP Neighbors

Purpose

Verify that each device shows the appropriate RSVP neighbors—for example, that Router R1 in Figure 1 lists both Router R3 and Router R2 as RSVP neighbors.

Action

From the CLI, enter the show rsvp neighbor command.

user@r1> show rsvp neighbor

The output shows the IP addresses of the neighboring routers. Verify that each neighboring RSVP router loopback address is listed.

Verifying RSVP Sessions

Purpose

Verify that an RSVP session has been established between all RSVP neighbors. Also, verify that the bandwidth reservation value is active.

Action

From the CLI, enter the show rsvp session detail command.

user@r1> show rsvp session detail

The output shows the detailed information, including session IDs, bandwidth reservation, and next-hop addresses, for each established RSVP session. Verify the following information:

  • Each RSVP neighbor address has an entry for each neighbor, listed by loopback address.

  • The state for each LSP session is Up.

  • For Tspec, the appropriate bandwidth value, 10Mbps, appears.

Verifying the Presence of RSVP-Signaled LSPs

Purpose

Verify that the routing table of the entry (ingress) router has a configured LSP to the loopback address of the other router. For example, verify that the inet.3 routing table of the R1 entry router in Figure 1 has a configured LSP to the loopback address of Router R7.

Action

From the CLI, enter the show route table inet.3 command.

user@r1> show route table inet.3

The output shows the RSVP routes that exist in the inet.3 routing table. Verify that an RSVP-signaled LSP is associated with the loopback address of the exit (egress) router, R7, in the MPLS network.

Example: Configuring RSVP Automatic Mesh

Service providers often use BGP and MPLS VPNs to efficiently scale the network while delivering revenue-generating services. In these environments, BGP is used to distribute the VPN routing information across the service provider's network, while MPLS is used to forward that VPN traffic from one VPN site to another.

When adding a new PE router that will participate in BGP and MPLS VPNs, all of the previously existing PE routers must be configured to peer with the new PE router for both BGP and MPLS. As each new PE router is added to the service provider's network, the configuration burden soon becomes too much to handle.

The configuration requirements for BGP peering can be reduced with the use of route reflectors. In RSVP signaled MPLS networks, RSVP automatic mesh can minimize the configuration burden for the MPLS portion of the network. Configuring rsvp-te on all PE routers allows RSVP to automatically create the needed LSPs when a new PE router is added.

Requirements

This example uses the following hardware and software components:

  • A router running Junos OS Release 10.1 or later.

  • A BGP and MPLS VPN using RSVP as the MPLS label-switched path (LSP) signaling protocol.

Overview

This example shows how to configure RSVP automatic mesh on a PE router using the rsvp-te configuration statement. In order for RSVP automatic mesh to function properly, all of the PE routers in the full mesh configuration must have the rsvp-te statement configured. This ensures that any new PE routers that are added later will also benefit from the automatic mesh feature, provided that they too are configured with the rsvp-te statement.

Given this requirement, this example only shows the configuration on the newly added PE router. It is assumed that RSVP automatic mesh has already been configured on the existing PE routers.

Topology

In Figure 2, there are three existing PE routers, PE1, PE2, and PE3, in the topology. PE4 has been added, and RSVP automatic mesh will be configured. The cloud represents the service provider network, and the network address, 192.0.2.0/24, is shown in the center of the figure.

Figure 2: Service Provider Network with PE Routers
Service Provider Network
with PE Routers

Configuration

Configuring RSVP automatic mesh involves performing these tasks:

  • Enabling the rsvp-te configuration statement at the [edit routing-options dynamic-tunnels dynamic-tunnel-name] hierarchy level.

  • Configuring the required destination-networks element.

    This configuration element specifies the IPv4 prefix range for the destination network. Only tunnels within the specified prefix range can be created.

  • Configuring the required label-switched-path-template element.

    This configuration element takes either default-template or the name of a preconfigured LSP template as an argument. The default-template is a system-defined template that requires no user 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, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

PE4 Router

Configuring RSVP Automatic Mesh

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To enable RSVP automatic mesh:

  1. Configure rsvp-te at the [edit routing-options dynamic-tunnels] hierarchy level.
  2. Configure destination-networks at the [edit routing-options dynamic-tunnels] hierarchy level.

Results

Issue the show command from the [edit routing-options dynamic-tunnels] hierarchy level to see the results of your configuration:

Verification

Verifying the Existence of RSVP Automatic Mesh Tunnels on Router PE4

Purpose

To verify the operation of the newly configured PE4 router, issue the show dynamic-tunnels database command from operational mode. This command will show the destination network to which dynamic tunnels can be created.

Action

Verifying the Existence of MPLS LSPs on Router PE4

Purpose

To verify the existence of MPLS LSPs on the PE4 router, issue the show mpls lsp command from operational mode. This command will show the state of the MPLS LSPs.

Action

Configuring Hello Acknowledgments for Nonsession RSVP Neighbors

The hello-acknowledgements statement controls the hello acknowledgment behavior between RSVP neighbors regardless of whether or not they are in the same session.

Hello messages received from RSVP neighbors that are not part of a common RSVP session are discarded. If you configure the hello-acknowledgements statement at the [edit protocols rsvp] hierarchy level, hello messages from nonsession neighbors are acknowledged with a hello acknowledgment message. When hellos are received from nonsession neighbors, an RSVP neighbor relationship is created and periodic hello messages can now be received from the nonsession neighbor. The hello-acknowledgements statement is disabled by default. Configuring this statement allows RSVP-capable routers to be discovered using hello packets and verifies that the interface is able to receive RSVP packets before sending any MPLS LSP setup messages.

Once you enable hello acknowledgments for nonsession RSVP neighbors, the router continues to acknowledge hello messages from any nonsession RSVP neighbors unless the interface itself goes down or you change the configuration. Interface-based neighbors are not automatically aged out.

You can include this statement at the following hierarchy levels:

  • [edit protocols rsvp]

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

Switching LSPs Away from a Network Node

You can configure the router to switch active LSPs away from a network node using a bypass LSP enabled for an interface. This feature might be used to maintain active networks when a device needs to be replaced without interrupting traffic transiting the network. The LSPs can be either static or dynamic.

  1. You first need to configure either link or node protection for the traffic that needs to pass around the network device you intend to disable. To function properly, the bypass LSP must use a different logical interface than the protected LSP.
  2. To prepare the router to begin switching traffic away from a network node, configure the always-mark-connection-protection-tlv statement:

    The router then marks all OAM traffic transiting this interface in preparation for switching the traffic to an alternate path based on the OAM functionality.

    You can configure this statement at the following hierarchy levels:

    • [edit protocols mpls interface interface-name]

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

  3. You then need to configure the switch-away-lsps statement to switch the traffic from the protected LSP to the bypass LSP, effectively bypassing the default downstream network device. The actual link itself is not brought down by this configuration.

    To configure the router to switch traffic away from a network node, configure the switch-away-lsps statement:

    You can configure this statement at the following hierarchy levels:

    • [edit protocols mpls interface interface-name]

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

Note the following limitations related to switching active LSPs away from a network node:

  • The switch-away feature is supported on MX Series routers only.

  • The switch-away feature is not supported for switching traffic from primary point-to-multipoint LSPs to bypass point-to-multipoint LSPs. If you configure the switch-away-lsps statement for a point-to-multipoint LSP, traffic is not switched to the bypass point-to-multipoint LSP.

  • If you configure the switch-away feature on an interface along the path of a dynamic LSP, new dynamic LSPs cannot be established over that path. The switch-away feature prevents the make-before-break behavior of RSVP-signaled LSPs. The make-before-break behavior normally causes the router to first attempt to re-signal a dynamic LSP before tearing down the original.

Configuring RSVP Setup Protection

You can configure the facility-backup fast reroute mechanism to provide setup protection for LSPs which are in the process of being signaled. Both point-to-point LSPs and point-to-multipoint LSPs are supported. This feature is applicable in the following scenario:

  1. A failed link or node is present on the strict explicit path of an LSP before the LSP is signaled.

  2. There is also a bypass LSP protecting the link or node.

  3. RSVP signals the LSP through the bypass LSP. The LSP appears as if it was originally set up along its primary path and then failed over to the bypass LSP because of the link or node failure.

  4. When the link or node has recovered, the LSP can be automatically reverted to the primary path.

You should configure the setup-protection statement at the [edit protocols rsvp] on each of the routers along the LSP path on which you want to enable LSP setup protection. You should also configure IGP traffic engineering on all of the routers on the LSP path. You can issue a show rsvp session command to determine whether or not the LSP has setup protection enabled on a router acting as a point of local repair (PLR) or a merge point.

To enable RSVP setup protection, include the setup-protection statement

You can include this statement at the following hierarchy levels:

  • [edit protocols rsvp]

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

Configuring Load Balancing Across RSVP LSPs

By default, when you have configured several RSVP LSPs to the same egress router, the LSP with the lowest metric is selected and carries all traffic. If all of the LSPs have the same metric, one of the LSPs is selected at random and all traffic is forwarded over it.

Alternatively, you can load-balance traffic across all of the LSPs by enabling per-packet load balancing.

To enable per-packet load balancing on an ingress LSP, configure the policy-statement statement as follows:

You then need to apply this statement as an export policy to the forwarding table.

Once per-packet load balancing is applied, traffic is distributed equally between the LSPs (by default).

You need to configure per-packet load balancing if you want to enable PFE fast reroute. To enable PFE fast reroute, include the policy-statement statement for per-packet load balancing shown in this section in the configuration of each of the routers where a reroute might take place. See also Configuring Fast Reroute.

You can also load-balance the traffic between the LSPs in proportion to the amount of bandwidth configured for each LSP. This capability can better distribute traffic in networks with asymmetric bandwidth capabilities across external links, since the configured bandwidth of an LSP typically reflects the traffic capacity of that LSP.

To configure RSVP LSP load balancing, include the load-balance statement with the bandwidth option:

You can configure this statement at the following hierarchy levels:

  • [edit protocols rsvp]

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

Keep the following information in mind when you use the load-balance statement:

  • If you configure the load-balance statement, the behavior of currently running LSPs is not altered. To force currently running LSPs to use the new behavior, you can issue a clear mpls lsp command.

  • The load-balance statement only applies to ingress LSPs that have per-packet load balancing enabled.

  • For Differentiated Services–aware traffic engineered LSPs, the bandwidth of an LSP is calculated by summing the bandwidth of all of the class types.

Configuring RSVP Automatic Mesh

You can configure RSVP to establish point-to-point label-switched paths (LSPs) automatically for any new PE router added to a full mesh of LSPs. To enable this feature, you must configure the rsvp-te statement on all of the PE routers in the full mesh.

Note

You cannot configure RSVP automatic mesh in conjunction with CCC. CCC cannot use the dynamically generated LSPs.

To configure RSVP automatic mesh, include the rsvp-te statement:

You can configure these statements at the following hierarchy levels:

  • [edit routing-options dynamic-tunnels tunnel-name]

  • [edit logical-systems logical-system-name routing-options dynamic-tunnels tunnel-name]

You must also configure the following statements to enable RSVP automatic mesh:

  • destination-networks—Specify the IP version 4 (IPv4) prefix range for the destination network. Dynamic tunnels within the specified IPv4 prefix range can be initiated.

  • label-switched-path-template (Multicast)—You can configure either the default template explicitly using the default-template option, or you can configure an LSP template of your own using the template-name option. The LSP template acts as a model configuration for the dynamically generated LSPs.

Configuring Timers for RSVP Refresh Messages

RSVP uses two related timing parameters:

  • refresh-time—The refresh time controls the interval between the generation of successive refresh messages. The default value for the refresh time is 45 seconds. This number is derived from the refresh-time statement’s default value of 30, multiplied by a fixed value of 1.5. This computation differs from RFC 2205, which states that the refresh time should be multiplied by a random value in the range from 0.5 through 1.5.

    Refresh messages include path and Resv messages. Refresh messages are sent periodically so that reservation states in neighboring nodes do not time out. Each path and Resv message carries the refresh timer value, and the receiving node extracts this value from the messages.

  • keep-multiplier—The keep multiplier is a small, locally configured integer from 1 through 255. The default value is 3. It indicates the number of messages that can be lost before a particular state is declared stale and must be deleted. The keep multiplier directly affects the lifetime of an RSVP state.

To determine the lifetime of a reservation state, use the following formula:

In the worst case, (keep-multiplier – 1) successive refresh messages must be lost before a reservation state is deleted.

We do not recommend configuring a short RSVP hello timer. If quick discovery of a failed neighbor is needed, configure short IGP (OSPF or IS-IS) hello timers.

By default, the refresh timer value is 30 seconds. To modify this value, include the refresh-time statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols rsvp]

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

The default value of the keep multiplier is 3. To modify this value, include the keep-multiplier statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols rsvp]

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

Preempting RSVP Sessions

Whenever bandwidth is insufficient to handle all RSVP sessions, you can control the preemption of RSVP sessions. By default, an RSVP session is preempted only by a new higher-priority session.

To always preempt a session when the bandwidth is insufficient, include the preemption statement with the aggressive option:

You can include this statement at the following hierarchy levels:

  • [edit protocols rsvp]

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

To disable RSVP session preemption, include the preemption statement with the disabled option:

To return to the default (that is, preempt a session only for a new higher-priority session), include the preemption statement with the normal option:

You can include this statement at the following hierarchy levels:

  • [edit protocols rsvp]

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

Configuring MTU Signaling in RSVP

To configure maximum transmission unit (MTU) signaling in RSVP, you need to configure MPLS to allow IP packets to be fragmented before they are encapsulated in MPLS. You also need to configure MTU signaling in RSVP. For troubleshooting purposes, you can configure MTU signaling alone without enabling packet fragmentation.

To configure MTU signaling in RSVP, include the path-mtu statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols mpls]

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

The following sections describe how to enable packet fragmentation and MTU signaling in RSVP:

Enabling MTU Signaling in RSVP

To enable MTU signaling in RSVP, include the rsvp mtu-signaling statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols mpls path-mtu]

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

Once you have committed the configuration, changes in the MTU signaling behavior for RSVP take effect the next time the path is refreshed.

You can configure the mtu-signaling statement by itself at the [edit protocols mpls path-mtu rsvp] hierarchy level. This can be useful for troubleshooting. If you configure just the mtu-signaling statement, you can use the show rsvp session detail command to determine what the smallest MTU is on an LSP. The show rsvp session detail command displays the MTU value received and sent in the Adspec object.

Enabling Packet Fragmentation

To allow IP packets to be fragmented before they are encapsulated in MPLS, include the allow-fragmentation statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols mpls path-mtu]

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

    Note

    Do not configure the allow-fragmentation statement alone. Always configure it in conjunction with the mtu-signaling statement.

Configuring Ultimate-Hop Popping for LSPs

By default, RSVP-signaled LSPs use penultimate-hop popping (PHP). Figure 3 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 3: Penultimate-Hop Popping for an LSP
Penultimate-Hop Popping for an LSP

You can also configure ultimate-hop popping (UHP) (as shown in Figure 4) 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 4) 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 4: 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 RSVP to Pop the Label on the Ultimate-Hop Router

You can control the label value advertised on the egress router of an LSP. The default advertised label is label 3 (Implicit Null label). If label 3 is advertised, the penultimate-hop router removes the label and sends the packet to the egress router. When ultimate-hop popping is enabled, label 0 (IP version 4 [IPv4] Explicit Null label) is advertised. Ultimate-hop popping ensures that any packets traversing an MPLS network include a label.

Note

Juniper Networks routers queue packets based on the incoming label. Routers from other vendors might queue packets differently. Keep this in mind when working with networks containing routers from multiple vendors.

To configure ultimate-hop popping for RSVP, include the explicit-null statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols mpls]

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

Enabling Ultimate-Hop Popping on Point-to-Multipoint LSPs

By default, for both point-to-point and point-to-multipoint LSPs, penultimate-hop popping is used for MPLS traffic. MPLS labels are removed from packets on the router just before the egress router of the LSP. The plain IP packets are then forwarded to the egress router. For ultimate-hop popping, the egress router is responsible for both removing the MPLS label and processing the plain IP packet.

It can be beneficial to enable ultimate-hop popping on point-to-multipoint LSPs, particularly when transit traffic is traversing the same egress device. If you enable ultimate-hop popping, a single copy of traffic can be sent over the incoming link, saving significant bandwidth. By default, ultimate-hop popping is disabled.

You enable ultimate-hop popping for point-to-multipoint LSPs by configuring the tunnel-services statement. When you enable ultimate-hop popping, the Junos OS selects one of the available virtual loopback tunnel (VT) interfaces to loop back the packets to the PFE for IP forwarding. By default, the VT interface selection process is performed automatically. Bandwidth admission control is used to limit the number of LSPs that can be used on one VT interface. Once all the bandwidth is consumed on one interface, the Junos OS selects another VT interface with sufficient bandwidth for admission control.

If an LSP requires more bandwidth than is available from any of the VT interfaces, ultimate-hop popping cannot be enabled and penultimate-hop popping is enabled instead.

For ultimate-hop popping on point-to-multipoint LSPs to function properly, the egress router must have a PIC that provides tunnel services, such as the tunnel services PIC or the adaptive services PIC. Tunnel services are needed for popping the final MPLS label and for returning packets for IP address lookups.

You can explicitly configure which VT interfaces handle the RSVP traffic by including the devices option for the tunnel-services statement. The devices option allows you to specify which VT interfaces are to be used by RSVP. If you do not configure this option, all of the VT interfaces available to the router can be used.

To enable ultimate-hop popping for the egress point-to-multipoint LSPs on a router, configure the tunnel-services statement:

You can configure this statement at the following hierarchy levels:

  • [edit protocols rsvp]

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

To enable ultimate-hop popping for egress point-to-multipoint LSPs, you must also configure the interface statement with the all option:

You must configure this statement at the [edit protocols rsvp] hierarchy level.

Tracing RSVP Protocol Traffic

To trace RSVP protocol traffic, include the traceoptions statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols rsvp]

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

You can specify the following RSVP-specific flags in the RSVP traceoptions statement:

Use the file statement to specify the name of the file that receives the output of the tracing operation. All files are placed in the directory /var/log. We recommend that you place RSVP tracing output in the file rsvp-log.

  • all—All tracing operations.

  • error—All detected error conditions

  • event—RSVP-related events (helps to trace events related to RSVP graceful restart)

  • lmp—RSVP-Link Management Protocol (LMP) interactions

  • packets—All RSVP packets

  • path—All path messages

  • pathtear—PathTear messages

  • resv—Resv messages

  • resvtear—ResvTear messages

  • route—Routing information

  • state—Session state transitions, including when RSVP-signaled LSPs come up and go down.

Note

Use the all trace flag and the detail flag modifier with caution because these might cause the CPU to become very busy.

To view the log file generated when you enable RSVP traceoptions, issue the show log file-name command, where file-name is the file you specified using the traceoptions statement.

For general information about tracing and global tracing options, see the Junos OS Routing Protocols Library.

Examples: Tracing RSVP Protocol Traffic

Trace RSVP path messages in detail:

Trace all RSVP messages:

Trace all RSVP error conditions:

Trace RSVP state transitions:

RSVP Log File Output

The following is sample output generated by issuing the show log file-name command on a router on which RSVP traceoptions have been enabled with the state flag configured. The RSVP-signaled LSP E-D is shown being torn down on Mar 11 14:04:36.707092. On Mar 11 14:05:30.101492, it is shown coming back up.

RSVP Graceful Restart

RSVP graceful restart allows a router undergoing a restart to inform its adjacent neighbors of its condition. The restarting router requests a grace period from the neighbor or peer, which can then cooperate with the restarting router. The restarting router can still forward MPLS traffic during the restart period; convergence in the network is not disrupted. The restart is not visible to the rest of the network, and the restarting router is not removed from the network topology. RSVP graceful restart can be enabled on both transit routers and ingress routers. It is available for both point-to-point LSPs and point-to-multipoint LSPs.

RSVP graceful restart is described in the following sections:

RSVP Graceful Restart Terminology

R  

R

Recovery time (in milliseconds)

Applies only when the control channel is up (the hello exchange is complete) before the restart time. Applies only to nodal faults.

When a graceful restart is in progress, the time left to complete a recovery is advertised. At other times, this value is zero. The maximum advertised recovery time is 2 minutes (120,000 milliseconds).

During the recovery time, a restarting node attempts to recover its lost states with assistance from its neighbors. The neighbor of the restarting node must send the path messages with the recovery labels to the restarting node within a period of one-half the recovery time. The restarting node considers its graceful restart complete after its advertised recovery time.

Restart time (in milliseconds)

The default value is 60,000 milliseconds (1 minute). The restart time is advertised in the hello message. The time indicates how long a neighbor should wait to receive a hello message from a restarting router before declaring that router dead and purging states.

The Junos OS can override a neighbor’s advertised restart time if the time is greater than one-third the local restart time. For example, given the default restart time of 60 seconds, a router would wait 20 seconds or less to receive a hello message from a restarting neighbor. If the restart time is zero, the restarting neighbor can immediately be declared dead.

RSVP Graceful Restart Operation

For RSVP graceful restart to function, the feature must be enabled on the global routing instance. RSVP graceful restart can be disabled at the protocol level (for RSVP alone) or at the global level for all protocols.

RSVP graceful restart requires the following of a restarting router and the router’s neighbors:

  • For the restarting router, RSVP graceful restart attempts to maintain the routes installed by RSVP and the allocated labels, so that traffic continues to be forwarded without disruption. RSVP graceful restart is done quickly enough to reduce or eliminate the impact on neighboring nodes.

  • The neighboring routers must have RSVP graceful restart helper mode enabled, thus allowing them to assist a router attempting to restart RSVP.

An object called Restart Cap that is sent in RSVP hello messages advertises a node’s restart capability. The neighboring node sends a Recover Label object to the restarting node to recover its forwarding state. This object is essentially the old label that the restarting node advertised before the node went down.

The following lists the RSVP graceful restart behaviors, which vary depending on the configuration and on which features are enabled:

  • If you disable helper mode, the Junos OS does not attempt to help a neighbor restart RSVP. Any information that arrives with a Restart Cap object from a neighbor is ignored.

  • When you enable graceful restart under the routing instance configuration, the router can restart gracefully with the help of its neighbors. RSVP advertises a Restart Cap object (RSVP RESTART) in hello messages in which restart and recovery times are specified (neither value is 0).

  • If you explicitly disable RSVP graceful restart under the [protocols rsvp] hierarchy level, the Restart Cap object is advertised with restart and recovery times specified as 0. The restart of neighboring routers is supported (unless helper mode is disabled), but the router itself does not preserve the RSVP forwarding state and cannot recover its control state.

  • If after a restart RSVP realizes that no forwarding state has been preserved, the Restart Cap object is advertised with restart and recovery times specified as 0.

  • If graceful restart and helper mode are disabled, RSVP graceful restart is completely disabled. The router neither recognizes nor advertises the RSVP graceful restart objects.

You cannot explicitly configure values for the restart and recovery times.

Unlike other protocols, there is no way for RSVP to determine that it has completed a restart procedure, other than a fixed timeout. All RSVP graceful restart procedures are timer-based. A show rsvp version command might indicate that the restart is still in progress even if all RSVP sessions are back up and the routes are restored.

Processing the Restart Cap Object

The following assumptions are made about a neighbor based on the Restart Cap object (assuming that a control channel failure can be distinguished unambiguously from a node restart):

  • A neighbor that does not advertise the Restart Cap object in its hello messages cannot assist a router with state or label recovery, nor can it perform an RSVP graceful restart.

  • After a restart, a neighbor advertising a Restart Cap object with a restart time equal to any value and a recovery time equal to 0 has not preserved its forwarding state. When a recovery time equals 0, the neighbor is considered dead and any states related to this neighbor are purged, regardless of the value of the restart time.

  • After a restart, a neighbor advertising its recovery time with a value other than 0 can keep or has kept the forwarding state. If the local router is helping its neighbor with restart or recovery procedures, it sends a Recover Label object to this neighbor.

Configuring RSVP Graceful Restart

The following RSVP graceful restart configurations are possible:

  • Graceful restart and helper mode are both enabled (the default).

  • Graceful restart is enabled but helper mode is disabled. A router configured in this way can restart gracefully, but cannot help a neighbor with its restart and recovery procedures.

  • Graceful restart is disabled but helper mode is enabled. A router configured in this way cannot restart gracefully, but can help a restarting neighbor.

  • Graceful restart and helper mode both are disabled. This configuration completely disables RSVP graceful restart (including restart and recovery procedures and helper mode). The router behaves like a router that does not support RSVP graceful restart.

Note

In order to turn on RSVP graceful restart, you must set the global graceful restart timer to at least 180 seconds.

The following sections describe how to configure RSVP graceful restart:

Enabling Graceful Restart for All Routing Protocols

To enable graceful restart for RSVP, you need to enable graceful restart for all the protocols that support graceful restart on the router. For more information about graceful restart, see the Junos OS Routing Protocols Library.

To enable graceful restart on the router, include the graceful-restart statement:

You can include this statement at the following hierarchy levels:

  • [edit routing-options]

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

Disabling Graceful Restart for RSVP

By default, RSVP graceful restart and RSVP helper mode are enabled when you enable graceful restart. However, you can disable one or both of these capabilities.

To disable RSVP graceful restart and recovery, include the disable statement at the [edit protocols rsvp graceful-restart] hierarchy level:

Disabling RSVP Helper Mode

To disable RSVP helper mode, include the helper-disable statement at the [edit protocols rsvp graceful-restart] hierarchy level:

Configuring the Maximum Helper Recovery Time

To configure the amount of time the router retains the state of its RSVP neighbors while they undergo a graceful restart, include the maximum-helper-recovery-time statement at the [edit protocols rsvp graceful-restart] hierarchy level. This value is applied to all neighboring routers, so it should be based on the time required by the slowest RSVP neighbor to recover.

Configuring the Maximum Helper Restart Time

To configure the delay between when the router discovers that a neighboring router has gone down and when it declares the neighbor down, include the maximum-helper-restart-time statement at the [edit protocols rsvp graceful-restart] hierarchy level. This value is applied to all neighboring routers, so it should be based on the time required by the slowest RSVP neighbor to restart.

RSVP LSP Tunnels Overview

A Resource Reservation Protocol (RSVP) label-switched path (LSP) tunnel enables you to send RSVP LSPs inside other RSVP LSPs. This enables a network administrator to provide traffic engineering from one end of the network to the other. A useful application for this feature is to connect customer edge (CE) routers with provider edge (PE) routers by using an RSVP LSP, and then tunnel this edge LSP inside a second RSVP LSP traveling across the network core.

You should have a general understanding of MPLS and label switching concepts. For more information about MPLS, see the Junos MPLS Applications Configuration Guide.

An RSVP LSP tunnel adds the concept of a forwarding adjacency, similar to the one used for generalized Multiprotocol Label Switching (GMPLS). (For more information about GMPLS, see Junos GMPLS User Guide.

The forwarding adjacency creates a tunneled path for sending data between peer devices in an RSVP LSP network. Once a forwarding adjacency LSP (FA-LSP) has been established, other LSPs can be sent over the FA-LSP by using Constrained Shortest Path First (CSPF), Link Management Protocol (LMP), Open Shortest Path First (OSPF), and RSVP.

To enable an RSVP LSP tunnel, the Junos OS uses the following mechanisms:

  • LMP—Originally designed for GMPLS, LMP establishes forwarding adjacencies between RSVP LSP tunnel peers, and maintains and allocates resources for traffic engineering links.

  • OSPF extensions—OSPF was designed to route packets to physical and logical interfaces related to a Physical Interface Card (PIC). This protocol has been extended to route packets to virtual peer interfaces defined in an LMP configuration.

  • RSVP-TE extensions—RSVP-TE was designed to signal the setup of packet LSPs to physical interfaces. The protocol has been extended to request path setup for packet LSPs traveling to virtual peer interfaces defined in an LMP configuration.

    Note

    Beginning with Junos OS Release 15.1, multi-instance support is extended to MPLS RSVP-TE. This support is available only for virtual router instance type. A router can create and participate in multiple independent TE topology partitions, which allows each partitioned TE domain to scale independently. Multi-instance RSVP-TE provides the flexibility to hand pick the control-plane entities that need to be instance-aware, for example, a router can participate in multiple TE instances while still running a single BGP instance.

    The Junos OS implementation of MPLS RSVP-TE is scaled to enhance the usability, visibility, configuration, and troubleshooting of LSPs in Junos OS Release 16.1.

    These enhancements make the RSVP-TE configuration easier at scale by:

    • Ensuring the LSP data-plane readiness during LSP resignaling before traffic traverses the LSP with the RSVP-TE LSP self-ping mechanism.

      An LSP should not start to carry traffic unless it is known to have been programmed in the data plane. Data exchange in the LSP data plane, such as LSP ping requests, happens at the ingress router before switching traffic to an LSP, or to its MBB instance. In large networks, this traffic can overwhelm an LSP egress router, as the egress LSP needs to respond to the LSP ping requests. The LSP self-ping mechanism enables the ingress LER to create LSP ping response messages and send them over the LSP data plane. On receiving these messages, the egress LER forwards them to the ingress, indicating the liveliness of the LSP data plane. This ensures that the LSP does not start to carry traffic before the data plane has been programmed.

    • Removing the current hard limit of 64K LSPs on an ingress router and scaling the total number of LSPs with RSVP-TE signaled LSPs. There can be up to 64K LSPs configured on a per-egress basis. Earlier, this limit was the aggregate number of LSPs that could be configured on the ingress LER.

    • Preventing abrupt tearing down of LSPs by the ingress router because of delay in signaling the LSP at the transit routers.

    • Enabling a flexible view of LSP data-sets to facilitate LSP characteristic data visualization.

    Note

    Starting with Junos OS Release 17.4, a default timer of 1800 seconds for self-ping is introduced.

The following limitations exist for LSP hierarchies:

  • Circuit cross-connect (CCC)-based LSPs are not supported.

  • Graceful restart is not supported.

  • Link protection is not available for FA-LSPs or at the egress point of the forwarding adjacency.

  • Point-to-multipoint LSPs are not supported across FA-LSPs.

Example: RSVP LSP Tunnel Configuration

Figure 5: RSVP LSP Tunnel Topology Diagram
RSVP LSP Tunnel Topology Diagram

Figure 5 shows an end-to-end RSVP LSP called e2e_lsp_r0r5 that originates on Router 0 and terminates on Router 5. In transit, this LSP traverses the FA-LSP fa_lsp_r1r4. The return path is represented by the end-to-end RSVP LSP e2e_lsp_r5r0 that travels over the FA-LSP fa_lsp_r4r1.

On Router 0, configure the end-to-end RSVP LSP that travels to Router  5. Use a strict path that traverses Router 1 and the LMP traffic engineering link traveling from Router 1 to Router 4.

Router 0

On Router 1, configure an FA-LSP to reach Router 4. Establish an LMP traffic engineering link and LMP peer relationship with Router 4. Reference the FA-LSP in the traffic engineering link and add the peer interface into both OSPF and RSVP.

When the return path end-to-end LSP arrives at Router 1, the routing platform performs a routing lookup and can forward traffic to Router 0. Make sure you configure OSPF correctly between Routers 0 and 1.

Router 1

On Router 2, configure OSPF, MPLS, and RSVP on all interfaces that transport the FA-LSPs across the core network.

Router 2

On Router 3, configure OSPF, MPLS, and RSVP on all interfaces that transport the FA-LSPs across the core network.

Router 3

On Router 4, configure a return path FA-LSP to reach Router 1. Establish an LMP traffic engineering link and LMP peer relationship with Router 1. Reference the FA-LSP in the traffic engineering link and add the peer interface into both OSPF and RSVP.

When the initial end-to-end LSP arrives at Router 4, the routing platform performs a routing lookup and can forward traffic to Router 5. Make sure you configure OSPF correctly between Router 4 and Router 5.

Router 4

On Router 5, configure the return path end-to-end RSVP LSP that travels to Router 0. Use a strict path that traverses Router 4 and the LMP traffic engineering link traveling from Router 4 to Router 1.

Router 5

Verifying Your Work

To verify that your RSVP LSP tunnel is working correctly, issue the following commands:

  • show ted database (extensive)

  • show rsvp session name (extensive)

  • show link-management

  • show link-management te-link name (detail)

To see these commands used with the configuration example, see the following sections:

Router 0

On Router 0, you can verify that the FA-LSPs appear as valid paths in the traffic engineering database. In this case, look for the paths from Router 1 (10.255.41.216) and Router 4 (10.255.41.217) that reference the LMP traffic engineering link addresses of 172.16.30.1 and 172.16.30.2. You can also issue the show rsvp session extensive command to look for the path of the end-to-end LSP as it travels to Router 5 over the FA-LSP.

user@router0> show ted database

Router 1

On Router 1, verify that your LMP traffic engineering link configuration is working and that the end-to-end LSP is traversing the traffic engineering link by issuing the show link-management set of commands. You can also issue the show rsvp session extensive command to confirm that the FA-LSP is operational.

user@router1> show link-management

After you set up traffic engineering links, configure LMP network peers with the peer peer-name statement at the [edit protocols link-management] hierarchy level. A peer is the network device with which your routing platform communicates and establishes an FA-LSP. Designate a peer name, configure the peer router ID as the address (often a loopback address), and apply the traffic engineering link to be associated with this peer. Remember to configure both sides of a peering relationship to enable bidirectional communication.

Unlike GMPLS, you must not configure a control channel for a peer. If you include a control channel, the commit operation fails.

To begin your RSVP LSP tunnel configuration, configure LMP traffic engineering links on both the ingress and egress routing platforms. Because traffic engineering links define a unidirectional connection between peer devices, you must configure traffic engineering links in both directions between peers to enable the bidirectional transport of packets.

To configure traffic engineering links in LMP, include the te-link te-link-name statement at the [edit protocols link-management] hierarchy level. Define the traffic engineering link options shown below, especially the label-switched path to be used as the FA-LSP to reach the peer. Optionally, you can specify the traffic engineering metric for the traffic engineering link (TE link). By default, the traffic engineering metric is derived from the CSPF computation.

Configuring Peer Interfaces in OSPF and RSVP

After you establish LMP peers, you must add peer interfaces to OSPF and RSVP. A peer interface is a virtual interface used to support the control adjacency between two peers.

The peer interface name must match the peer peer-name statement configured in LMP at the [edit protocols link-management] hierarchy level. Because actual protocol packets are sent and received by peer interfaces, the peer interfaces can be signaled and advertised to peers like any other physical interface configured for OSPF and RSVP. To configure OSPF routing for LMP peers, include the peer-interface statement at the [edit protocols ospf area area-number] hierarchy level. To configure RSVP signaling for LMP peers, include the peer-interface statement at the [edit protocols rsvp] hierarchy level.

Defining Label-Switched Paths for the FA-LSP

Next, define your FA-LSP by including the label-switched-path statement at the [edit protocols mpls] hierarchy level. Include the router ID of the peer in the to statement at the [edit protocols mpls label-switched-path] hierarchy level. Because packet LSPs are unidirectional, you must create one FA-LSP to reach the peer and a second FA-LSP to return from the peer.

Establishing FA-LSP Path Information

When you configure explicit LSP paths for an FA-LSP, you must use the traffic engineering link remote address as your next-hop address. When CSPF is supported, you can use any path option you wish. However, when CSPF is disabled with the no-cspf statement at the [edit protocols mpls label-switched-path lsp-name] hierarchy level, you must use strict paths.

Note

If the end-to-end LSP originates on the same routing platform as the FA-LSP, you must disable CSPF and use strict paths.

Option: Tearing Down RSVP LSPs Gracefully

You can tear down an RSVP LSP in a two-step process that gracefully withdraws the RSVP session used by the LSP. For all neighbors that support graceful teardown, a request for the teardown is sent by the routing platform to the destination endpoint for the LSP and all RSVP neighbors in the path. The request is included within the ADMIN_STATUS field of the RSVP packet. When neighbors receive the request, they prepare for the RSVP session to be withdrawn. A second message is sent by the routing platform to complete the teardown of the RSVP session. If a neighbor does not support graceful teardown, the request is handled as a standard session teardown rather than a graceful one.

To perform a graceful teardown of an RSVP session, issue the clear rsvp session gracefully command. Optionally, you can specify the source and destination address of the RSVP session, the LSP identifier of the RSVP sender, and the tunnel identifier of the RSVP session. To use these qualifiers, include the connection-source, connection-destination, lsp-id, and tunnel-id options when you issue the clear rsvp session gracefully command.

You can also configure the amount of time that the routing platform waits for neighbors to receive the graceful teardown request before initiating the actual teardown by including the graceful-deletion-timeout statement at the [edit protocols rsvp] hierarchy level. The default graceful deletion timeout value is 30 seconds, with a minimum value of 1 second and a maximum value of 300 seconds. To view the current value configured for graceful deletion timeout, issue the show rsvp version operational mode command.

Related Documentation

Release History Table
Release
Description
However, starting from Junos OS Release 16.1, when RSVP hello messages time-out, the RSVP sessions are brought down.