Setting Up RSVP-Signaled LSPs

Problem

You want to use RSVP as the signaling protocol so you can implement some of the traffic engineering features available only with RSVP, including protecting traffic links.

Solution

For each MPLS LSP, configure the ingress, transit, and egress routers on the path. On the ingress router, first configure the interface to support MPLS addressing:

[edit interfaces] aviva@R1# set so-0/0/2 unit 0 family mpls

Then enable the MPLS protocol on the interface:

[edit protocols] aviva@R1# set mpls interface so-0/0/2 aviva@R1# set mpls interface fxp0.0 disable

Finally, turn on RSVP as the signaling protocol:

[edit protocols] aviva@R1# set rsvp interface so-0/0/2

On the transit and egress routers, turn on MPLS and RSVP in a similar fashion. R6 is the egress router:

[edit interfaces] aviva@R6# set so-0/0/3 unit 0 family mpls [edit protocols] aviva@R6# set mpls interface so-0/0/3 aviva@R6# set mpls interface fxp0.0 disable aviva@R6# set rsvp interface so-0/0/3 aviva@R6# set rsvp interface fxp0.0 disable

R3 is the transit router:

[edit interfaces] aviva@R3# set so-0/0/2 unit 0 family mpls aviva@R3# set so-0/0/3 unit 0 family mpls [edit protocols] aviva@R3# set mpls interface so-0/0/2 aviva@R3# set mpls interface so-0/0/3 aviva@R3# set mpls interface fxp0.0 disable aviva@R3# set rsvp interface so-0/0/2 aviva@R3# set rsvp interface so-0/0/3 aviva@R3# set rsvp interface fxp0.0 disable

Then, on the ingress router, set up the LSP:

[edit protocols mpls] aviva@R1# set mpls label-switched-path R1-to-R6 to 10.0.0.6

Also set up a return LSP from R6 to R1 so that the LSP is bidirectional and traffic can travel from the egress router back to the ingress router:

[edit protocols] aviva@R6# set mpls label-switched-path R6-to-R1 to 10.0.0.1

Discussion

This recipe shows how to use RSVP as the signaling protocol for MPLS, based on the topology shown in Figure 14-6. Interfaces running MPLS must also be running BGP and an IGP (either IS-IS or OSPF). In this topology, all interfaces are running IS-IS and OSPF.

Figure 14-6. MPLS with RSVP topology

As with the LDP configuration, first configure the MPLS address family on the logical interfaces so the interface can process labeled packets. On the ingress router, R1, set the MPLS family on the so-0/0/2 interface. On the transit router, R3, add it to the so-0/0/2 and so-0/0/3 interfaces. On the egress router, R6, configure it on the so-0/0/3 interface. The configuration for each physical interface now has three families, IPv4 (inet), iso (for IS-IS), and MPLS:

aviva@R1> show configuration interfaces so-0/0/2 { unit 0 { family inet { address 10.1.13.1/30; } family iso; family mpls; } } fxp0 { unit 0 { family inet { address 192.168.70.143/21; } } } lo0 { unit 0 { family inet { address 10.0.0.1/32; } family iso { address 49.0004.1000.0000.0001.00; } } }

You see that on physical interface so-0/0/2 on the ingress router, the MPLS family is configured in addition to the inet and iso families. You don configure the MPLS family on either the loopback (lo0) or fxp0 interfaces because they are not transit interfaces and never carry labeled packets.

Use the show interfaces terse command to verify that the MPLS family is configured on all expected interfaces. Heres the output for the ingress router:

aviva@R1> show interfaces terse Interface Admin Link Proto Local Remote so-0/0/2 up up so-0/0/2.0 up up inet 10.1.13.1/30 iso mpls fxp0 up up fxp0.0 up up inet 192.168.70.143/21 lo0 up up lo0.0 up up inet 10.0.0.1 --> 0/0 iso 49.0004.1000.0000.0001.00 lo0.16385 up up inet inet6 fe80::2a0:a5ff:fe56:189

Heres the output for the transit router:

