Practical Applications: Signaling Different Types of RSVP-TE Paths | Rick Gallahers MPLS Training Guide: Building Multi Protocol Label Switching Networks

< Day Day Up >

The command syntax may look complex, but adding RSVP is as simple as adding LDP. The important thing to note here is that LDP and RSVP cannot run on the same interface.

In Chapter 2, Figure 2.15, we completed steps of defining interfaces, adding OSPF, and adding MPLS to the interfaces. We completed the commands by adding LDP in Figure 2.16.

Instead of adding LDP now, we are going to add RSVP. We accomplish this by the following simple steps:

Create the path.
Add RSVP to each interface.
Start RSVP.

Riverstone graciously provided the following demonstrations as an example of RSVP setup.

Extending RSVP for MPLS Networks

Standards track protocol defined by RFC 3209, 'RSVP-TE: Extensions to RSVP for LSP Tunnels.' The Applicability statement for RSVP-TE is described by RFC 3210.

Signaling a Path Using RSVP-TE

RSVP-TE can be used to signal nd explicit paths through an MPLS network. Once the network is MPLS ready and the link state routing protocol has been deployed, with or without traffic engineering extensions, a dynamically signaled LSP can be established by simply configuring the instantiating router. Traffic engineering can be applied to either of these signaling approaches. Creating an RSVP path through a network is a rather simple process.

Hop by Hop

The hop-by-hop method determines a path through the network based on the interior gateway protocol's view of the network. If no constraints are applied to the LSP, the instantiating router simply sends the request for a path to the active next hop for that destination, with no explicit routing. The IGP at each router is free to select active next hops based on the link state database. In the event of path failure, such as a link failure somewhere in the network, the hop-by-hop method will eventually establish a path around the failure based on updated link state database information. Reoptimization is under development on the RS platform.

To create a simple hop-by-hop path, use the command shown in Figure 3.12. More specific commands are shown in Figures 3.13 and 3.14. In this example, we continue to build upon the network that we created in Chapter 2. After reviewing the previously covered commands in Figure 3.14, we go on to build the network one step at a time by adding MPLS and RSVP to the path (see Figure 3.15).

Figure 3.12: Simple RSVP Command Overview

Figure 3.13: RSVP Path Request

Figure 3.14: Previously Covered Commands

Figure 3.15: Show LSP ALL

The sample network in Figure 3.13 shows how an instantiating router requests a hop-by-hop, end-to-end RSVP path through the MPLS network to a destination, without any constraints or resource requirements.

The northernmost router represented the active next hop for the destination, and the instantiating router followed the information in the forwarding information base and sent the RSVP request to the active next hop indicated in the FIB. The result: The IGP used the shortest path between the edge routers over which to signal and establish the path.

RSVP Hop-by-Hop Show Commands

Figure 3.15 represents an MPLS show label-switched-path command detail. This command is used to display high-level LSP information, including start and end points, state, and labels used.

A more detailed view of the LSP information can be found using the verbose option, as shown in Figure 3.16. This includes the various session attributes for the LSP and the associated path information. The path information includes path attributes, labels associated with the LSP, timers, resource constraints, and the confirmation the path the LSP has taken through the MPLS network (record-route).

Figure 3.16: Show LSP Verbose

The same display commands can be used on the transit router for this LSP. Remember, an outbound label 3 indicates penultimate hop pop is performed on the router preceding the last router in the LSP. When this is done, the router makes a forwarding decision based on the inbound label sending it to the next hop without applying a new upper-level label on the outbound.

Explicit Route Objects

The hop-by-hop method allows the IGP to select the path through the network. However, many benefits can be realized by having the instantiating router dictate the hops an LSP will traverse. The explicit route object (ERO) is the creation and inclusion of the list of routers that comprise the most suitable path through the MPLS network. This is analogous to the source routing, where the instantiating router dictates, either in whole or in part, the path through the network.

The ERO object may contain two kinds of explicit routes: strict or loose hops. A strict hop indicates that the two nodes must be adjacent to one another, with no intermediate hops separating them. A loose hop indicates that the nodes do not have to be adjacent to each other and the IGP can be used to determine the best path to the loose hop. This allows the router building the ERO to apply some abstract level of configuration, indicating that the path needs to traverse a particular router without dictating how to reach that hop. By default, any hop specified as part of the ERO is strict unless otherwise configured as loose. Information contained in the ERO is stored in the path state block for each router. Currently, implementations on the RS platform support loose and strict routing in the form of IP addresses.

The Internet draft defines the fields of the ERO subobject as shown in Figure 3.17 and described in the following list.

