 |
Note: If the end-to-end LSP originates on the same routing platform as the FA-LSP, you must disable CSPF and use strict paths. |
You must complete the following tasks to implement an RSVP LSP tunnel:
To begin your RSVP LSP tunnel configuration, configure LMP TE links on both the ingress and egress routing platforms. Because TE links define a unidirectional connection between peer devices, you must configure TE links in both directions between peers to enable the bidirectional transport of packets.
To configure TE links in LMP, include the te-link te-link-name statement at the [edit protocols link-management] hierarchy level. Define the TE 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 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.
- }
- }
- }
After you set up TE links, configure LMP network peers with the peer 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 TE 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 configuration will fail to commit.
- [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.
- }
- }
- }
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-name statement configured in LMP at the [edit protocols link-management peer] 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.
- }
- }
- }
- }
- }
When you configure explicit LSP paths for an FA-LSP, you must use the TE link remote address as your next-hop address. When CSPF is supported, you can use any path option you wish. However, when CSPF is disabled with the no-cspf statement at the [edit protocols mpls label-switched-path lsp-name] hierarchy level, you must use strict paths.
|
Note: If the end-to-end LSP originates on the same routing platform as the FA-LSP, you must disable CSPF and use strict paths. |
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.
- }
- }
- }
After you create the FA-LSPs and TE links, you can configure end-to-end LSPs to travel across the FA-LSPs. Here are some general guidelines for this step:
For more information about creating RSVP LSPs, see the JUNOS MPLS Applications Configuration Guide.
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. To configure, include 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.