aviva@R3> show interfaces terse Interface Admin Link Proto Local Remote so-0/0/2 up up so-0/0/2.0 up up inet 10.1.13.2/30 iso mpls so-0/0/3 up up so-0/0/3.0 up up inet 10.1.36.1/30 iso mpls fxp0 up up fxp0.0 up up inet 192.168.70.145/21 lo0 up up lo0.0 up up inet 10.0.0.3 --> 0/0 iso 49.0002.1000.0000.0003.00 lo0.16385 up up inet inet6 fe80::2a0:a5ff:fe56:416

On both routers, you see that the MPLS family is enabled on the appropriate logical interfaces (so-0/0/2 on the ingress router, and so-0/0/2 and so-0/0/3 on the transit router). You also see that the inet and iso families are configured on these interfaces and on the routers lo0 interfaces.

Next, configure the three routers that will form the LSP to run MPLS. The basic configuration is very simple. In the [edit protocols mpls] section of the configuration hierarchy, list the router interfaces on which MPLS will run. For the ingress router, configure MPLS on the interface that leads toward the transit router in the LSP and disable MPLS on the routers fxp0 interface:

aviva@R1> show configuration protocols mpls interface so-0/0/2.0; interface fxp0.0 { disable; }

The SONET interface so-0/0/2 connects from the ingress router to the transit router. This lab setup uses M7i routers, so we disable MPLS on the fxp0 interface, which, while not required, is considered to be good practice.

After configuring the MPLS interfaces, check that MPLS is running on the interfaces. Heres the status on the ingress router:

aviva@R1> show mpls interface Interface State Administrative groups so-0/0/2.0 Up

The output shows that MPLS is up and running on interface so-0/0/2. Also, confirm MPLS status on the transit and egress routers:

aviva@R3> show mpls interface Interface State Administrative groups so-0/0/2.0 Up so-0/0/3.0 Up aviva@R6> show mpls interface Interface State Administrative groups so-0/0/3.0 Up

You see that all required MPLS interfaces are up and running.

The next step in the configuration is to set up RSVP as the signaling protocol. The basic configuration is similar to that for MPLS: you list all router interfaces that will be running RSVP. These are the same interfaces that you configured for MPLS. Use the set rsvp interface command to configure these interfaces in the [edit protocols] hierarchy. As with MPLS, do not include the lo0 and fxp0 interfaces in the list of RSVP interfaces because they do not carry labeled traffic. Also, as with MPLS, it is considered good practice to disable RSVP on the fxp0 interface. Use the following command to verify the configuration:

aviva@R1> show configuration protocols rsvp interface so-0/0/2.0; interface fxp0.0 { disable; }

The show rsvp version command shows you whether RSVP is running on the router:

aviva@R1> show rsvp version Resource ReSerVation Protocol, version 1. rfc2205 RSVP protocol = Enabled R(refresh timer) = 30 seconds K(keep multiplier) = 3 Preemption = Normal Soft-preemption cleanup = 30 seconds Graceful deletion timeout = 30 seconds Graceful restart = Disabled Restart helper mode = Enabled Maximum helper restart time = 20000 msec Maximum helper recovery time = 180000 msec Restart time = 0 msec

The first line of the output shows that the JUNOS software is running RSVP Version 1 (defined in RFC 2205). The second line shows that RSVP is enabled on the router. The remaining lines show the settings for various RSVP parameters, which are the default values because we haven configured anything other than basic RSVP functionality at this point. The refresh timer of 30 seconds determines how often RSVP sends periodic messages to its neighbors. The JUNOS software multiplies this value by 1.5 and sends RSVP messages every 45 seconds by default. The keep multiplier indicates the number of RSVP messages that can be lost on a connection before the software considers an RSVP state to be stale.

The fifth line, Preemption, shows the default session preemption type of Normal. RSVP uses preemption to accommodate additional sessions when a link does not have sufficient bandwidth to carry all sessions. Normal preemption means that only new better-priority RSVP sessions can preempt existing ones. (Recipe 14.14 explains how to modify the default preemption behavior.) Normally, sessions are torn down immediately when they are preempted. However, if soft preemption is configured, RSVP attempts for 30 seconds to establish a new session before tearing down the existing one. This is called soft-preemption cleanup. As part of tearing down an LSP, by default, RSVP waits 30 seconds to gracefully time out the session. The last five lines apply to graceful restart, which is disabled on the router.