Figure 3.17: ERO Subobject Fields

L: The disposition of the particular hop. A value of 0 indicates the subobject is strict. This is the default if the configuration omits the Type field for this hop. A value of 1 indicates the type of this hop is loose.

Type: A seven-bit field indicating the value of the subobject's contents (see Figure 3.18). The draft currently defines four reserved values. Of these, Riverstone supports IP addressing.

Figure 3.18: Four Reserved Values

Autonomous systemLength: An 8-bit field that represents the number of bytes for the entire subobject, inclusive of all fields.

Subobject Contents: The addressing information specific to the type. A minimum of 2 bytes represents the smallest possible type field, AS Number.

Configuring an explicit route on the RS platform is done by creating a path with a specified number of hops, defining those hops with their disposition, strict or loose, and associating that path to an LSP as primary or secondary.

Note: If the path is created without specifying any number of hops, the interior gateway protocol determines the active next hop for the destination and sends the request to that node. It is equivalent to creating a hop-by-hop path, with no explicit route.

To create the path with an explicit route:

 RS(config)# mpls create path <name> num-hops <number>

To define the hops for a created path:

 RS(config)# mpls set path <name> hop <number> ip-addr <ip-address> type <strict|loose>

Associating a path to an LSP:

 RS(config)# mpls set label-switched-path <name> primary|secondary <path name>

A Strict Routing Example

Here we configure a completely strict route from ingress (LER1) to egress (LER2). An overview of this network is shown in Figure 3.19.Figure 3.20 shows the commands in standalone detail. Notice how every router must be specified and that the routing is strict. Note: The items in bold are replacement items for RSVP or LDP commands.

Figure 3.19: Unique RSVP Strict Path Commands

Figure 3.20: Unique RSVP Strict Path Commands

The resulting subobjects of the ERO would look like this:

L=0;Type=4;Length=64;Contents=192.168.1.6 (instantiating router interface) L=0;Type=4;Length=64;Contents=192.168.1.5 L=0;Type=4;Length=64;Contents=192.168.1.26 L=0;Type=4;Length=64;Contents=192.168.1.22

Explicit route data is logged in the 'explicit-path' field of LDP information.

LER1# mpls show label-switched-paths all verbose  Ingress LSP:     Label-Switched-Path: "LSP"     state: Up       lsp-id: 0x9     status: Success     to: 2.2.2.2      from: 2.2.2.1         proto: <rsvp>     protection: primary     setup-pri: 7      hold-pri: 0     attributes: <FROM_ADDR PRI>       Protection-Path "ERO-Path1": <Active, Primary>       state: Up     lsp-id: 0x4002       status: Success       attributes: <>       inherited-attributes: <>     Path-Signaling-Parameters:       attributes: <>       inherited-attributes: <NO-CSPF>       label in:     label out: 17       retry-limit: 5000 retry-int: 15 sec.       retry-count: 5000 next_retry_int: 0.000000 sec.       preference: 7   metric: 1       ott-index: 1    ref-count: 1                  bps: 0       mtu: 1500       hop-limit: 255   opt-int: 600 sec.       explicit-path: "ERO-Path1" num-hops: 4         192.168.1.6  - strict         192.168.1.5  - strict         192.168.1.26  - strict         192.168.1.22  - strict       record-route:          192.168.1.5         192.168.1.26         192.168.1.22   Transit LSP:   Egress LSP:

This example demonstrates a slightly different approach, using loose hops and the loopback interfaces on the routers instead of physical interface addressing. In this example, all traffic is forced through a single router, LSR3, by coding one of the loose hops to be the IP address of that router's loopback interface. Also notice that the first hop and last hop are actually the tunnel end points. In essence, the path can be established across any links as long as one of the transit nodes is LSR3. This provides a certain level of link failure protection but still leaves the single point of failure, should LSR3 become unusable. Loose and strict routes may be combined in a path message, allowing for the description of a path that must pass through some hops in an specific point-to-point fashion (strict) while other parts of the path may be derived by the IGP (loose). In Figures 3.19 and 3.20, we saw an example of strict RSVP. Notice how this has changed to loose routing in Figures 3.21 and 3.22

Figure 3.21: RSVP Loose Routing (View 1)

Figure 3.22: RSVP with Loose Routing (View 2)

