Home / MPLS / What is LDP extended discovery?

What is LDP extended discovery?

Normally LDP neighbors are found automatically by sending UDP Hello packets on Port 646 with the destination of multicast address 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 targeted ldp

BB-PE1#sh mpls ldp neighbor det
    Peer LDP Ident:; Local LDP Ident
        TCP connection: -
        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 ->, active, passive;
            holdtime: infinite, hello interval: 10000 ms
        Addresses bound to peer LDP Ident:

        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:, rev 6
        local binding:  label: imp-null
        remote binding: lsr:, label: 16
  lib entry:, rev 17
        remote binding: lsr:, label: 17
  lib entry:, rev 4
        local binding:  label: 16
        remote binding: lsr:, label: 21


  1. 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?

  2. 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.

    Mohammed Mahmoud.

  3. 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

    Then we enable the LDP on that tunnel:
    mpls ldp
    session protection
    for LOOPBACK_0
    interface tunnel-te15

  4. You got it right ,Thanks Taufiq for sharing 🙂