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 detailRSVP neighbor: 6 learned
Address: 192.168.224.178 via: fxp1.0 status: Up
Last changed time: 10:06, Idle: 5 sec, Up cnt: 1, Down cnt: 0
Message received: 36
Hello: sent 69, received: 69, interval: 9 sec
Remote instance: 0x60b8feba, Local instance: 0x74bc7a8d
Refresh reduction: not operational
Address: 192.168.224.186 via: fxp2.0 status: Down
Last changed time: 10:17, Idle: 40 sec, Up cnt: 0, Down cnt: 0
Message received: 6
Hello: sent 20, received: 0, interval: 9 sec
Remote instance: 0x0, Local instance: 0x2ae1b339
Refresh reduction: incomplete
Remote end: disabled, Ack-extension: enabled
Address: 192.168.224.188 via: fxp2.0 status: Up
Last changed time: 4:15, Idle: 0 sec, Up cnt: 1, Down cnt: 0
Message received: 55
Hello: sent 47, received: 31, interval: 9 sec
Remote instance: 0x6436a35b, Local instance: 0x663849f0
Refresh reduction: operational
Remote end: enabled, Ack-extension: enabled
For more information on the show rsvp neighbor detail command, see the Junos OS Operational Mode Commands.
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, the RSVP hello interval might impact 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 1 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.
To adjust the threshold at which a change in the reserved bandwidth triggers an IGP update, include the update-threshold 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]
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.
