We’ve spent a great deal of time in the last few posts talking about MPLS both with LDP and with static LSP configurations. While these approaches certainly work, they aren’t the only options to use for label distribution and LSP creation. If we take static LSPs off the table (since they’re the equivalent of static routes and not scalable) we really have two main choices for label distribution – LDP and RSVP. LDP is typically considered to be the easiest of the two options but also offers a limited set of functionality. RSVP offers many more features but also requires more configuration. When you’re designing an MPLS network you’ll have to decide which protocol to use based on your requirements. In many cases a network may leverage both in different areas. In this post the aim is just to get RSVP up and running – we’ll dig into the specifics in a later post.
So let’s get right into a simple lab where we leverage RSVP instead of LDP. Like the previous post, we’ll leverage the same lab environment…
Let’s assume as before that the base configuration of the lab includes all the routers interfaces configured, OSPF enabled on all of the router to router interfaces, and a BGP peering in AS 65000 existing between vMX1 and vMX4. To configure RSVP we do the same thing we did with LDP – we enable the interfaces for RSVP and MPLS…
vMX1 Configuration…
set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family mpls
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
vMX2 Configuration…
set interfaces ge-0/0/0 unit 0 family mpls
set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family mpls
set protocols rsvp interface ge-0/0/0.0
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols mpls interface ge-0/0/0.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
vMX3 Configuration…
set interfaces ge-0/0/0 unit 0 family mpls
set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family mpls
set protocols rsvp interface ge-0/0/0.0
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols mpls interface ge-0/0/0.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
vMX4 Configuration…
set interfaces ge-0/0/0 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family mpls
set protocols rsvp interface ge-0/0/0.0
set protocols rsvp interface ge-0/0/2.0
set protocols mpls interface ge-0/0/0.0
set protocols mpls interface ge-0/0/2.0
Alright – at this point – we have our base configuration in place. If we check things out, we can see that RSVP has found neighbors. If we look at vMX2 we can see it has peers with all of the other vMX…
[email protected]> show rsvp neighbor
RSVP neighbor: 3 learned
Address Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd
10.1.1.0 0 1/0 1:46 9 13/12 0
10.1.1.3 0 1/0 1:22 9 13/10 0
10.1.1.7 0 1/0 39 9 13/5 0
[email protected]> show route table inet.3
[email protected]>
Note that the inet.3 table is empty. RSVP does not automatically advertise FECs like LDP does. Remember that in most cases, the FECs we’re dealing with are the routers loopback addresses. Since the FECs are not automagically advertised – RSVP is said to operate in “Downstream on Demand” label distribution mode. LDP on the other hand is said to operate in “Downstream Unsolicited” mode since it sends the labels regardless of being asked for them.
Note: A good example of this is looking at the inet.3 table after we had configured the same lab with LDP. In that case, you would have seen all of the router loopback addresses as soon as LDP had converged. With RSVP – we won’t see the entry in ght inet.3 table until and LSP is manually created.
So since the FECs arent automatically created for us – how do we go about creating them? Simple, we define label switched paths. Let’s create an LSP from vMX1 to vMX4…
set protocols mpls label-switched-path vmx1-vmx4 to 4.4.4.4
That’s all we need to do in order to define a LSP on vMX1. To look at the status of the LSP, we can use the show mpls lsp command…
[email protected]> show mpls lsp
Ingress LSP: 1 sessions
To From State Rt P ActivePath LSPname
4.4.4.4 0.0.0.0 Dn 0 - vmx1-vmx4
Total 1 displayed, Up 0, Down 1
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
[email protected]>
That doesn’t look good. It would appear that the LSP is down. The reason the LSP is down is because we haven’t enabled a means for the RSVP communication to work. RSVP works by sending messages through the traffic engineering (TE) extensions added on to the IGPs. IGPs like IS-IS automatically have the TE extensions enabled but others (like OSPF) don’t. In order for the TE extensions to be be enabled we need to tell OSPF to use them. We need to enable this on all of the routers using this command…
set protocols ospf traffic-engineering
Once enabled on all of the routers, you should see the LSP change state…
[email protected]> show mpls lsp
Ingress LSP: 1 sessions
To From State Rt P ActivePath LSPname
4.4.4.4 1.1.1.1 Up 0 * vmx1-vmx4
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
[email protected]>
Nice! So looks like our LSP is up. However at this point – the top client still can not reach the bottom client. Why is that? Recall that LSPs are directional. So while we’ve enabled the flow from vMX1 to vMX4 – the reverse path still has no way to go. Well – I take that back – the reverse path has a route – it just happens to point at vMX2 and vMX4 who have no working knowledge of the 10.2.2.0/31 prefix so they’ll just drop it. Let’s make sure that things are working in one direction by performing a packet capture on the traffic before it get’s to vMX4. Since there are multiple paths to reach vMX4, we need to figure out which one vMX1 is using….
[email protected]> show route table inet.0 10.2.2.2/31
inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.2.2.2/31 *[BGP/170] 19:41:48, localpref 100, from 4.4.4.4
AS path: I, validation-state: unverified
> to 10.1.1.9 via ge-0/0/2.0, label-switched-path vmx1-vmx4
[email protected]>
So we can see that the route to 10.2.2.2/31is present and has a next hop listed of 10.1.1.9 heading through the LSP vmx1-vmx4. But wait a minute – isn’t 4.4.4.4 reachable both from vMX2 and vMX3? So why is the LSP only picking one path? The simple answer is that RSVP prefers (needs) stability. We’ll talk about this in greater detail in later posts, but for now we can summarize and say that RSVP will take a single path for each LSP defined. If you want to leverage multiple paths to reach 10.2.2.2/31 you’d need multiple LSPs.
Let’s spend a few minutes talking about how RSVP establishes a LSP. When you request an LSP to be setup on a router – that router calculates a path to the LSP egress router. The ingress router (the one you’re configuring) is typically called the headend router and the egress LSP router is referred to as the tailend router. In our case, vMX1 is the headend router and vMX4 is the tailend router. vMX1 will generate what’s referred to as a “PATH” message with a destination of the tailend router. This is where things get interesting. Most of the blogs/articles you read (this for example) will tell you that the headend router sends a message direct to the tailend router and relies on routers in the path to inspect the path message because it has the router alert flag set. When I looked at this and did captures I saw RSVP “bundled” messages coming through. Bundling is described in great detail in RFC2961 and it drastically changes the way that RSVP messages are sent making them more point to point and not relying on router alert to have in path nodes inspect them. Suffice to say – the headend router is sending a request along it’s best path to reach the LSP endpoint. Each router along the way sees this PATH message and, if required, allocates resources or reservations per the request. Once the tailend router receives the PATH message sent by the headend router it will allocate a label to use for the LSP and sends that back toward the headend using a RESV (reservation) message. When the next router in the reverse path receives the RESV packet sent by the tailend, it records the label and then sends it’s own RESV packet to the next router in the reverse with it’s own label. This pattern continues all the way to the headend router. Let’s pull some captures of this process occurring. Based on the information above, we can assume that the PATH packets are taking the path from vMX1 -> vMX3 and then vMX3 -> vMX4 (this last path is assumed but it’s directly connected at that point). So let’s capture this process on those links to see the LSP being stood up…
Note: You’ll want to click on the images below to open them in a new tab. The default sizing and resolution isn’t super awesome.
Frame vMX1 -> vMX3
Frame vMX3 -> vMX4
The above two captures show the bundled PATH messages being sent first from vMX1 to vMX3 and then again from vMX3 to vMX4. Notice that the LSP ID is set to 1 in both cases and that the final destination is clearly called out as being 4.4.4.4. Now let’s look at the RESV requests that should take the reverse path back to vMX1…
Frame vMX4 -> vMX3
Frame vMX3 -> vMX1
Nice! So the RESV messages have told each router what to use to reach the LSP endpoint. vMX4 told vMX3 to use label 3 (for PHP) and vMX3 told vMX1 to use 299872. We can confirm this by looking at the vMX…
[email protected]> show route table inet.0 10.2.2.2/31 extensive
inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
10.2.2.2/31 (1 entry, 1 announced)
TSI:
KRT in-kernel 10.2.2.2/31 -> {indirect(1048575)}
*BGP Preference: 170/-101
Next hop type: Indirect, Next hop index: 0
Address: 0xd0071b0
Next-hop reference count: 2
Source: 4.4.4.4
Next hop type: Router, Next hop index: 586
Next hop: 10.1.1.9 via ge-0/0/2.0, selected
Label-switched-path vmx1-vmx4
Label operation: Push 299872
Label TTL action: prop-ttl
Load balance label: Label 299872: None;
Label element ptr: 0xd0078c0
Label parent element ptr: 0x0
Label element references: 2
Label element child references: 0
Label element lsp id: 19
Session Id: 0x140
Protocol next hop: 4.4.4.4
Indirect next hop: 0xb68cca0 1048575 INH Session ID: 0x142
State: <Active Int Ext>
Local AS: 65000 Peer AS: 65000
Age: 20:00:22 Metric2: 2
Validation State: unverified
Task: BGP_65000.4.4.4.4+53485
Announcement bits (2): 0-KRT 5-Resolve tree 1
AS path: I
Accepted
Localpref: 100
Router ID: 4.4.4.4
Indirect next hops: 1
Protocol next hop: 4.4.4.4 Metric: 2
Indirect next hop: 0xb68cca0 1048575 INH Session ID: 0x142
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.1.1.9 via ge-0/0/2.0
Session Id: 0x140
4.4.4.4/32 Originating RIB: inet.3
Metric: 2 Node path count: 1
Forwarding nexthops: 1
Nexthop: 10.1.1.9 via ge-0/0/2.0
Session Id: 140
[email protected]>
Of course – we need to use the extensive output to see the label – but you can see in the output Label operation: Push 299872 which aligns with what we saw in the captures.
So after that long tangent – let’s get back to our initial problem – we only have a one way LSP. Let’s validate that by capturing the traffic on the link between vMX1 and vMX3…
20:49:22.417716 52:de:52:ef:01:03 > 52:de:52:ef:03:03, ethertype MPLS unicast (0x8847), length 102: MPLS (label 299872, exp 0, [S], ttl 63) 10.2.2.1 > 10.2.2.3: ICMP echo request, id 12769, seq 395, length 64
20:49:23.417766 52:de:52:ef:01:03 > 52:de:52:ef:03:03, ethertype MPLS unicast (0x8847), length 102: MPLS (label 299872, exp 0, [S], ttl 63) 10.2.2.1 > 10.2.2.3: ICMP echo request, id 12769, seq 396, length 64
20:49:24.417770 52:de:52:ef:01:03 > 52:de:52:ef:03:03, ethertype MPLS unicast (0x8847), length 102: MPLS (label 299872, exp 0, [S], ttl 63) 10.2.2.1 > 10.2.2.3: ICMP echo request, id 12769, seq 397, length 64
20:49:25.417662 52:de:52:ef:01:03 > 52:de:52:ef:03:03, ethertype MPLS unicast (0x8847), length 102: MPLS (label 299872, exp 0, [S], ttl 63) 10.2.2.1 > 10.2.2.3: ICMP echo request, id 12769, seq 398, length 64
As we expected (even with the right label!) we only have one way traffic flow. To resolve this – we need to configure a LSP from vMX4 to vMX1 on vMX4…
set protocols mpls label-switched-path vmx4-vmx1 to 1.1.1.1
Once this is configured, our pings should start working. Let’s check the routing table on vMX4…
[email protected]> show route table inet.0 10.2.2.0/31
inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.2.2.0/31 *[BGP/170] 00:04:00, localpref 100, from 1.1.1.1
AS path: I, validation-state: unverified
> to 10.1.1.6 via ge-0/0/2.0, label-switched-path vmx4-vmx1
[email protected]>
Interesting – so the return LSP is taking a different path. So our traffic flow really looks like this…
Since both routers have equal cost paths to reach their respective LSP endpoint, the LSP could have been formed on either path. It just so happened in the above example that the routers chose different IGP paths.
So at this point – it may appear to you that RSVP isn’t as great as LDP was. It requires manual configuration and it can’t inherently allow for ECMP type traffic flows across the routers. I assure you – there’s good reason for this though and in the next blog we’ll start talking about with RSVP is considered to be a much better alternative to LDP.
Great article!
As always, well explained and detailed, step-by-step and easy to understand
Thank you!