LDP Over RSVP-TE

Considering the available label distribution protocols in MPLS networks, RSVP-TE and LDP are the de-facto standards. LDP is quite popular, however, one of its main limitations is the lack of traffic engineering support–ignoring CR-LDP for now. Sometimes even small networks can benefit from steering traffic one way or another to avoid potential congestion scenarios and/or underutilised links. This post looks at how LDP over RSVP-TE works in small Juniper MX core network deployment primarily running LDP as its main label distribution protocol.

The following topology diagram is used to illustrate the concept throughout this post.

LDP over RSVP-TE Topology
LDP over RSVP-TE Topology

As traffic arrives/originates at R5 towards 7.7.7.7 it ingress the LDP LSP where R5 pushes a label of value 300064 and forwards it to R3. A simple traceroute confirms the LSP is following the IGP path as you would normally expect with LDP–shown by the red path in the diagram.

[email protected]> traceroute 7.7.7.7   
traceroute to 7.7.7.7 (7.7.7.7), 30 hops max, 40 byte packets
 1  10.0.35.3 (10.0.35.3)  1.060 ms  1.466 ms  0.813 ms
 2  10.0.34.4 (10.0.34.4)  1.264 ms  1.167 ms  1.764 ms
 3  10.0.46.6 (10.0.46.6)  1.961 ms  1.421 ms  2.136 ms
 4  7.7.7.7 (7.7.7.7)  1.862 ms  2.660 ms  2.282 ms

[email protected]> traceroute mpls ldp 7.7.7.7 
  Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   300064  LDP         10.0.35.3        (null)           Success           
    2   299904  LDP         10.0.34.4        10.0.35.3        Success           
    3   299952  LDP         10.0.46.6        10.0.34.4        Success           
    4        3  LDP         10.0.67.7        10.0.46.6        Egress            

  Path 1 via ge-0/0/0.35 destination 127.0.0.64

The output also shows the PHP behaviour at R6 confirming explicit-null is not configured on R7.

RSVP was then enabled on the appropriate interfaces across the core network and an alternative path between R3 to R6 was created–shown by the purple path in the diagram–resulting in R3 being the ingress router or the head-end for this unidirectional RSVP LSP.

[edit]
[email protected]# show protocols mpls 
label-switched-path R3-TO-R6 {
    to 6.6.6.6;
    primary R3-R1-R2-R6;
}
path R3-R1-R2-R6 {
    1.1.1.1 strict;
    2.2.2.2 strict;
}                                       
interface all;
interface fxp0.0 {
    disable;
}

[edit]
[email protected]# run show mpls lsp ingress 
Ingress LSP: 1 sessions
To              From            State Rt P     ActivePath       LSPname
6.6.6.6         3.3.3.3         Up     0 *     R3-R1-R2-R6      R3-TO-R6
Total 1 displayed, Up 1, Down 0

Although the LSP has an Up state R3 only has directly discovered LDP neighbours to which it is exchanging label information.

[edit]
[email protected]# run show ldp neighbor        
Address            Interface          Label space ID         Hold time
10.0.13.1          ge-0/0/0.13        1.1.1.1:0                11
10.0.34.4          ge-0/0/0.34        4.4.4.4:0                14
10.0.35.5          ge-0/0/0.35        5.5.5.5:0                12

[edit]
[email protected]# run show ldp session     
  Address           State        Connection     Hold time  Adv. Mode
1.1.1.1             Operational  Open             20         DU
4.4.4.4             Operational  Open             20         DU
5.5.5.5             Operational  Open             20         DU

R5 continues to use the LDP/IGP path just as before.

[email protected]> traceroute 7.7.7.7             
traceroute to 7.7.7.7 (7.7.7.7), 30 hops max, 40 byte packets
 1  10.0.35.3 (10.0.35.3)  0.960 ms  0.771 ms  0.756 ms
 2  10.0.34.4 (10.0.34.4)  1.141 ms  1.233 ms  1.031 ms
 3  10.0.46.6 (10.0.46.6)  1.443 ms  1.376 ms  2.233 ms
 4  7.7.7.7 (7.7.7.7)  2.842 ms  2.214 ms  2.246 ms

In order for LDP to operate over the RSVP LSP it is necessary to add the ldp-tunneling statement under the LSP R3-TO-R6 on R3 as shown below.

[edit]
[email protected]# set protocols mpls label-switched-path R3-TO-R6 ldp-tunneling

[edit]
[email protected]# show protocols mpls label-switched-path R3-TO-R6 
to 6.6.6.6;
ldp-tunneling;
primary R3-R1-R2-R6;

[edit]
[email protected]# commit 
commit complete

R3 is now able to run LDP over the RSVP established LSP and open an LDP session ‘directly’ to R6, essentially tunnelling the LDP LSP through the RSVP LSP.

[edit]
[email protected]# run show ldp neighbor 
Address            Interface          Label space ID         Hold time
10.0.13.1          ge-0/0/0.13        1.1.1.1:0                14
10.0.34.4          ge-0/0/0.34        4.4.4.4:0                13
10.0.35.5          ge-0/0/0.35        5.5.5.5:0                13
6.6.6.6            lo0.0              6.6.6.6:0                42

[edit]
[email protected]# run show ldp session     
  Address           State        Connection     Hold time  Adv. Mode
1.1.1.1             Operational  Open             22         DU
4.4.4.4             Operational  Open             22         DU
5.5.5.5             Operational  Open             22         DU
6.6.6.6             Operational  Open             22         DU

The discovery process is considered an extended discovery–as opposed to basic discovery between directly connected neighbours–and therefore the LDP process must be enabled on the lo0 interfaces at both ends. If we were to disable LDP for lo0 the session would be closed as shown below.

