Description

The LDP neighborship is up, but the LDP route is not populating in the INET 3 table.

Symptoms

TOPOLOGY: 
Dolphins (lo0: 10.10.10.10/32) 10.1.1.1/24<----------------------> 10.1.1.2/24 Firebird (lo0 : 20.20.20.20/32)

 

labroot@firebird-re0> show configuration protocols ldp | display set 

set protocols ldp import BLOCK_LDP

set protocols ldp export BLOCK_LDP

set protocols ldp interface xe-1/0/1.0

set protocols ldp interface lo0.0

 

labroot@dolphins-re0:test> show configuration protocols ldp | display set 

set logical-systems test protocols ldp interface xe-0/0/1.0

set logical-systems test protocols ldp interface lo0.0

 

LDP neighborship is up on both the sides

labroot@firebird-re0> show ldp neighbor 

Address               Interface    Label space ID   Hold time

10.1.1.1              xe-1/0/1.0   10.10.10.10:0    11

 

Firebird is populating LDP route in inet.3, but Dolphins is not.

 

labroot@firebird-re0> show route table inet.3 

10.10.10.10/32   *[LDP/9] 22:27:28, metric 1

          > to 10.1.1.1 via xe-1/0/1.0

 

 

labroot@dolphins-re0:test> show route table inet.3 

labroot@dolphins-re0:test> 

 

 

  • The following LDP policy is applied to the protocol in Firebird. Essentially, this policy either accept or deny bindings advertised by neighboring routers.

labroot@firebird-re0> show configuration policy-options policy-statement BLOCK_LDP 

from {

  route-filter 10.10.10.10/32 exact;

}

then accept;

 

  • If a binding is filtered by the policy, it will still appear in the LDP database, but it won't be considered for installation as part of a label-switched path (LSP). You can verify whether a binding has been filtered by the policy using the following command.

labroot@firebird-re0> show ldp database  

Input label database, 20.20.20.20:0--10.10.10.10:0

Labels received: 1

 Label   Prefix

   3   10.10.10.10/32

 

Output label database, 20.20.20.20:0--10.10.10.10:0

Labels advertised: 2

 Label   Prefix

   16   10.10.10.10/32

   3   20.20.20.20/32 (Filtered)

 

  • As the binding is filtered out, the LDP route will not be visible in the inet.3 table.

Solution

To fix the issue, we either need to update or delete the LDP policy. The default LDP import policy accepts all LDP routes and imports them into the inet.3 routing table, while the default LDP export policy rejects everything.

 

In this scenario, the terminating action of 'reject' for the export policy is applied. As a result, the LDP binding advertised from Firebird is filtered out.

 

Firebird LDP policy has been updated with its loopback address. Following this change, the LDP binding for 20.20.20.20/32 is not filtered and is advertised to the dolphins. Consequently, we see the LDP route in the inet.3 table in Dolphins.

 

labroot@firebird-re0> show configuration policy-options 

policy-statement BLOCK_LDP {

  from {

    route-filter 10.10.10.10/32 exact;

    route-filter 20.20.20.20/32 exact;

  }

  then accept;

}

 

labroot@dolphins-re0:test> show route table inet.3 

 

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

20.20.20.20/32   *[LDP/9] 00:00:28, metric 1

          > to 10.1.1.2 via xe-0/0/1.0

 

Modification History

2024-06-11 : Article Created

2026-06-14: Mark to be external