interface create ip To-LSR1 address-netmask 192.168.1.2/30 port gi.2.1 interface create ip To-LSR2 address-netmask 192.168.1.6/30 port gi.2.2 interface add ip lo0 address-netmask 2.2.2.1/32 ip-router global set router-id 2.2.2.1 ospf create area backbone ospf add interface To-LSR1 to-area backbone ospf add interface To-LSR2 to-area backbone ospf add stub-host 2.2.2.1 to-area backbone cost 10 ospf start mpls add interface To-LSR1 mpls add interface To-LSR2 mpls create path To-LER2-Prime num-hops 3 mpls set path To-LER2-Prime hop 1 ip-addr 2.2.2.1 type strict mpls set path To-LER2-Prime hop 2 ip-addr 1.1.1.3 type loose mpls set path To-LER2-Prime hop 3 ip-addr 2.2.2.2 type loose mpls create label-switched-path To-LER2-1 from 2.2.2.1 to 2.2.2.2 no-cspf mpls set label-switched-path To-LER2-1 primary To-LER2-Prime    mpls start rsvp add interface To-LSR1 rsvp add interface To-LSR2 rsvp start ospf set traffic-engineering on

The resulting subobjects of the ERO would look like this:

L=0;Type=4;Length=64;Contents=2.2.2.1 (instantiating router interface) L=1;Type=4;Length=64;Contents=1.1.1.1 L=1;Type=4;Length=64;Contents=2.2.2.2

Looking at the LSP information reveals the differences between the two approaches. The completely strict explicit route was a kind of 'this way or no way' approach to signaling and establishing the LSP. If any node or link specified in the explicit path failed, that path statement would fail the LSP. The loose approach provides slightly more resilience at the expense of complete control. Should the path be established and a node or link that the LSP was using fail, the instantiating router would determine a new path through the network, signal, and establish it.

LER1# mpls show label-switched-paths all verbose  Ingress LSP:     Label-Switched-Path: "LSP"     state: Up       lsp-id: 0x9     status: Success     to: 2.2.2.2      from: 2.2.2.1         proto: <rsvp>     protection: primary     setup-pri: 7      hold-pri: 0     attributes: <FROM_ADDR PRI>       Protection-Path "ERO-Path1": <Active, Primary>       state: Up     lsp-id: 0x4003       status: Success       attributes: <>       inherited-attributes: <>     Path-Signaling-Parameters:       attributes: <>       inherited-attributes: <NO-CSPF>       label in:     label out: 17       retry-limit: 5000 retry-int: 15 sec.       retry-count: 5000 next_retry_int: 0.000000 sec.       preference: 7   metric: 1       ott-index: 1    ref-count: 1                  bps: 0       mtu: 1500       hop-limit: 255   opt-int: 600 sec.       explicit-path: "ERO-Path1" num-hops: 3         2.2.2.1    - strict         1.1.1.3    - loose         2.2.2.2    - loose       record-route:          192.168.1.1         192.168.1.14         192.168.1.22   Transit LSP:   Egress LSP:

The actual explicit route object is built using a combination of the IGP forwarding table and the manually configured hops. For example, the first hop in the path was derived from the forwarding table based on the next best hop for the loose route of 1.1.1.3. Similarly, the next best hop from 1.1.1.3 to 2.2.2.2 was also determined from the routing table. Configuration 1 is shown in Figure 3.23.

Figure 3.23: Configuration Example 1

Assuming there was a failure, as long as the loopback interfaces specified as part of the ERO are reachable, the IGP will converge and the path will be established across an alternate set of transit routers. An example is presented in Figure 3.25, Configuration 2.

Figure 3.24: Configuration Example 2

LER1# mpls show label-switched-paths all verbose  Ingress LSP:     Label-Switched-Path: "LSP"     state: Up       lsp-id: 0x9     status: Success     to: 2.2.2.2      from: 2.2.2.1         proto: <rsvp>     protection: primary     setup-pri: 7      hold-pri: 0     attributes: <FROM_ADDR PRI>       Protection-Path "ERO-Path1": <Active, Primary>       state: Up     lsp-id: 0x4003       status: Success       attributes: <>       inherited-attributes: <>     Path-Signalling-Parameters:       attributes: <>       inherited-attributes: <NO-CSPF>       label in:     label out: 17       retry-limit: 5000 retry-int: 15 sec.       retry-count: 5000 next_retry_int: 0.000000 sec.       preference: 7   metric: 1       ott-index: 1    ref-count: 1                  bps: 0       mtu: 1500       hop-limit: 255   opt-int: 600 sec.       explicit-path: "ERO-Path1" num-hops: 3         2.2.2.1    - strict         1.1.1.3    - loose         2.2.2.2    - loose       record-route:          192.168.1.5         192.168.1.26         192.168.1.22     Transit LSP:   Egress LSP:

< Day Day Up >