[edit]
[email protected]# set protocols ldp interface lo0.0 disable 

[edit]
[email protected]# commit 
commit complete

[edit]
[email protected]# run show ldp neighbor 
Address            Interface          Label space ID         Hold time
10.0.13.1          ge-0/0/0.13        1.1.1.1:0                13
10.0.34.4          ge-0/0/0.34        4.4.4.4:0                11
10.0.35.5          ge-0/0/0.35        5.5.5.5:0                12

[edit]
[email protected]# run show ldp session     
  Address           State        Connection     Hold time  Adv. Mode
1.1.1.1             Operational  Open             22         DU
4.4.4.4             Operational  Open             22         DU
5.5.5.5             Operational  Open             22         DU

[edit]
[email protected]# rollback 1 
load complete

[edit]
[email protected]# commit 
commit complete

At this moment labels are being exchanged between R3 and R6 accordingly. The received labels–shown under ‘Input label database’ below– confirms that it expects a label value of 299952 for the 7.7.7.7/32 FEC.

[edit]
[email protected]# run show ldp database session 6.6.6.6 
Input label database, 3.3.3.3:0--6.6.6.6:0
  Label     Prefix
 300000      1.1.1.1/32
 299984      2.2.2.2/32
 299968      3.3.3.3/32
 299936      4.4.4.4/32
 300048      5.5.5.5/32
      3      6.6.6.6/32
 299952      7.7.7.7/32                 

Output label database, 3.3.3.3:0--6.6.6.6:0
  Label     Prefix
 299968      1.1.1.1/32
 299952      2.2.2.2/32
      3      3.3.3.3/32
 299920      4.4.4.4/32
 299936      5.5.5.5/32                 
 300048      6.6.6.6/32
 300064      7.7.7.7/32

How does it effect R5 traffic destined to R7? Again a simple traceroute should allow us to verify it.

[email protected]> traceroute mpls ldp 7.7.7.7    
  Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   300064  LDP         10.0.35.3        (null)           Success           
    2   300000  RSVP-TE     10.0.13.1        10.0.35.3        Success           
    3   299984  RSVP-TE     10.0.12.2        10.0.13.1        Success           
    4        3  RSVP-TE     10.0.26.6        10.0.12.2        Success           
    5        3  LDP         10.0.67.7        10.0.26.6        Egress            

  Path 1 via ge-0/0/0.35 destination 127.0.0.64

This is an exciting output which clearly confirms LDP tunnelling happening at R3. It also shows two pop/PHP operations. One happening at R2 for the RSVP LSP and another at R6 for the LDP LSP.

Looking at R3’s LIB table shows that inbound traffic with label 300064 is forwarded through the R3-TO-R6 LSP.

[edit]
[email protected]# run show route label 300064 

mpls.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

300064             *[LDP/9] 00:02:15, metric 1
                    > to 10.0.13.1 via ge-0/0/0.13, label-switched-path R3-TO-R6

A closer look shows that upon receiving label 300064 R3 actually performs a swap operation from 300064 to 299952–which is the label R6 expects for 7.7.7.7/32 FEC–and a transport label 300000 is also pushed for the RSVP LSP matching what is shown in R5’s traceroute output.

[edit]
[email protected]# run show route label 300064 detail 

mpls.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
300064 (1 entry, 1 announced)
        *LDP    Preference: 9
                Next hop type: Router, Next hop index: 584
                Address: 0x97886f4
                Next-hop reference count: 2
                Next hop: 10.0.13.1 via ge-0/0/0.13, selected
                Label-switched-path R3-TO-R6
                Label operation: Swap 299952, Push 300000(top)
                Label TTL action: prop-ttl, prop-ttl(top)
                Load balance label: Label 299952: None; Label 300000: None; 
                Session Id: 0x1
                State: 
                Age: 3:34 	Metric: 1 
                Validation State: unverified 
                Task: LDP
                Announcement bits (1): 0-KRT 
                AS path: I
                Prefixes bound to route: 7.7.7.7/32

Once traffic arrives at R1 a swap operation is performed based on the topmost–RSVP–label only.

[email protected]> show route label 300000 detail best

mpls.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
300000 (1 entry, 1 announced)
        *RSVP   Preference: 7/1
                Next hop type: Router, Next hop index: 569
                Address: 0x955aab8
                Next-hop reference count: 2
                Next hop: 10.0.12.2 via ge-0/0/0.12, selected
                Label-switched-path R3-TO-R6
                Label operation: Swap 299984
                Load balance label: Label 299984: None; 
                Session Id: 0x2
                State: 
                Age: 19:33 	Metric: 1 
                Validation State: unverified 
                Task: RSVP
                Announcement bits (1): 0-KRT 
                AS path: I

R2 being the penultimate router to R6 pops the topmost label.

[email protected]> show route label 299984 detail best    

mpls.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
299984(S=0) (1 entry, 1 announced)
        *RSVP   Preference: 7/1
                Next hop type: Router, Next hop index: 583
                Address: 0x965c208
                Next-hop reference count: 2
                Next hop: 10.0.26.6 via ge-0/0/0.26, selected
                Label-switched-path R3-TO-R6
                Label operation: Pop      
                Load balance label: None; 
                Session Id: 0x2
                State: 
                Age: 21:13 	Metric: 1 
                Validation State: unverified 
                Task: RSVP
                Announcement bits (1): 0-KRT 
                AS path: I

The following diagram illustrates the control plane behaviour for transit traffic arriving at R5 destined to R7.

LDP Over RSVP-TE Control Plane
LDP Over RSVP-TE Control Plane

Leave a Reply

Your email address will not be published. Required fields are marked *