MPLS/RSVP configuration & troubleshooting #1

I would like to show how I configured my MPLS cloud with RSVP signaling in this post. This is the first post of my RSVP,MPLS/VPNs series. I will use the topology below throughout my posts. In a real world MPLS core, things may be different but this is just a lab.

mpls_ospf_rsvp

I have a provider MPLS core (AS8500) and several customers A,B,C,D
with different AS numbers. Addressing is as it is depicted in the picture.

RSVP as the label distribution protocol dynamically establishes Label Switching Paths (LSP) and it is fundamental to MPLS which uses this information to create its forwarding tables. Here  I use OSPF to discover the paths, which means your network must already have a working OSPF for RSVP to function properly.

Below are the steps I have taken to configure this label distribution protocol plus MPLS on top of it. I am also sharing the problems I have experienced on the way. I still lack tons of things on these protocols and the more I learn the more I see how it is immense and not easy to digest.
We have to start somewhere, let’s begin with RSVP.

RSVP

 1) Enable RSVP in all routers and their interfaces. This is lab so we don’t care much about unnecessary RSVP traffic.

2) Check interfaces and neighbors

I must admit that this RSVP neighbor relation isn’t that clear for me.  Under normal circumstances I should expect a neighbor if there is an active session but in practice as soon as I enable RSVP in all interfaces, some routers have neighbors for each interfaces some have missing neighbors.

Correction: My latest tests showed that if there is no LSP setup, there isn’t any RSVP neighborship either. So I must have done some mistake above or there was some configuration already for these neigborships to be UP otherwise, there shouldn’t be any neighborship

Now every router in the cloud have RSVP enabled except the customer sites. Let’s check if we have any active session or not:

We have no active session as we haven’t set up any LSP yet. Now MPLS’s turn;

 

MPLS

An LSP is a unidirectional path from the ingress router to the egress router. I will show you what you can do with an LSP. For example let’s see how J35 will reach the network 98.1.1.0/24 under normal circumstances.

According to BGP table packet will be forwarded to J34 in the north side but when we check J34 routing table we see that there is no route for this destination.

it is empty. Reason? It is because I have IBGP peering with only J40 and core is free of BGP but because I will implement MPLS, P routers won’t need to inspect my IP packet. Even if you try, you will see that you can’t reach the network;

 

 

 Enable MPLS

MPLS protocol must be enabled in two sections in a junos router. Under protocol and interface. Every interface participating on MPLS network must have mpls family enabled e.g J40

In addition to this, those interfaces are enabled under protocols level or all interfaces to make it quick

no-cspf must be present in all routers for the time being. I will come to this. If you don’t set this,
nothing will work.

Once we enable MPLS in every router, now it is time to create the first LSP in the direction from J40 to J35. This command tells J40 that it should set up an LSP for destination 10.1.1.7

Heyyy, we have an active one way LSP now. As you can see J40 has an Ingress RSVP but J29 has transit. From the output we can also say that J40 will label MPLS packets with 299888 label and J29 will swap it by 299824

But how is J29 aware of the label of J40 299888? or more correctly how J40 router knows that it should label packets with 299888 but not something else. For this I must show some packet captures. As soon as you configure LSP on J40 router, RSVP PATH message is sent across the network following the OSPF path. Packet is examined by each router in the path and once it reaches at the egress router a RESV (Reservation) packet is sent back and it is also examined by each router.

Note: 10.1.1.8 should be learned via OSPF already.

PATH MESSAGES

From (Ingress)J40-to-J29

path_message_j40-j29

 From J29-to-J30

path_message-j29-j30

 From J34-to-J35 (egress )

path_message_j34-j35

Ingress router J40 sets the Router Alert option of IP packet in the PATH message. As you can see each PATH message is requesting a LABEL and each hop adds its IP to RECORD ROUTE object. You can even see the lsp name configured in junos in this message. So, at each hop packet is opened, modified and forwarded to the nexthop until it reaches the destination.  Now it is time for RESV (Reservation) back to the source.

RESV Messages

From (egress) J35-to-J34

resv_message-J35-J34

Here the same story but now REQUESTED labels are assigned and routers along the path are informed one by one. In this message, J35 tells J34 that its label is 3.  This is implicit NULL and it informs this upstream LSR (J34) to pop its label before forwarding its packets towards egress router on this LSP.

From J30-to-J29

resv_message-j30-j29

 

Look at the label assigned and check the “show rsvp session” command output I pasted above. You can see the label 299824. J30 router informs J29 that if it sends an MPLS packet, it should label it with 299824.

From J29-to-J40

resv_message_j29-j40

 

And it is the last RESV message. Label is assigned and RECORD ROUTE contains the entire track.

Now, once Ingress receives this RESV message, LSP is established. Once you setup the return LSP, we will have two way LSP established. Here it is;

 

Problems

1)One basic problem you may encounter is to forget to enable mpls or rsvp on interfaces.

2) The biggest problem I experienced in RSVP was because of a strange issue. Egress router J35 had multiple IP addresses on its mpls facing interface. This caused RESV message to be sent from an IP address that J35 isn’t expecting. I saw that once J35 received this RESV, it returned
an RESV error message “no sender information for this resv message“.  I fixed it either removing extra IP addresses or setting primary/preferred options on the primary IP 172.40.1.2 which is the RSVP neighbor address.

Now we have two LSPs established with which I am ending this post. This is the first post of MPLS series as I have mentioned. We don’t have a working network yet but I will come to that point. In the next post, I hope to show how we can route packets through these LSPs and do some fast link recovery.

Stay tuned!

Go to the 2nd post on this topic

5 thoughts on “MPLS/RSVP configuration & troubleshooting #1

You have a feedback?