Next, check that RSVP is up and running on the routers interfaces. Heres the output for the ingress router:

aviva@R1> show rsvp interface RSVP interface: 1 active Active Subscr- Static Available Reserved Highwater Interface State resv iption BW BW BW mark so-0/0/2.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 0bps

The second column, State, shows that RSVP is running on the so-0/0/2 interface.

Finally, you are ready to configure the LSP between R1 and R6 with the following command. On the ingress router, R1, verify the configuration:

[edit protocols mpls] aviva@R1# set label-switched-path R1-to-R6 to 10.0.0.6

Then check that the LSP is up:

aviva@R1> show mpls lsp Ingress LSP: 1 sessions To From State Rt ActivePath P LSPname 10.0.0.6 10.0.0.1 Up 1 * R1-to-R6 Total 1 displayed, Up 1, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0

The output shows one LSP, R1-to-R6, configured on R1 and that this is an ingress LSP. To verify that the LSP is up on all the routers, use the same command to check LSP status. Heres the command output on the transit router:

aviva@R3> show mpls lsp Ingress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 1 sessions To From State Rt Style Labelin Labelout LSPname 10.0.0.6 10.0.0.1 Up 1 1 FF 103488 3 R1-to-R6 Total 1 displayed, Up 1, Down 0

You see that it has one transit LSP from the ingress, 10.0.0.1, to the expected egress at 10.0.0.6. This is LSP R1-to-R6, which is the one we expect. Heres the output on the egress router:

aviva@R6> show mpls lsp Ingress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress LSP: 1 sessions To From State Rt Style Labelin Labelout LSPname 10.0.0.6 10.0.0.1 Up 0 1 FF 3 - R1-to-R6 Total 1 displayed, Up 1, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0

This output correctly shows the one LSP we have configured.

For the three routers in the LSP, the show mpls lsp output differs slightly. The P column for R1, the ingress router, contains an asterisk to indicate that LSP R1-to-R6 is the primary LSP between the two routers. The output on the transit and egress routers shows information about the RSVP reservation style and label values.

The command output for the transit router shows that received packets have a label value of 103488 and it uses a label value of 3 on the record for outgoing packets. A label value of 3 is one of the reserved values, used to request that the downstream router pop the label. The transit router is the penultimate-hop router, and the egress router has advertised a label value of 3 to R3 so that it performs penultimate-hop popping to remove the top label on the stack before forwarding packets to R6.

The Rt column in the output on all three routers shows the number of active prefixes installed in the routing table as a result of the RSVP session. Recipe 14.7 explains how to view these routes.

The extensive version of the show mpls lsp command provides additional information about the LSP, including a log of the LSPs history:

aviva@R1> show mpls lsp extensive Ingress LSP: 1 sessions 10.0.0.6 From: 10.0.0.1, State: Up, ActiveRoute: 1, LSPname: R1-to-R6 ActivePath: (primary) LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary State: Up Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20) 10.1.13.2 S 10.1.36.2 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt): 10.1.13.2 10.1.36.2 5 Oct 4 13:31:06 Selected as active path 4 Oct 4 13:31:06 Record Route: 10.1.13.2 10.1.36.2 3 Oct 4 13:31:06 Up 2 Oct 4 13:31:06 Originate Call 1 Oct 4 13:31:06 CSPF: computation result accepted Created: Tue Oct 4 13:31:05 2005 Total 1 displayed, Up 1, Down 0

This command works only on the ingress router because this router is responsible for establishing and maintaining the LSP. The transit and egress routers have no details about the LSPs state. The first line of the output confirms what we already know about the LSP: that it is named R1-to-R6, runs from 10.0.0.1 to 10.0.0.6, and is up. The highlighted lines show the history of the LSP, from most current to oldest events. The last line in the log tells you that the LSP was created at 13:31:05. RSVP used CSPF to determine a path for the LSP (this is the default JUNOS RSVP behavior), and by 13:31:06 the LSP was up and running and was selected as the active path. Consult the LSPs log to help determine the causes of MPLS errors in the network.

