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.
rsvp { interface interface-name; }
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:
interface interface-name { disable; }
You can include this statement at the following hierarchy levels:
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.
You can configure RSVP label-switched paths (LSPs) to use a delay metric for computing
the path. To configure, use the CLI options that we've introduced under the
[edit protocols mpls label-switched-path name]
hierarchy.
Example: Configuring RSVP and MPLS
The following shows a sample configuration for a router at the beginning of an LSP:
[edit]
protocols {
mpls {
label-switched-path sf-to-london {
to 192.168.1.4;
}
}
rsvp {
interface so-0/0/0;
}
}
The following shows a sample configuration for all the other routers that form the LSP:
[edit]
protocols {
mpls {
interface so-0/0/0;
}
rsvp {
interface so-0/0/0;
}
}
Configuring RSVP Interfaces
The following sections describe how to configure RSVP interfaces:
- Configuring RSVP Refresh Reduction
- Configuring the RSVP Hello Interval
- Configuring RSVP Authentication
- Configuring the Bandwidth Subscription for Class Types
- Configuring the RSVP Update Threshold on an Interface
- Configuring RSVP for Unnumbered Interfaces
Configuring RSVP Refresh Reduction
You can configure RSVP refresh reduction on each interface by including the following statements in the interface configuration:
aggregateandreliable—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
aggregateandreliablestatements.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:
aggregate;
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:
no-aggregate;
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:
reliable;
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:
no-reliable;
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
RSVP 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.
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:
hello-interval seconds;
Starting in release 16.1 Junos sends RSVP hello messages over a bypass LSP when one is available. See no-node-hello-on-bypass for information on how to revert to the historic behavior of sending hellos over the IGP next hop.
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:
authentication-key key;
You can include this statement at the following hierarchy levels:
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.
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.
Starting in release 16.1 Junos sends RSVP hello messages over a bypass LSP when one is available. See no-node-hello-on-bypass for information on how to revert to the historic behavior of sending hellos over the IGP next hop.
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.
Topology
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
Procedure
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.
set interfaces ge-0/0/0 unit 0 family mpls set protocols rsvp interface ge-0/0/0.0 set protocols mpls label-switched-path r1-r7 to 10.0.9.7 set protocols mpls label-switched-path r1-r7 bandwidth 10m set protocols mpls interface all
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:
Enable the MPLS family on all transit interfaces in the MPLS network.
[edit] user@host# set interfaces ge-0/0/0 unit 0 family mpls
Enable RSVP on each transit interface in the MPLS network.
[edit] user @host# set protocols rsvp interface ge-0/0/0
Enable the MPLS process on the transit interface in the MPLS network.
[edit] user@host# set protocols mpls interface ge-0/0/0
Define the LSP on the ingress router.
[edit protocols mpls] user@host# set label-switched-path r1-r7 to 10.0.9.7
Reserve 10 Mbps of bandwidth on the LSP.
[edit protocols mpls] user @host# set label-switched-path r1-r7 bandwidth 10m
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 (...).
user@host# show
...
interfaces {
ge-0/0/0 {
family mpls;
}
}
}
...
protocols {
rsvp {
interface ge-0/0/0.0;
}
mpls {
label-switched-path r1-r7 {
to 10.0.9.7;
bandwidth 10m;
}
interface all;
}
}
...
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 RSVP neighbor: 2 learned Address Idle Up/Dn LastChange HelloInt HelloTx/Rx 10.0.6.2 0 3/2 13:01 3 366/349 10.0.3.3 0 1/0 22:49 3 448/448
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 Ingress RSVP: 1 sessions 10.0.9.7 From: 10.0.6.1, LSPstate: Up, ActiveRoute: 0 LSPname: r1–r7, LSPpath: Primary Bidirectional, Upstream label in: –, Upstream label out: - Suggested label received: -, Suggested label sent: – Recovery label received: -, Recovery label sent: 100000 Resv style: 1 FF, Label in: -, Label out: 100000 Time left: -, Since: Thu Jan 26 17:57:45 2002 Tspec: rate 10Mbps size 10Mbps peak Infbps m 20 M 1500 Port number: sender 3 receiver 17 protocol 0 PATH rcvfrom: localclient PATH sentto: 10.0.4.13 (ge-0/0/1.0) 1467 pkts RESV rcvfrom: 10.0.4.13 (ge-0/0/1.0) 1467 pkts Record route: <self> 10.0.4.13 10.0.2.1 10.0.8.10
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
inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.9.7/32 *[RSVP/7] 00:05:29, metric 10
> to 10.0.4.17 via ge-0/0/0.0, label-switched-path r1–r7
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.
Configuration
Configuring RSVP automatic mesh involves performing these tasks:
Enabling the
rsvp-teconfiguration statement at the[edit routing-options dynamic-tunnels dynamic-tunnel-name]hierarchy level.Configuring the required
destination-networkselement.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-templateelement.This configuration element takes either
default-templateor the name of a preconfigured LSP template as an argument. Thedefault-templateis 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
set routing-options dynamic-tunnels dt-1 rsvp-te rsvp-te-1 label-switched-path-template default-template set routing-options dynamic-tunnels dt-1 rsvp-te rsvp-te-1 destination-networks 192.0.2.0/24
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:
Configure
rsvp-teat the[edit routing-options dynamic-tunnels]hierarchy level.[edit routing-options dynamic-tunnels] user@PE4# set dt-1 rsvp-te rsvp-te-1 label-switched-path-template default-template
Configure
destination-networksat the[edit routing-options dynamic-tunnels]hierarchy level.[edit routing-options dynamic-tunnels] user@PE4# set dt-1 rsvp-te rsvp-te-1 destination-networks 192.0.2.0/24
Results
Issue the show command from the [edit
routing-options dynamic-tunnels] hierarchy level to see the
results of your configuration:
[edit routing-options dynamic-tunnels]
user@PE4#show
dt-1 {
rsvp-te rsvp-te-1 {
label-switched-path-template {
default-template;
}
destination-networks {
192.0.2.0/24;
}
}
}
Verification
- Verifying the Existence of RSVP Automatic Mesh Tunnels on Router PE4
- Verifying the Existence of MPLS LSPs on Router PE4
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
user@PE4> show dynamic-tunnels database Table: inet.3 Destination-network: 192.0.2.0/24
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
user@PE4> show mpls lsp
Ingress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress LSP: 3 sessions To From State Rt Style Labelin Labelout LSPname 192.0.2.104 192.0.2.103 Up 0 1 FF 3 - PE2-PE4 192.0.2.104 192.0.2.102 Up 0 1 FF 3 - PE2-PE4 192.0.2.104 192.0.2.101 Up 0 1 FF 3 - PE1-PE4 Total 3 displayed, Up 3, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0
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.
hello-acknowledgements;
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.
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-lspsstatement 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:
A failed link or node is present on the strict explicit path of an LSP before the LSP is signaled.
There is also a bypass LSP protecting the link or node.
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.
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
setup-protection;
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:
[edit policy-options] policy-statement policy-name { then { load-balance per-packet; } accept; }
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:
load-balance { bandwidth; }
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-balancestatement, the behavior of currently running LSPs is not altered. To force currently running LSPs to use the new behavior, you can issue aclear mpls lspcommand.The
load-balancestatement 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.
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:
rsvp-te { destination-networks network-prefix; label-switched-path-template (Multicast) { default-template; template-name; } }
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 thedefault-templateoption, or you can configure an LSP template of your own using thetemplate-nameoption. 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 therefresh-timestatement’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:
lifetime = (keep-multiplier + 0.5) x (1.5 x refresh-time)
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:
refresh-time seconds;
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:
keep-multiplier number;
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:
preemption aggressive;
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:
preemption disabled;
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:
preemption normal;
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:
path-mtu { allow-fragmentation; rsvp { mtu-signaling; } }
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:
rsvp mtu-signaling;
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:
allow-fragmentation;
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-fragmentationstatement alone. Always configure it in conjunction with themtu-signalingstatement.
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.
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).
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
traceroutecommand
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-labelstatement 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-labelstatement 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-servicestatement 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-nexthopstatement. 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.
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.
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:
explicit-null;
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:
tunnel-services { devices device-names; }
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:
interface all;
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:
traceoptions { file filename <files number> <size size> <world-readable | no-world-readable>; flag flag <flag-modifier> <disable>; }
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 conditionsevent—RSVP-related events (helps to trace events related to RSVP graceful restart)lmp—RSVP-Link Management Protocol (LMP) interactionspackets—All RSVP packetspath—All path messagespathtear—PathTear messagesresv—Resv messagesresvtear—ResvTear messagesroute—Routing informationstate—Session state transitions, including when RSVP-signaled LSPs come up and go down.
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 for Routing Devices.
Examples: Tracing RSVP Protocol Traffic
Trace RSVP path messages in detail:
[edit]
protocols {
rsvp {
traceoptions {
file rsvp size 10m files 5;
flag path;
}
}
}
Trace all RSVP messages:
[edit]
protocols {
rsvp {
traceoptions {
file rsvp size 10m files 5;
flag packets;
}
}
}
Trace all RSVP error conditions:
[edit]
protocols {
rsvp {
traceoptions {
file rsvp size 10m files 5;
flag error;
}
}
}
Trace RSVP state transitions:
[edit]
protocols {
rsvp {
traceoptions {
file rsvp-data;
flag state;
}
}
}
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.
user@host> show log rsvp-data
Mar 11 13:58:51 trace_on: Tracing to "/var/log/E/rsvp-data" started
Mar 11 13:58:51.286413 rsvp_iflchange for vt ifl vt-1/2/0.69206016
Mar 11 13:58:51.286718 RSVP add interface vt-1/2/0.69206016, ifindex 101, ifaddr (null), family 1, is_appl_vt 0, already known
Mar 11 13:58:51.286818 RSVP Peer vt-1/2/0.69206016 TE-link __rpd:vt-1/2/0.69206016 Up
Mar 11 13:58:51.286978 RSVP add interface vt-1/2/0.69206016, ifindex 101, ifaddr (null), family 3, is_appl_vt 0, already known
Mar 11 13:58:51.287962 RSVP add interface lt-1/2/0.2, ifindex 113, ifaddr (null), family 2, is_appl_vt 0, already known
Mar 11 13:58:51.288629 RSVP add interface lt-1/2/0.2, ifindex 113, ifaddr 10.0.0.2, family 1, is_appl_vt 0, already known
Mar 11 13:58:51.288996 RSVP add interface lt-1/2/0.17, ifindex 114, ifaddr (null), family 2, is_appl_vt 0, already known
Mar 11 13:58:51.289593 RSVP add interface lt-1/2/0.17, ifindex 114, ifaddr (null), family 3, is_appl_vt 0, already known
Mar 11 13:58:51.289949 RSVP add interface lt-1/2/0.17, ifindex 114, ifaddr 10.0.0.17, family 1, is_appl_vt 0, already known
Mar 11 13:58:51.290049 RSVP Peer lt-1/2/0.17 TE-link __rpd:lt-1/2/0.17 Up
Mar 11 13:59:05.042034 RSVP new bypass Bypass->10.0.0.18 on interface lt-1/2/0.17 to 10.0.0.18 avoid 0.0.0.0
Mar 11 14:04:36.707092 LSP "E-D" is Down (Reason: Reservation state deleted)
Session: 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0 Sender: 192.168.0.5(port/lsp ID 1)
Mar 11 14:04:36.707661 RSVP delete resv state, session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0
Mar 11 14:04:36.781185 RSVP delete path state, session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0
Mar 11 14:04:36.781440 RSVP delete session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0
Mar 11 14:05:30.101492 RSVP new Session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0, session ID 3
Mar 11 14:05:30.101722 RSVP new path state, session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0
Mar 11 14:05:30.179124 RSVP new resv state, session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0
Mar 11 14:05:30.179395 RSVP PSB E-D, allocating psb resources for label 4294967295
Mar 11 14:05:30.180353 LSP "E-D" is Up
Session: 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0 Sender: 192.168.0.5(port/lsp ID 2)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
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.
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.
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.
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
- Disabling Graceful Restart for RSVP
- Disabling RSVP Helper Mode
- Configuring the Maximum Helper Recovery Time
- Configuring the Maximum Helper Restart Time
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 for Routing Devices.
To enable graceful restart on the router, include the graceful-restart statement:
graceful-restart;
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:
disable;
Disabling RSVP Helper Mode
To disable RSVP helper mode, include the helper-disable statement at the [edit protocols rsvp graceful-restart] hierarchy level:
helper-disable;
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.
maximum-helper-recovery-time seconds;
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.
maximum-helper-restart-time seconds;
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 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
[edit]
interfaces {
so-0/0/3 {
unit 0 {
family inet {
address 10.1.2.1/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.41.222/32;
}
family mpls;
}
}
}
routing-options {
forwarding-table {
export pplb;
}
}
protocols {
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
label-switched-path e2e_lsp_r0r5 { # An end-to-end LSP traveling to Router 5.
to 10.255.41.221;
bandwidth 30k;
primary path-fa; # Reference the requested path here.
}
path path-fa { # Configure the strict path here.
10.1.2.2 strict;
172.16.30.2 strict; # This traverses the TE link heading to Router 4.
}
interface all;
interface fxp0.0 {
disable;
}
interface so-3/2/1.0 {
admin-group other;
}
interface so-0/0/3.0 {
admin-group other;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
}
}
}
policy-options {
policy-statement pplb {
then {
load-balance per-packet;
}
}
}
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
[edit]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.2.3.1/30;
}
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.2.4.1/30;
}
family mpls;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.2.2/30;
}
family mpls;
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.2.5.1/30;
}
family mpls;
}
}
at-1/0/0 {
atm-options {
vpi 1;
}
unit 0 {
vci 1.100;
family inet {
address 10.2.3.5/30;
}
family mpls;
}
}
}
routing-options {
forwarding-table {
export [ pplb choose_lsp ];
}
}
protocols {
rsvp {
interface all;
interface fxp0.0 {
disable;
}
peer-interface r4; # Apply the LMP peer interface here.
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
label-switched-path fa_lsp_r1r4 { # Configure your FA-LSP to Router 4 here.
to 10.255.41.217;
bandwidth 400k;
primary path_r1r4; # Apply the FA-LSP path here.
}
path path_r1r4 { # Configure the FA-LSP path here.
10.2.4.2;
10.4.5.2;
10.3.5.1;
}
interface so-0/0/3.0 {
admin-group other;
}
interface so-0/0/1.0 {
admin-group fa;
}
interface at-1/0/0.0 {
admin-group backup;
}
interface fe-0/1/2.0 {
admin-group backup;
}
interface so-0/0/2.0 {
admin-group fa;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
peer-interface r4; # Apply the LMP peer interface here.
}
}
link-management { # Configure LMP statements here.
te-link link_r1r4 { # Assign a name to the TE link here.
local-address 172.16.30.1; # Configure a local address for the TE link.
remote-address 172.16.30.2; # Configure a remote address for the TE link.
te-metric 1; # Manually set a metric here if you are not relying on CSPF.
label-switched-path fa_lsp_r1r4; # Reference the FA-LSP here.
}
peer r4 { # Configure LMP peers here.
address 10.255.41.217; # Configure the loopback address of your peer here.
te-link link_r1r4; # Apply the LMP TE link here.
}
}
}
policy-options {
policy-statement choose_lsp {
term A {
from community choose_e2e_lsp;
then {
install-nexthop strict lsp e2e_lsp_r1r4;
accept;
}
}
term B {
from community choose_fa_lsp;
then {
install-nexthop strict lsp fa_lsp_r1r4;
accept;
}
}
}
policy-statement pplb {
then {
load-balance per-packet;
}
}
community choose_e2e_lsp members 1000:1000;
community choose_fa_lsp members 2000:2000;
community set_e2e_lsp members 1000:1000;
community set_fa_lsp members 2000:2000;
}
On Router 2, configure OSPF, MPLS, and RSVP on all interfaces that transport the FA-LSPs across the core network.
Router 2
[edit]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.4.5.1/30;
}
family mpls;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.1.4.2/30;
}
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.2.4.2/30;
}
family mpls;
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.3.4.2/30;
}
family mpls;
}
}
}
routing-options {
forwarding-table {
export pplb;
}
}
protocols { # OSPF, MPLS, and RSVP form the core backbone for the FA-LSPs.
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
path path_r1 {
10.2.4.1;
}
path path_r3r4 {
10.4.5.2;
10.3.5.1;
}
interface all;
interface fxp0.0 {
disable;
}
interface so-0/0/1.0 {
admin-group other;
}
interface fe-0/1/2.0 {
admin-group backup;
}
interface so-0/0/2.0 {
admin-group fa;
}
interface so-0/0/0.0 {
admin-group fa;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
}
}
}
policy-options {
policy-statement pplb {
then {
load-balance per-packet;
}
}
}
On Router 3, configure OSPF, MPLS, and RSVP on all interfaces that transport the FA-LSPs across the core network.
Router 3
[edit]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.4.5.2/30;
}
family mpls;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.5.6.1/30;
}
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.3.5.2/30;
}
family mpls;
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.2.5.2/30;
}
family mpls;
}
}
}
routing-options {
forwarding-table {
export pplb;
}
}
protocols { # OSPF, MPLS, and RSVP form the core backbone for the FA-LSPs.
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
path path_r4 {
10.3.5.1;
}
path path_r2r1 {
10.4.5.1;
10.2.4.1;
}
interface all;
interface fxp0.0 {
disable;
}
interface so-0/0/2.0 {
admin-group fa;
}
interface fe-0/1/2.0 {
admin-group backup;
}
interface so-0/0/1.0 {
admin-group other;
}
interface so-0/0/0.0 {
admin-group fa;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
}
}
}
policy-options {
policy-statement pplb {
then {
load-balance per-packet;
}
}
}
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
[edit]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.3.6.1/30;
}
family mpls;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.2.3.2/30;
}
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.3.5.1/30;
}
family mpls;
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.3.4.1/30;
}
family mpls;
}
}
at-1/0/0 {
atm-options {
vpi 1;
}
unit 0 {
vci 1.100;
family inet {
address 10.2.3.6/30;
}
family mpls;
}
}
}
routing-options {
forwarding-table {
export [ pplb choose_lsp ];
}
}
protocols {
rsvp {
interface all;
interface fxp0.0 {
disable;
}
peer-interface r1; # Apply the LMP peer interface here.
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
label-switched-path fa_lsp_r4r1 { # Configure your FA-LSP here.
to 10.255.41.216;
bandwidth 400k;
primary path_r4r1; # Apply the FA-LSP path here.
}
path path_r4r1 { # Configure the FA-LSP path here.
10.3.5.2;
10.4.5.1;
10.2.4.1;
}
interface all;
interface fxp0.0 {
disable;
}
interface at-1/0/0.0 {
admin-group backup;
}
interface so-0/0/2.0 {
admin-group fa;
}
interface fe-0/1/2.0 {
admin-group backup;
}
interface so-0/0/0.0 {
admin-group other;
}
interface so-0/0/1.0 {
admin-group fa;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
peer-interface r1; # Apply the LMP peer interface here.
}
}
link-management { # Configure LMP statements here.
te-link link_r4r1 { # Assign a name to the TE link here.
local-address 172.16.30.2; # Configure a local address for the TE link.
remote-address 172.16.30.1; # Configure a remote address for the TE link.
te-metric 1; # Manually set a metric here if you are not relying on CSPF.
label-switched-path fa_lsp_r4r1; # Reference the FA-LSP here.
}
peer r1 { # Configure LMP peers here.
address 10.255.41.216; # Configure the loopback address of your peer here.
te-link link_r4r1; # Apply the LMP TE link here.
}
}
}
policy-options {
policy-statement choose_lsp {
term A {
from community choose_e2e_lsp;
then {
install-nexthop strict lsp e2e_lsp_r4r1;
accept;
}
}
term B {
from community choose_fa_lsp;
then {
install-nexthop strict lsp fa_lsp_r4r1;
accept;
}
}
}
policy-statement pplb {
then {
load-balance per-packet;
}
}
community choose_e2e_lsp members 1000:1000;
community choose_fa_lsp members 2000:2000;
community set_e2e_lsp members 1000:1000;
community set_fa_lsp members 2000:2000;
}
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
[edit]
interfaces {
so-0/0/2 {
unit 0 {
family inet {
address 10.3.6.2/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.41.221/32;
}
}
}
}
routing-options {
forwarding-table {
export pplb;
}
}
protocols {
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
label-switched-path e2e_lsp_r5r0 { # An end-to-end LSP returning to Router 0.
to 10.255.41.222;
bandwidth 30k;
primary path-fa; # Reference the requested path here.
}
path path-fa { # Configure the strict path here.
10.3.6.1 strict;
172.16.30.1 strict; # This traverses the TE link heading to Router 1.
}
interface all;
interface fxp0.0 {
disable;
}
interface so-0/0/2.0 {
admin-group other;
}
interface so-0/0/1.0 {
admin-group other;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
}
}
}
policy-options {
policy-statement pplb {
then {
load-balance per-packet;
}
}
}
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-managementshow 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
TED database: 0 ISIS nodes 8 INET nodes
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.214 Rtr 486 4 4 OSPF(0.0.0.0)
To: 10.255.41.222, Local: 10.1.4.2, Remote: 10.1.4.1
To: 10.255.41.216, Local: 10.2.4.2, Remote: 10.2.4.1
To: 10.255.41.215, Local: 10.4.5.1, Remote: 10.4.5.2
To: 10.3.4.1-1, Local: 10.3.4.2, Remote: 0.0.0.0
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.215 Rtr 187 4 4 OSPF(0.0.0.0)
To: 10.255.41.214, Local: 10.4.5.2, Remote: 10.4.5.1
To: 10.255.41.217, Local: 10.3.5.2, Remote: 10.3.5.1
To: 10.255.41.221, Local: 10.5.6.1, Remote: 10.5.6.2
To: 10.2.5.1-1, Local: 10.2.5.2, Remote: 0.0.0.0
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.216 Rtr 396 6 6 OSPF(0.0.0.0)
To: 10.255.41.222, Local: 10.1.2.2, Remote: 10.1.2.1
To: 10.255.41.214, Local: 10.2.4.1, Remote: 10.2.4.2
To: 10.255.41.217, Local: 10.2.3.1, Remote: 10.2.3.2
To: 10.255.41.217, Local: 172.16.30.1, Remote: 172.16.30.2
To: 10.255.41.217, Local: 10.2.3.5, Remote: 10.2.3.6
To: 10.2.5.1-1, Local: 10.2.5.1, Remote: 0.0.0.0
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.217 Rtr 404 6 6 OSPF(0.0.0.0)
To: 10.255.41.216, Local: 10.2.3.2, Remote: 10.2.3.1
To: 10.255.41.216, Local: 172.16.30.2, Remote: 172.16.30.1
To: 10.255.41.216, Local: 10.2.3.6, Remote: 10.2.3.5
To: 10.255.41.215, Local: 10.3.5.1, Remote: 10.3.5.2
To: 10.255.41.221, Local: 10.3.6.1, Remote: 10.3.6.2
To: 10.3.4.1-1, Local: 10.3.4.1, Remote: 0.0.0.0
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.221 Rtr 481 2 2 OSPF(0.0.0.0)
To: 10.255.41.215, Local: 10.5.6.2, Remote: 10.5.6.1
To: 10.255.41.217, Local: 10.3.6.2, Remote: 10.3.6.1
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.222 Rtr 2883 2 2 OSPF(0.0.0.0)
To: 10.255.41.216, Local: 10.1.2.1, Remote: 10.1.2.2
To: 10.255.41.214, Local: 10.1.4.1, Remote: 10.1.4.2
user@router0> show ted database 10.255.41.216 extensive
TED database: 0 ISIS nodes 8 INET nodes
NodeID: 10.255.41.216
Type: Rtr, Age: 421 secs, LinkIn: 6, LinkOut: 6
Protocol: OSPF(0.0.0.0)
To: 10.255.41.222, Local: 10.1.2.2, Remote: 10.1.2.1
Color: 0x8 other
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.4Mbps [1] 155.4Mbps [2] 155.4Mbps [3] 155.4Mbps
[4] 155.4Mbps [5] 155.4Mbps [6] 155.4Mbps [7] 155.4Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.4Mbps [1] 155.4Mbps [2] 155.4Mbps [3] 155.4Mbps
[4] 155.4Mbps [5] 155.4Mbps [6] 155.4Mbps [7] 155.4Mbps
To: 10.255.41.214, Local: 10.2.4.1, Remote: 10.2.4.2
Color: 0x2 fa
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.12Mbps [1] 155.12Mbps [2] 155.12Mbps [3] 155.12Mbps
[4] 155.12Mbps [5] 155.12Mbps [6] 155.12Mbps [7] 155.12Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.12Mbps [1] 155.12Mbps [2] 155.12Mbps [3] 155.12Mbps
[4] 155.12Mbps [5] 155.12Mbps [6] 155.12Mbps [7] 155.12Mbps
To: 10.255.41.217, Local: 10.2.3.1, Remote: 10.2.3.2
Color: 0x2 fa
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
To: 10.255.41.217, Local: 172.16.30.1, Remote: 172.16.30.2
Metric: 1
Static BW: 400kbps
Reservable BW: 400kbps
Available BW [priority] bps:
[0] 370kbps [1] 370kbps [2] 370kbps [3] 370kbps
[4] 370kbps [5] 370kbps [6] 370kbps [7] 370kbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 370kbps [1] 370kbps [2] 370kbps [3] 370kbps
[4] 370kbps [5] 370kbps [6] 370kbps [7] 370kbps
To: 10.255.41.217, Local: 10.2.3.5, Remote: 10.2.3.6
Color: 0x4 backup
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
To: 10.2.5.1-1, Local: 10.2.5.1, Remote: 0.0.0.0
Color: 0x4 backup
Metric: 1
Static BW: 100Mbps
Reservable BW: 100Mbps
Available BW [priority] bps:
[0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps
[4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps
[4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps
user@router0> show ted database 10.255.41.217 extensive
TED database: 0 ISIS nodes 8 INET nodes
NodeID: 10.255.41.217
Type: Rtr, Age: 473 secs, LinkIn: 6, LinkOut: 6
Protocol: OSPF(0.0.0.0)
To: 10.255.41.216, Local: 10.2.3.2, Remote: 10.2.3.1
Color: 0x2 fa
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
To: 10.255.41.216, Local: 172.16.30.2, Remote: 172.16.30.1
Metric: 1
Static BW: 400kbps
Reservable BW: 400kbps
Available BW [priority] bps:
[0] 370kbps [1] 370kbps [2] 370kbps [3] 370kbps
[4] 370kbps [5] 370kbps [6] 370kbps [7] 370kbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 370kbps [1] 370kbps [2] 370kbps [3] 370kbps
[4] 370kbps [5] 370kbps [6] 370kbps [7] 370kbps
To: 10.255.41.216, Local: 10.2.3.6, Remote: 10.2.3.5
Color: 0x4 backup
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
To: 10.255.41.215, Local: 10.3.5.1, Remote: 10.3.5.2
Color: 0x2 fa
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.12Mbps [1] 155.12Mbps [2] 155.12Mbps [3] 155.12Mbps
[4] 155.12Mbps [5] 155.12Mbps [6] 155.12Mbps [7] 155.12Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.12Mbps [1] 155.12Mbps [2] 155.12Mbps [3] 155.12Mbps
[4] 155.12Mbps [5] 155.12Mbps [6] 155.12Mbps [7] 155.12Mbps
To: 10.255.41.221, Local: 10.3.6.1, Remote: 10.3.6.2
Color: 0x8 other
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
To: 10.3.4.1-1, Local: 10.3.4.1, Remote: 0.0.0.0
Color: 0x4 backup
Metric: 1
Static BW: 100Mbps
Reservable BW: 100Mbps
Available BW [priority] bps:
[0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps
[4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps
[4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps
user@router0> show rsvp session name e2e_lsp_r0r5 extensive
Ingress RSVP: 1 sessions
10.255.41.221
From: 10.255.41.222, LSPstate: Up, ActiveRoute: 2
LSPname: e2e_lsp_r0r5, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 101584
Resv style: 1 FF, Label in: -, Label out: 101584
Time left: -, Since: Wed Sep 7 19:02:56 2005
Tspec: rate 30kbps size 30kbps peak Infbps m 20 M 1500
Port number: sender 2 receiver 29458 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 10.1.2.2 (so-0/0/3.0) 15 pkts
RESV rcvfrom: 10.1.2.2 (so-0/0/3.0) 16 pkts
Explct route: 10.1.2.2 172.16.30.2 10.3.6.2
Record route: <self> 10.1.2.2 172.16.30.2 10.3.6.2
Total 1 displayed, Up 1, Down 0
Egress RSVP: 1 sessions
Total 0 displayed, Up 0, Down 0
Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0
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
Peer name: r4 , System identifier: 10758
State: Up, Control address: 10.255.41.217
TE links:
link_r1r4
TE link name: link_r1r4, State: Up
Local identifier: 16299, Remote identifier: 0, Local address: 172.16.30.1, Remote address: 172.16.30.2,
Encoding: Packet, Switching: Packet, Minimum bandwidth: 0bps, Maximum bandwidth: 400kbps,
Total bandwidth: 400kbps, Available bandwidth: 370kbps
Name State Local ID Remote ID Bandwidth Used LSP-name
fa_lsp_r1r4 Up 22642 0 400kbps Yes e2e_lsp_r0r5
user@router1> show link-management te-link name link_r1r4 detail
TE link name: link_r1r4, State: Up
Local identifier: 16299, Remote identifier: 0, Local address: 172.16.30.1, Remote address: 172.16.30.2,
Encoding: Packet, Switching: Packet, Minimum bandwidth: 0bps, Maximum bandwidth: 400kbps,
Total bandwidth: 400kbps, Available bandwidth: 370kbps
Resource: fa_lsp_r1r4, Type: LSP, System identifier: 2147483683, State: Up, Local identifier: 22642,
Remote identifier: 0
Total bandwidth: 400kbps, Unallocated bandwidth: 370kbps
Traffic parameters: Encoding: Packet, Switching: Packet, Granularity: Unknown
Number of allocations: 1, In use: Yes
LSP name: e2e_lsp_r0r5, Allocated bandwidth: 30kbps
user@router1> show rsvp session name fa_lsp_r1r4 extensive
Ingress RSVP: 1 sessions
10.255.41.217
From: 10.255.41.216, LSPstate: Up, ActiveRoute: 0
LSPname: fa_lsp_r1r4, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 100816
Resv style: 1 FF, Label in: -, Label out: 100816
Time left: -, Since: Wed Sep 7 19:02:33 2005
Tspec: rate 400kbps size 400kbps peak Infbps m 20 M 1500
Port number: sender 2 receiver 5933 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 10.2.4.2 (so-0/0/2.0) 28 pkts
RESV rcvfrom: 10.2.4.2 (so-0/0/2.0) 26 pkts
Explct route: 10.2.4.2 10.4.5.2 10.3.5.1
Record route: <self> 10.2.4.2 10.4.5.2 10.3.5.1
Total 1 displayed, Up 1, Down 0
Egress RSVP: 1 sessions
Total 0 displayed, Up 0, Down 0
Transit RSVP: 2 sessions
Total 0 displayed, Up 0, Down 0
Configuring Link Management Protocol Peers
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.
[edit]
protocols {
link-management {
peer peer-name { # Configure the name of your network peer.
address ip-address; # Include the router ID of the peer.
te-link te-link-name; # Assign a TE link to this peer.
}
}
}
Configuring Link Management Protocol Traffic Engineering Links
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.
[edit]
protocols {
link-management {
te-link te-link-name { # Name of the TE link.
label-switched-path lsp-name; # LSP used for the forwarding adjacency.
local-address ip-address; # Local IP address associated with the TE link.
remote-address ip-address; # Remote IP address mapped to the TE link.
te-metric value; # Traffic engineering metric used for the TE link.
}
}
}
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.
[edit]
protocols {
rsvp {
peer-interface peer-name { # Configure the name of your LMP peer.
}
ospf {
area area-number {
peer-interface peer-name { # Configure the name of your LMP peer.
}
}
}
}
}
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.
[edit]
protocols {
mpls {
label-switched-path lsp-name {
from ip-address;
to ip-address;
primary path-name;
secondary path-name;
no-cspf; # This statement to disable CSPF is optional.
}
}
}
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.
[edit]
protocols {
mpls {
path path-name {
next-hop-address (strict | loose);
}
}
}
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.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.