03-02-2016 08:51 AM
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.
Solved! Go to Solution.
03-07-2016 09:10 AM
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
03-03-2016 07:05 AM
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
03-07-2016 06:10 AM
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
03-07-2016 09:10 AM
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
03-08-2016 06:07 AM
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.
03-08-2016 09:13 AM
Yes, that is require to check if neighbor is capable and interested in forming targeted LDP session before initiating TCP session
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide