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.

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.

#set protocols rsvp interface all

2) Check interfaces and neighbors

root@J32#run show rsvp neighbor 
RSVP neighbor: 3 learned
Address            Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd
25.1.2.2             10  1/0       27:45        9   186/186  104
10.194.194.2          5  1/0       27:45        9   186/186  108
192.168.195.1        10  1/0       26:06        9   175/175  81

root@J32#run show rsvp interface 
RSVP interface: 5 active
                  Active Subscr- Static      Available   Reserved    Highwater
Interface   State resv   iption  BW          BW          BW          mark
ge-0/0/0.0  Up         0   100%  1000Mbps    1000Mbps    0bps        0bps       
ge-0/0/1.0  Up         0   100%  1000Mbps    1000Mbps    0bps        0bps       
ge-0/0/2.0  Up         1   100%  1000Mbps    1000Mbps    0bps        0bps       
ge-0/0/3.0  Up         1   100%  1000Mbps    1000Mbps    0bps        0bps       
sp-0/0/0.0  Up         0   100%  800Mbps     800Mbps     0bps        0bps

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:

root@j40# run 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: 0 sessions
Total 0 displayed, Up 0, Down 0

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.

root@j35#run show route 98.1.1.0/24 

inet.0: 63 destinations, 74 routes (62 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

98.1.1.0/24        *[BGP/170] 00:42:56, localpref 100, from 10.1.1.8
                      AS path: I
                    > to 172.40.1.1 via ge-0/0/0.0
                      to 172.41.1.1 via ge-0/0/1.0

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.

root@J34> show route 98.1.1.0/24

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;

[edit protocols bgp]
root@j35# show 
group int {
    type internal;
    local-address 10.1.1.7;
    export bgp-my-nets;
    neighbor 10.1.1.8;
}

root@j35#run traceroute no-resolve 98.1.1.1 
traceroute to 98.1.1.1 (98.1.1.1), 30 hops max, 40 byte packets
 1  172.40.1.1  5.914 ms  6.049 ms 172.41.1.1  7.874 ms
 2  192.168.24.1  10.030 ms 192.168.23.2  7.930 ms  8.018 ms
 3  192.168.24.2  9.958 ms  10.022 ms 192.168.24.1  9.965 ms
 4  192.168.24.2  9.996 ms 192.168.24.1  14.010 ms  14.007 ms
 5  192.168.24.1  15.894 ms  8.084 ms 192.168.24.2  13.909 ms
 6  192.168.24.1  18.019 ms 192.168.24.2  13.959 ms  15.971 ms
 7  192.168.24.2  12.009 ms  15.889 ms 192.168.24.1  16.135 ms
 8  192.168.24.2  19.895 ms 192.168.24.1  19.986 ms  17.956 ms
 9  192.168.24.1  18.005 ms  17.985 ms 192.168.24.2  14.014 ms
10  192.168.24.1  25.973 ms 192.168.24.2  20.017 ms  19.901 ms
11  192.168.24.2  22.013 ms  23.986 ms 192.168.24.1  22.030 ms
12  192.168.24.2  21.902 ms 192.168.24.1  29.996 ms  23.909 ms

 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

[edit]
root@j40# show interfaces ge-0/0/0 
unit 0 {
    family inet {
        address 24.1.1.2/24;
    }
    family mpls;
}

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

#set protocols mpls interface all
#set protocols mpls no-cspf

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

root@j40# show protocols mpls                
no-cspf;
label-switched-path j40-to-j35 {
    to 10.1.1.7;
}
interface all;

[edit]
root@j40# run show rsvp session 
Ingress RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
10.1.1.7        10.1.1.8        Up       0  1 FF       -   299888 j40-to-j35
Total 1 displayed, Up 1, Down 0

Egress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

[edit]
root@jgw29# run 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: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
10.1.1.7        10.1.1.8        Up       0  1 FF  299888   299824 j40-to-j35
Total 1 displayed, Up 1, Down 0

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

 From J29-to-J30

 From J34-to-J35 (egress )

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

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

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

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;

[edit protocols mpls]
root@j35# show 
no-cspf;
label-switched-path j35-to-j40 {
    to 10.1.1.8;
}
interface all;

[edit protocols mpls]
root@j35# run show rsvp session 
Ingress RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
10.1.1.8        10.1.1.7        Up       0  1 FF       -   299952 j35-to-j40
Total 1 displayed, Up 1, Down 0

Egress RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
10.1.1.7        10.1.1.8        Up       0  1 FF       3        - j40-to-j35
Total 1 displayed, Up 1, Down 0

Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

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