cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3803
Views
10
Helpful
5
Replies

MPLS TE Tunnel - Targeted LDP session

rrajmohan
Level 1
Level 1

Why do we require a targeted LDP session over the established TE tunnel ?

For this targeted LDP session, what will be the transport address / discovery interface ?

Since TE LSP is unidirectional, what will happen to LDP session if TE tunnel on one side is down.

1 Accepted Solution

Accepted Solutions

Hi Rajmohan,

I don't think that for LSR to initiate targeted LDP session it is required to have tunnel configured on tail end but for targeted LDP to come up, tail end router also needs to send targeted LDP discovery packet and for that either you need to have tunnel configure or you can define static neighbor.

Lab output:

RP/0/RSP0/CPU0:R1 ----- RP/0/RSP0/CPU0:R2

1. when tunnel configured only on one side - R1

RP/0/RSP0/CPU0:R1#sh mpls ldp discovery
Fri Jan 8 14:11:55.442 UTC

Local LDP Identifier: 49.44.4.45:0
Discovery Sources:
Interfaces:
Bundle-Ether123 : xmit

tunnel-te100 : xmit
Target: 1.55.55.55

Targeted Hellos:
49.44.4.45 -> 1.55.55.55 (active), xmit  <<<<<< only xmit

2. configured static neighbor on tail end router (R2)

RP/0/RSP0/CPU0:R2(config-ldp)#
RP/0/RSP0/CPU0:R2(config-ldp)#neighbor 49.44.4.45 targeted

RP/0/RSP0/CPU0:R1#sh mpls ldp discovery
Fri Jan 8 14:12:23.042 UTC

Local LDP Identifier: 49.44.4.45:0
Discovery Sources:
Interfaces:
Bundle-Ether123 : xmit

tunnel-te100 : xmit
Target: 1.55.55.55

Targeted Hellos:
49.44.4.45 -> 1.55.55.55 (active/passive), xmit/recv  <<<<<<< now it is receiving LDP Hellos
LDP Id: 1.55.55.55:0
Hold time: 90 sec (local:90 sec, peer:90 sec)

RP/0/RSP0/CPU0:R1#sh mpls ldp neighbor
Fri Jan 8 14:12:30.927 UTC

Peer LDP Identifier: 1.55.55.55:0
TCP connection: 1.55.55.55:646 - 49.44.4.45:43047
Graceful Restart: No
Session Holdtime: 180 sec
State: Oper; Msgs sent/rcvd: 6/63; Downstream-Unsolicited
Up time: 00:00:00
LDP Discovery Sources:
Targeted Hello (49.44.4.45 -> 1.55.55.55, active/passive)
Addresses bound to this peer:

Regards,

Akash

View solution in original post

5 Replies 5

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Rrajmohan,

this is done to have LDP based LSPs tunneled over the MPLS TE in the inner core.

In this way PE devices that are outside the full mesh of MPLS TE tunnels can take advantage of them having their associated LDP based LSPs travelling within the MPLS TE tunnel for some routing hops.

An MPLS TE tunnel in the opposite direction has to exist in order to be able to tunnel also the LDP based LSPs in the opposite direction.

If the MPLS TE tunnel is down the targeted LDP session will try to use IP path without using the benefits of an establised MPLS TE tunnel per direction.

Hope to help

Giuseppe

Thank you for the clarification provided.

"LSRs will initiate targeted LDP session.only if TE tunnel exist on both direction between them"

Why is this restriction applied?.

Even if a TE tunnel exist in one direction & the Tail end LSR advertise its label bindings to Head end will enable the LDP based LSP to get tunneled in TE LSP.

How does the check for existence of operational TE tunnel in both direction occurs so as to initiate targeted LDP session?

Which LSR initiate the the targeted LDP session

Hi Rajmohan,

I don't think that for LSR to initiate targeted LDP session it is required to have tunnel configured on tail end but for targeted LDP to come up, tail end router also needs to send targeted LDP discovery packet and for that either you need to have tunnel configure or you can define static neighbor.

Lab output:

RP/0/RSP0/CPU0:R1 ----- RP/0/RSP0/CPU0:R2

1. when tunnel configured only on one side - R1

RP/0/RSP0/CPU0:R1#sh mpls ldp discovery
Fri Jan 8 14:11:55.442 UTC

Local LDP Identifier: 49.44.4.45:0
Discovery Sources:
Interfaces:
Bundle-Ether123 : xmit

tunnel-te100 : xmit
Target: 1.55.55.55

Targeted Hellos:
49.44.4.45 -> 1.55.55.55 (active), xmit  <<<<<< only xmit

2. configured static neighbor on tail end router (R2)

RP/0/RSP0/CPU0:R2(config-ldp)#
RP/0/RSP0/CPU0:R2(config-ldp)#neighbor 49.44.4.45 targeted

RP/0/RSP0/CPU0:R1#sh mpls ldp discovery
Fri Jan 8 14:12:23.042 UTC

Local LDP Identifier: 49.44.4.45:0
Discovery Sources:
Interfaces:
Bundle-Ether123 : xmit

tunnel-te100 : xmit
Target: 1.55.55.55

Targeted Hellos:
49.44.4.45 -> 1.55.55.55 (active/passive), xmit/recv  <<<<<<< now it is receiving LDP Hellos
LDP Id: 1.55.55.55:0
Hold time: 90 sec (local:90 sec, peer:90 sec)

RP/0/RSP0/CPU0:R1#sh mpls ldp neighbor
Fri Jan 8 14:12:30.927 UTC

Peer LDP Identifier: 1.55.55.55:0
TCP connection: 1.55.55.55:646 - 49.44.4.45:43047
Graceful Restart: No
Session Holdtime: 180 sec
State: Oper; Msgs sent/rcvd: 6/63; Downstream-Unsolicited
Up time: 00:00:00
LDP Discovery Sources:
Targeted Hello (49.44.4.45 -> 1.55.55.55, active/passive)
Addresses bound to this peer:

Regards,

Akash

Akash, Thank you for the clarification provided.

So, Even for targeted LDP sessions, successful neighbor discovery (Unicast/UDP) must precede the TCP/646 sesssion for label binding advertisement.

Yes, that is require to check if neighbor is capable and interested in forming targeted LDP session before initiating TCP session