Define rsvp how to#

But we haven’t really talked about the mechanism used to make these determinations. So we’ve seen what we can do with loose and strict EROs.

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). Since they are the same, this really only indicates that this router is the PHP router. S=1 indicates there are no more labels and the next hop lookup should occur in the inet.0 table. 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. The S refers to the S bit of the MPLS label. Note how one includes S=0 and the other doesn’t. Also note that there are actually two entries here for the same label. Notice that the label action here is to pop since this is the PHP router. Let’s back up and make sure this makes sense by validating what vMX1 is doing… 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. Initially we had told the path to go to vMX2 ( 2.2.2.2) which would have pushed the path over here. The LSP vMX4-vMX1 already existed but now we also see vMX1-vMX4 listed. > show route forwarding-table label 300192ĭestination Type RtRef Next hop Type Index NhRef Netifģ00192 user 0 10.1.1.3 Swap 300128 590 2 ge-0/0/1.0Ībove – we can see that the router is aware of two LSPs. We can see that by looking at the routing table for the bottom user prefix… So in our case, the LSP vmx1-vmx4 happened to chose the path down to vMX3 and over 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. For instance, if we pick our lab up where we left off last time, we had an LSP defined from vMX1 to vMX4.

Define rsvp how to#

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. Note: We’ll be using the lab where we left off from the last post. Let’s talk about them individually and show an example of each in our lab. 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. At it’s most basic level – and ERO describes which LSRs (Label Switched Routers) a given LSP should traverse. RSVP extends this by allowing the definition of what are referred to as Explicit Route Objects (EROs). So at it’s core – obviously both rely heavily on the underlying routing information to build LSPs. 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.

While this is an accurate statement, it doesn’t mean that RSVP isn’t. The first thing that everyone points out is that LDP is tightly bound to the underlying IGP. So now let’s talk about some differences between LDP and RSVP. 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. In this use case, it is often referred to as “RSVP-TE” or “MPLS RSVP-TE”. The protocol was then extended to support setting up MPLS LSPs. RSVP was initially a means to reserve resources for flows across a network. That’s because RSVP itself initially had nothing to do with MPLS. When talking about MPLS – RSVP is typically just called RSVP – but without the MPLS context – it might be a little confusing. 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. This was a tedious process at least when compared to what we saw with LDP setting up LSPs. In our last post we covered the basics of getting an RSVP LSP setup.