MPLS/RSVP configuration & troubleshooting #2

In my previous post MPLS/RSVP configuration & troubleshooting I have configured two LSPs between two MPLS routers. Now I will continue where I left off. Just one thing I must inform you that MPLS labels in the previous post won’t match this post as I restarted my routers. We will again use the same topology;

Previously we had two LSPs but didn’t know what to do with them. Now we will see how we can make use of them. When we create the LSP, one new routing table inet.3 will be populated.

root@j35> show route table inet.3    

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

10.1.1.8/32        *[RSVP/7/1] 00:29:24, metric 40
                    > to 172.41.1.1 via ge-0/0/1.0, label-switched-path j35-to-j40

inet.3 is the MPLS routing table. Once an LSP is established, you can find it here. You can see this table in an Ingress MPLS router but not in transit one in which you can see mpls.0 switching table populated.

BGP has very close connection with this table. For example, the network 98.1.1.0/24 has been discovered via IBGP from J40 to J35. This means protocol next hop is 10.1.1.8 address. BGP first look in the inet.3 table and if it finds 10.1.1.8 there, it will install the physical next hop in inet.0

root@j35> 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:34:27, localpref 100, from 10.1.1.8
                      AS path: I
                    > to 172.41.1.1 via ge-0/0/1.0, label-switched-path j35-to-j40

Having an LSP as the next hop literally means, instead of sending it as an IP packet, router will encapsulate it in an MPLS frame and send it over the network. This also means that (P)Provider routers in the middle don’t really care what destination IP address you have in your packet. This also means that they can forward the packet without knowing the destination network. Pretty cool!

In the previous post our traceroute had failed because P routers didn’t have the routing entry for 98.1.1.0/24. Now we encapsulate the packet in MPLS frame. Let’s see what happens now;

root@j35> 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.41.1.1  8.201 ms  5.867 ms  5.968 ms
     MPLS Label=299824 CoS=0 TTL=1 S=1
 2  192.168.24.1  8.861 ms  12.005 ms  8.013 ms
     MPLS Label=299808 CoS=0 TTL=1 S=1
 3  10.194.194.1  15.986 ms  11.946 ms  14.018 ms
     MPLS Label=299808 CoS=0 TTL=1 S=1
 4  98.1.1.1  17.961 ms  15.950 ms  19.772 ms

Packet is forwarded properly. To demonstrate how the MPLS frame looks like I am sending a ping to destination 98.1.1.1 and see how the request/response looks like when we capture packet between J35-J31

ICMP REQUEST MPLS FRAME


ICMP RESPONSE MPLS FRAME

root@j35> 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       -   299824 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

If you compare the REQUEST ICMP MPLS FRAME and show rsvp session from J35, you can see that the label in the capture is matching the Labelout column. If you have noticed, you don’t see any MPLS header in the response. It is because J35 is an egress router and J31 is doing PHP (Penultimate Hop Popping) due to which packet is decapsulated before being sent to J35.

Now for some reason I would like my LSP not traverse the south but the routers in the north. If you look at the traceroute output, you can see that packets for 98.1.1.0/24 are traversing J31->J33->J32->J40 path but I want them to follow J34->J30->J29->J40

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


[edit]
root@j40# show protocols mpls 
no-cspf;
label-switched-path j40-to-j35 {
    to 10.1.1.7;
    primary north;
}
path north {
    24.1.1.1 strict;
    10.1.1.3 strict;
    10.1.1.6 strict;
}
interface all;

For this I have used strict keyword in every path and assigned this path as primary on this LSP. (Specifying egress router is optional) then I did the same for the reverse direction.

[edit protocols mpls]
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] 01:08:49, localpref 100, from 10.1.1.8
                      AS path: I
                    > to 172.40.1.1 via ge-0/0/0.0, label-switched-path j35-to-j40

Now can you see that next hope changed from 172.41.1.1 (J31) to 172.40.1.1 (J34). We can see this change with an mpls traceroute as well.

root@j35> traceroute mpls rsvp j35-to-j40 
  Probe options: retries 3, exp 7

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   299792  RSVP-TE     172.40.1.1       (null)           Unhelpful         
    2                       10.1.1.3         172.40.1.1       Unhelpful         
    3                       10.1.1.2         10.1.1.3         Unhelpful         
    4                       10.1.1.8         10.1.1.2         Egress    

root@j35> traceroute 98.1.1.1 no-resolve     
traceroute to 98.1.1.1 (98.1.1.1), 30 hops max, 40 byte packets
 1  172.40.1.1  5.952 ms  5.937 ms  6.004 ms
     MPLS Label=299792 CoS=0 TTL=1 S=1
 2  192.168.198.1  9.961 ms  11.976 ms  9.961 ms
     MPLS Label=299776 CoS=0 TTL=1 S=1
 3  192.168.196.1  12.059 ms  17.668 ms  12.237 ms
     MPLS Label=299776 CoS=0 TTL=1 S=1
 4  98.1.1.1  19.958 ms  17.977 ms  18.002 ms

However forcing a strict path has some drawbacks as far as I can see. If the LSP does down for some reason, a new LSP isn’t established automatically which means your traffic is black holed. For this we will add a second path in the case the primary path goes down.

I have done a failure test in which I cut communication between J34 and J30 in the north and saw that switchover to the secondary path took quite short during which I only lost 1 ICMP. Here how it worked for me;

I would like to end this post here. I haven’t talked about Fast reroute feature yet as it requires some major changes in my topology. I will do it in the next post hopefully.

Click for the 3rd post

Stay tuned!