You may be wondering why RSVP is using CSPF when setting up the LSP when we haven included anything about turning on CSPF in the configuration. By default, JUNOS RSVP uses CSPF to calculate paths. The data that RSVP uses for the CSPF calculation comes from an IGP, either IS-IS or OSPF. Extensions to both protocols allow them to collect information about the network topology and available bandwidth on network links. The JUNOS implementations of both IGPs support the extensions. This network data for CSPF is stored in a TED on each router. In the JUNOS IS-IS software, these extensions are on by default. Because IS-IS is running as one of the IGPs in our network, it automatically carries the traffic-engineering information. Heres how you can disable the IS-IS support for TE:

[edit protocols isis] aviva@R1# set traffic-engineering disable

In the JUNOS OSPF, the extensions are off by default. You must explicitly configure OSPF support of the CSPF computation:

[edit protocols ospf] aviva@R1# set traffic-engineering

Use the following command to see what information IS-IS and OSPF have added to the TED database:

aviva@R1> show ted database TED database: 3 ISIS nodes 3 INET nodes ID Type Age(s) LnkIn LnkOut Protocol R1.00(10.0.0.1) Rtr 239 1 1 IS-IS(2) To: R3.00(10.0.0.3), Local: 10.1.13.1, Remote: 10.1.13.2 ID Type Age(s) LnkIn LnkOut Protocol OSPF(0.0.0.0) To: R3.00(10.0.0.3), Local: 10.1.13.1, Remote: 10.1.13.2 ID Type Age(s) LnkIn LnkOut Protocol R3.00(10.0.0.3) Rtr 468 2 2 IS-IS(2) To: R1.00(10.0.0.1), Local: 10.1.13.2, Remote: 10.1.13.1 To: R6.00(10.0.0.6), Local: 10.1.36.1, Remote: 10.1.36.2 ID Type Age(s) LnkIn LnkOut Protocol R6.00(10.0.0.6) Rtr 431 1 1 IS-IS(2) To: R3.00(10.0.0.3), Local: 10.1.36.2, Remote: 10.1.36.1

This output shows three entries and that both IS-IS and OSPF are contributing to the TED database (listed in the Protocol column). All three entries were learned from routers (shown in the Type column). You see that R1 (the ingress router) has one link in and one link out, R2 (the transit router) has two links in either direction, and R3 (the egress router) has one link in and one out, which matches the LSP. The To: lines show the router IDs that correspond to the three routers in the LSP.

The extensive version of this command shows additional information about reservable and available bandwidth on networks links that IS-IS and OSPF have collected for use by CSPF:

aviva@R1> show ted database 10.0.0.1 extensive TED database: 3 ISIS nodes 3 INET nodes NodeID: R1.00(10.0.0.1) Type: Rtr, Age: 621 secs, LinkIn: 1, LinkOut: 1 Protocol: IS-IS(2) To: R3.00(10.0.0.3), Local: 10.1.13.1, Remote: 10.1.13.2 Color: 0 Metric: 10 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 Protocol: OSPF(0.0.0.0) To: R3.00(10.0.0.3), Local: 10.1.13.1, Remote: 10.1.13.2 Color: 0 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

The last step in setting up the RSVP-signaled LSP is to create a return LSP from R6 to R1 on router R6:

[edit protocols mpls] aviva@R6# set label-switched-path R6-to-R1 to 10.0.0.1

To confirm the configuration, use the show mpls lsp command on R6:

aviva@R6> show mpls lsp Ingress LSP: 1 sessions To From State Rt ActivePath P LSPname 10.0.0.1 10.0.0.6 Up 1 * R6-to-R1 Total 1 displayed, Up 1, Down 0 Egress LSP: 1 sessions To From State Rt Style Labelin Labelout LSPname 10.0.0.6 10.0.0.1 Up 0 1 FF 3 - R1-to-R6 Total 1 displayed, Up 1, Down 0

