In our last post we covered the basics of getting an RSVP LSP setup. This was a tedious process at least when compared to what we saw with LDP setting up LSPs. So I think it’s worthwhile to spend some time talking about RSVP and what it offers that merit it’s consideration as a label distribution protocol. First off – let’s talk about naming. When talking about MPLS – RSVP is typically just called RSVP – but without the MPLS context – it might be a little confusing. That’s because RSVP itself initially had nothing to do with MPLS. RSVP was initially a means to reserve resources for flows across a network. The protocol was then extended to support setting up MPLS LSPs. In this use case, it is often referred to as “RSVP-TE” or “MPLS RSVP-TE”. For the sake of my sanity – when I reference RSVP going forward I’ll be referring to RSVP that’s used to setup MPLS LSPs.
So now let’s talk about some differences between LDP and RSVP. The first thing that everyone points out is that LDP is tightly bound to the underlying IGP. While this is an accurate statement, it doesn’t mean that RSVP isn’t. As we saw in our last post – the LSPs that got setup by RSVP did in fact follow the IGP to reach the to address defined in our LSP definitions. So at it’s core – obviously both rely heavily on the underlying routing information to build LSPs. RSVP extends this by allowing the definition of what are referred to as Explicit Route Objects (EROs). At it’s most basic level – and ERO describes which LSRs (Label Switched Routers) a given LSP should traverse. Since in our last post, we didn’t have any EROs defined, we saw that the routers used the IGP to build an end to end LSP based on our input criteria which happened to be the router endpoint for the LSP. EROs fall into two distinct categories. Loose hops and strict hops. Let’s talk about them individually and show an example of each in our lab.
Note: We’ll be using the lab where we left off from the last post.
Loose hop EROs mean that we tell the router that traffic has to traverse a particular LSR, but we don’t really tell it how to do that. For instance, if we pick our lab up where we left off last time, we had an LSP defined from vMX1 to vMX4. The only definition we provided was using the to parameter which ,as we discussed, lets RSVP use the IGP to pick a single best path. So in our case, the LSP vmx1-vmx4 happened to chose the path down to vMX3 and over to vMX4. We can see that by looking at the routing table for the bottom user prefix…
[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] 1w0d 17:10:04, 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]>
Let’s now change the configuration slightly to include a loose path…
set protocols mpls path loose-vmx1-vmx4 2.2.2.2 loose
The first step in configuring an ERO is to define a path. This is done under the MPLS protocol stanza and consists of a name for the path and a possible strict or loose hop. In this case, we defined the path called loose-vmx1-vmx4 with a loose hop of 2.2.2.2. The next thing we need to do is tell the LSP we had previously defined to use this path…
set protocols mpls label-switched-path vmx1-vmx4 primary loose-vmx1-vmx4
That’s it! Once committed we can look at the routing table again…
[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] 1w0d 17:17:09, localpref 100, from 4.4.4.4
AS path: I, validation-state: unverified
> to 10.1.1.1 via ge-0/0/1.0, label-switched-path vmx1-vmx4
[email protected]>
Notice how the router’s next hop is 10.1.1.1 which is the next hop to reach vMX2. If we look on vMX2 we should see that vMX2 still thinks that it’s best path to the LSP endpoint (4.4.4.4) is over it’s directly connected link…
[email protected]> show route table inet.0 4.4.4.4/32
inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
4.4.4.4/32 *[OSPF/10] 1w0d 17:24:42, metric 1
> to 10.1.1.7 via ge-0/0/2.0
[email protected]>
So this makes sense. and our paths now look like this…
So what if we also request that the LSP traverse vMX3?…
set protocols mpls path loose-vmx1-vmx4 3.3.3.3 loose
Note that this is adding another ERO to the existing criteria, we aren’t overwriting the last one with this one…
path loose-vmx1-vmx4 {
2.2.2.2 loose;
3.3.3.3 loose;
}
So now let’s look at our route output on vMX1 again…
[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] 1w0d 17:30:56, localpref 100, from 4.4.4.4
AS path: I, validation-state: unverified
> to 10.1.1.1 via ge-0/0/1.0, label-switched-path vmx1-vmx4
[email protected]>
So nothing changed here, let’s check vMX2 again…
[email protected]> show route table inet.0 4.4.4.4/32
inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
4.4.4.4/32 *[OSPF/10] 1w0d 17:33:19, metric 1
> to 10.1.1.7 via ge-0/0/2.0
[email protected]>
Hmmmm. So it still thinks the path to 4.4.4.4/32 is over it’s directly connected interface. But this is exactly what it should be doing! This is our first example of how RSVP decouples itself from the IGP. Recall that vMX2 and vMX3 have no knowledge of the actual target prefix (10.2.2.2/31) since they are just MPLS P nodes. So the only routing information they have is about the LSP endpoints which are advertised into the underlying IGP. If we dig a little deeper, we’ll see that vMX2 is actually honoring our request to include vMX3 in the LSP vmx1-vmx4…
[email protected]> 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: 2 sessions
To From State Rt Style Labelin Labelout LSPname
1.1.1.1 4.4.4.4 Up 0 1 FF 300160 3 vmx4-vmx1
4.4.4.4 1.1.1.1 Up 0 1 FF 300192 300128 vmx1-vmx4
Total 2 displayed, Up 2, Down 0
[email protected]> show route forwarding-table label 300192
Routing table: default.mpls
MPLS:
Destination Type RtRef Next hop Type Index NhRef Netif
300192 user 0 10.1.1.3 Swap 300128 590 2 ge-0/0/1.0
Routing table: __mpls-oam__.mpls
MPLS:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 dscd 553 1
[email protected]>
Above – we can see that the router is aware of two LSPs. The LSP vMX4-vMX1 already existed but now we also see vMX1-vMX4 listed. Initially we had told the path to go to vMX2 (2.2.2.2) which would have pushed the path over here. But since we also have now told it to include vMX3 (3.3.3.3) in the path our forwarding table for that label shows that it will send the traffic out of the ge-0/0/1.0 interface (the interface facing vMX3) and swap the label. Let’s back up and make sure this makes sense by validating what vMX1 is doing…
[email protected]> show rsvp session
Ingress RSVP: 1 sessions
To From State Rt Style Labelin Labelout LSPname
4.4.4.4 1.1.1.1 Up 0 1 FF - 300192 vmx1-vmx4
Total 1 displayed, Up 1, Down 0
Egress RSVP: 1 sessions
To From State Rt Style Labelin Labelout LSPname
1.1.1.1 4.4.4.4 Up 0 1 FF 3 - vmx4-vmx1
Total 1 displayed, Up 1, Down 0
Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0
[email protected]>
Notice that the locally defined LSP (vmx1-vmx4) is listed as an ingress RSVP and lists a label out of 300192. Let’s look at our forwarding table to make sure this makes sense…
[email protected]> show route forwarding-table family inet table default destination 10.2.2.2/31
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
10.2.2.2/31 user 0 indr 1048574 2
10.1.1.1 Push 300192 587 2 ge-0/0/1.0
[email protected]>
Yep – so that label adds up. So when vMX1 wants to send traffic to 10.2.2.2/31 it push a label of 300192 on the frame and sends it out the ge-0/0/1.0 interface toward vMX2. We already saw that when vMX2 gets a label of 300192 it swaps the label with 300128 and pushes the frame out the ge-0/0/1.0 interface facing vMX3. For added validation let’s validate that in the mpls.0 table on vMX2…
[email protected]> show route table mpls.0 label 300192
mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
300192 *[RSVP/7/1] 00:09:58, metric 1
> to 10.1.1.3 via ge-0/0/1.0, label-switched-path vmx1-vmx4
[email protected]>
So that all adds up. By adding a path to the LSP definition we can define loose hops that we’re requesting the routers to use to reach the defined destination in the LSP. So how did this all happen? Without relying on the IGP – how did RSVP signal vMX2 and vMX3 that they had to be included in the LSP path? Let’s dive into some packet capture to see what’s going on. We’ll back up and start by looking at what happened on the wire when we first modified the LSP to include vMX2 (2.2.2.2)…
The above capture was seen on the link between vMX1 and vMX2. Notice that it includes 2 ERO objects. Also notice that they are both being listed as strict EROs. So what gives? It’s best to think of the loose ERO type as being more of a concept. It’s simply a means to tell the router how to make it’s calculation. Once it completes it’s calculation, it comes up with a list of strict EROs based on the loose ERO definition you provided. Thinking about it – that makes pretty good sense. I mean – after all – the ingress router (vMX1) needs to understand the entire path to reach the LSP endpoint. So long as it follows the rules we’ve defined we’re in good shape.
So we can see that we have a strict ERO for 10.1.1.1 and 10.1.1.7. So we can assume that the precomputed path is vMX1->vMX2->vMX4. Let’s now look at the same capture happening on the link between vMX2 and vMX4…
This looks largely the same – but note that out ERO area now only includes the ERO for 10.1.1.7. When vMX2 receives the PATH advertisement from vMX1 – it removes the ERO that matches it’s interface. There’s also the RRO field (Record Route) which each router in the path appends it’s IP address onto. If a router sees it’s own IP address in the RRO, it knows there’s a loop and will prevent the LSP from being built.
Now let’s look at the capture from where we added 3.3.3.3 as another loose hop in the path…
If we look at the same section we’ll see that we now have 3 strict EROs. To be thorough, we’ll look at the path between vMX2 and vMX3…
And between vMX3 and vMX4…
So same behavior – each router removes it’s associated ERO from the PATH advertisement and then passes it along to the next defined ERO. So at this point, our LSP vmx1-vmx4 looks like this…
It’s important to point out that by defining loose EROs, we’re basically telling RSVP to rely on the underlying IGP to find the path to defined loose hop. So now let’s look at our LSP vmx4-vmx1 and attempt to configure it with a strict ERO. Let’s define a path as follows on vMX4…
set protocols mpls path strict-vmx4-vmx1 10.1.1.6 strict
set protocols mpls path strict-vmx4-vmx1 10.1.1.3 strict
set protocols mpls path strict-vmx4-vmx1 10.1.1.8 strict
set protocols mpls label-switched-path vmx4-vmx1 primary strict-vmx4-vmx1
Sp basically we’re now asking for something like this…
The configuration we put in is basically telling vMX4 to take the worst possible path ever to reach vMX1. We tell it to go to vMX2 -> vMX3 -> vMX1. Note that we could have skipped defining the ERO for 10.1.1.8 and the LSP would still work. The EROs are just taken into consideration and when the information runs out, the router will revert to it’s non-ERO behavior and find a path to the endpoint (defined with the to). You can also mix strict and loose EROs so long as you don’t get yourself into trouble (or do something that’s not possible). To prove this is working as expected, let’s label trace the LSP from vMX4 to vMX1…
[email protected]> show route forwarding-table family inet table default destination 10.2.2.0/31
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
10.2.2.0/31 user 0 indr 1048575 2
10.1.1.6 Push 300208 586 2 ge-0/0/2.0
[email protected]>
As seen above, vMX4 will push a label of 300208to the frame and send it out of the ge-0/0/2.0 interface. On vMX2…
[email protected]> show route table mpls.0 label 300208
mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
300208 *[RSVP/7/1] 00:07:55, metric 1
> to 10.1.1.3 via ge-0/0/1.0, label-switched-path vmx4-vmx1
[email protected]>
So here we can see that it’s going to send the traffic out of ge-0/0/1.0 towards 10.1.1.3. The annoying part of RSVP LSPs is that you don’t get the label information in this output. To see what label would be used we have to lookup the LSP…
[email protected]> show mpls lsp name vmx4-vmx1
Ingress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 2 sessions
To From State Rt Style Labelin Labelout LSPname
1.1.1.1 4.4.4.4 Up 0 1 FF 300208 300144 vmx4-vmx1
Total 1 displayed, Up 1, Down 0
[email protected]>
Or look at the actual RSVP session…
[email protected]> show rsvp session
Ingress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0
Egress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit RSVP: 2 sessions
To From State Rt Style Labelin Labelout LSPname
1.1.1.1 4.4.4.4 Up 0 1 FF 300208 300144 vmx4-vmx1
4.4.4.4 1.1.1.1 Up 0 1 FF 300192 300128 vmx1-vmx4
Total 2 displayed, Up 2, Down 0
[email protected]>
In both cases we can see 300208 in and 300144out toward vMX3. On vMX3 we’ll look at the forwarding table for that label…
[email protected]> show route forwarding-table label 300144
Routing table: default.mpls
MPLS:
Destination Type RtRef Next hop Type Index NhRef Netif
300144 user 0 10.1.1.8 Pop 588 2 ge-0/0/2.0
300144(S=0) user 0 10.1.1.8 Pop 589 2 ge-0/0/2.0
Routing table: __mpls-oam__.mpls
MPLS:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 dscd 553 1
[email protected]>
Notice that the label action here is to pop since this is the PHP router. Also note that there are actually two entries here for the same label. Note how one includes S=0 and the other doesn’t. The S refers to the S bit of the MPLS label . S=0 indicates there are more labels in the stack that need to be looked up triggering the router to look in the mpls.0 table again. S=1 indicates there are no more labels and the next hop lookup should occur in the inet.0 table. Since they are the same, this really only indicates that this router is the PHP router. This field will be more relevant for specific MPLS applications like MPLS VPNs with RSVP etc (we’ll see that later on in another blog post).
So we’ve seen what we can do with loose and strict EROs. But we haven’t really talked about the mechanism used to make these determinations. That is – I showed you that the routers were generating PATH messages with EROs – but I didn’t explain how that was working. The magic behind all of this is the traffic engineering database (TED) and the CSPF algorithm. We’ll deep dive on those in our next post. Stay tuned!
Thank you very much for providing such a nice , detailed description of RSVP EROs. All of your blogs are really really Good and I am a big fan of yours .
I am wondering if you could please provide deep insight of auto bandwidth LSPs (its working mechanism , load balancing of multiple auto LSPs to same destination etc) with respect to Juniper MX. That is a very interesting topic I guess and would inspire many others who follow your blog.
I would highly appreciate sir if you could write a blog on this.
Thanks
Good post! Thanks!
Excellent post! Valuable information