Normally LDP neighbors are found automatically by sending UDP Hello packets on Port 646 with the destination of multicast address 224.0.0.2 out of each LDP enabled interface.
In some MPLS applications a LDP session must be established between non directly connected peers to exchange labels. In such cases Hello packets can not be just broadcasted, instead these Hello packets are sent as unicast packets using UDP on port 646 and destined to the targeted peer.
AToM and some Traffic Engineering scenarios are examples of these applications that require a targeted LDP session between non directly connected routers.
The command mpls ldp neighbor [vrf vpn-name] ip-addr targeted [ldp | tdp] can be used to manually configure targeted LDP sessions between peers.
Note: In the AToM and TE cases you don’t need to use the previous command because the session will be established automatically after adding the service required configuration.
Configuration example:
BB-PE1(config)#mpls ldp neighbor 100.100.253.2 targeted ldp BB-PE1#sh mpls ldp neighbor 100.100.253.2 det Peer LDP Ident: 100.100.253.2:0; Local LDP Ident 100.100.253.1:0 TCP connection: 100.100.253.2.25316 - 100.100.253.1.646 Password: not required, none, in use State: Oper; Msgs sent/rcvd: 12/12; Downstream; Last TIB rev sent 17 Up time: 00:01:30; UID: 3; Peer Id 1; LDP discovery sources: Targeted Hello 100.100.253.1 -> 100.100.253.2, active, passive; holdtime: infinite, hello interval: 10000 ms Addresses bound to peer LDP Ident: 100.100.29.1 100.100.253.2 Peer holdtime: 180000 ms; KA interval: 60000 ms; Peer state: estab Clients: Dir Adj Client !-- Small Part of the LIB table showing the label exchange between the peers BB-PE1#sh mpls ldp binding lib entry: 100.100.19.0/24, rev 6 local binding: label: imp-null remote binding: lsr: 100.100.253.2:0, label: 16 lib entry: 100.100.19.1/32, rev 17 remote binding: lsr: 100.100.253.2:0, label: 17 lib entry: 100.100.19.2/32, rev 4 local binding: label: 16 remote binding: lsr: 100.100.253.2:0, label: 21
Hi,
‘In the AToM and TE cases you don’t need to use the previous command because the session will be established automatically after adding the service required configuration’
When is the targetted LDP initated in the above case?
Can you give some examples of such commands? xconnect?
Hi Imran,
Yes, with AToM just configuring the xconnect command initiates the targeted LDP session, but with TE it is a little different (remember that the most common scenario that you require LDP with TE is when the tunnel is terminated on a P router, we can have a latter post discussing this in details), with TE it depends on the scenario, if you have just one tunnel from the head-end to the tail-end thus you’ll need to instruct the tail-end router to accept the LDP targeted session using the “mpls ldp discovery targeted-hello accept” command, while if you had bidirectional TE tunnels setup, in this case having “mpls ip” under both tunnel interfaces initiates the session for you.
I hope that I’ve been informative.
BR,
Mohammed Mahmoud.
This is similar with what we do in LDP over RSVP. We create tunnel first
interface tunnel-te15
description Primary TE Tunnel to Jakarta Core Router
ipv4 unnumbered Loopback0
logging events lsp-status reoptimize
logging events lsp-status state
logging events lsp-status reroute
priority 0 0
autoroute announce
signalled-bandwidth 0
destination 10.10.1.1
fast-reroute
Then we enable the LDP on that tunnel:
mpls ldp
router-id 20.20.20.1
nsr
graceful-restart
session protection
label
advertise
disable
for LOOPBACK_0
!
!
interface tunnel-te15
You got it right ,Thanks Taufiq for sharing 🙂