You see that R6 now has both an ingress and egress LSP session. R1, the router at the far end of the LSP, also has two similar LSP sessions, and R3, the router in the middle, has two transit sessions:

aviva@R3> show mpls lsp Transit LSP: 2 sessions To From State Rt Style Labelin Labelout LSPname 10.0.0.1 10.0.0.6 Up 1 1 FF 103504 3 R6-to-R1 10.0.0.6 10.0.0.1 Up 1 1 FF 103488 3 R1-to-R6 Total 2 displayed, Up 2, Down 0

This output shows that R3 is using two different labels for the two LSPs, which is what you expect because the two traffic flows are separate.

Another way to verify that the RSVP-signaled LSP is up is to examine the RSVP session. Lets look at R1, the ingress router for the R1-to-R6 LSP:

aviva@R1> show rsvp session detail Ingress RSVP: 1 sessions 10.0.0.6 From: 10.0.0.1, LSPstate: Up, ActiveRoute: 1 LSPname: R1-to-R6, LSPpath: Primary Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 103536 Resv style: 1 FF, Label in: -, Label out: 103536 Time left: -, Since: Tue Oct 4 14:36:13 2005 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 2 receiver 12077 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 10.1.13.2 (so-0/0/2.0) 1886 pkts RESV rcvfrom: 10.1.13.2 (so-0/0/2.0) 1894 pkts Explct route: 10.1.13.2 10.1.36.2 Record route: 10.1.13.2 10.1.36.2 Total 1 displayed, Up 1, Down 0 Egress RSVP: 1 sessions 10.0.0.1 From: 10.0.0.6, LSPstate: Up, ActiveRoute: 0 LSPname: R6-to-R1, LSPpath: Primary Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: - Resv style: 1 FF, Label in: 3, Label out: - Time left: 119, Since: Tue Oct 4 14:35:46 2005 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 49792 protocol 0 PATH rcvfrom: 10.1.13.2 (so-0/0/2.0) 1886 pkts Adspec: received MTU 1500 PATH sentto: localclient RESV rcvfrom: localclient Record route: 10.1.36.2 10.1.13.2 Total 1 displayed, Up 1, Down 0

The ingress router now has two RSVP sessions. The first two lines of the output for each session confirm the head and tail ends of the RSVP sessions, the LSP pathname, and that the LSP is operational. For the first session, from 10.0.0.1 to 10.0.0.6, R1 is the ingress router and the output shows that RSVP is using label 103536 on outgoing packets. Check the transit router to confirm that it is receiving this label:

aviva@R3> show rsvp session detail name R1-to-R6 Transit LSP: 2 sessions 10.0.0.6 From: 10.0.0.1, LSPstate: Up, ActiveRoute: 1 LSPname: R1-to-R6, LSPpath: Primary Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 3 Resv style: 1 FF, Label in: 103536, Label out: 3 Time left: 157, Since: Tue Oct 4 14:15:42 2005 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 2 receiver 12077 protocol 0 PATH rcvfrom: 10.1.13.1 (so-0/0/2.0) 1904 pkts Adspec: received MTU 1500 sent MTU 1500 PATH sentto: 10.1.36.2 (so-0/0/3.0) 1908 pkts RESV rcvfrom: 10.1.36.2 (so-0/0/3.0) 1904 pkts Explct route: 10.1.36.2 Record route: 10.1.13.1 10.1.36.2 Total 1 displayed, Up 1, Down 0

Back to the output for R1, the Record route field shows the route being used for this session as reported in the RSVP RRO:

Record route: 10.1.13.2 10.1.36.2

The RSVP session starts at , which is the local router, then proceeds through 10.1.31.2 to the egress router at 10.1.36.2. This matches the LSP illustrated in Figure 14-6. The record route on the transit router shows the following:

Record route: 10.1.13.1 10.1.36.2

Here, the transit router, , is placed between the ingress and egress routers, which again matches the network topology.

See Also

Recipes 14.7 and 14.14

Категории