Supported Platforms
Filtering Inbound LDP Label Bindings
You can filter received LDP label bindings, applying policies to accept or deny bindings advertised by neighboring routers. To configure received-label filtering, include the import statement:
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
The named policy (configured at the [edit policy-options] hierarchy level) is applied to all label bindings received from all LDP neighbors. All filtering is done with from statements. Table 1 lists the only from operators that apply to LDP received-label filtering.
Table 1: from Operators That Apply to LDP Received-Label Filtering
from Operator | Description |
|---|---|
interface | Matches on bindings received from a neighbor that is adjacent over the specified interface |
neighbor | Matches on bindings received from the specified LDP router ID |
next-hop | Matches on bindings received from a neighbor advertising the specified interface address |
route-filter | Matches on bindings with the specified prefix |
If a binding is filtered, it still appears in the LDP database, but is not considered for installation as part of a label-switched path (LSP).
Generally, applying policies in LDP can be used only to block the establishment of LSPs, not to control their routing. This is because the path that an LSP follows is determined by unicast routing, and not by LDP. However, when there are multiple equal-cost paths to the destination through different neighbors, you can use LDP filtering to exclude some of the possible next hops from consideration. (Otherwise, LDP chooses one of the possible next hops at random.)
LDP sessions are not bound to interfaces or interface addresses. LDP advertises only per-router (not per-interface) labels; so if multiple parallel links exist between two routers, only one LDP session is established, and it is not bound to a single interface. When a router has multiple adjacencies to the same neighbor, take care to ensure that the filter does what is expected. (Generally, using next-hop and interface is not appropriate in this case.)
If a label has been filtered (meaning that it has been rejected by the policy and is not used to construct an LSP), it is marked as filtered in the database:
user@host> show ldp databaseInput label database, 10.10.255.1:0-10.10.255.6:0 Label Prefix 3 10.10.255.6/32 (Filtered) Output label database, 10.10.255.1:0-10.10.255.6:0 Label Prefix 3 10.10.255.1/32 (Filtered)
For more information about how to configure policies for LDP, see the Routing Policy Feature Guide for Routing Devices.
Examples: Filtering Inbound LDP Label Bindings
Accept only /32 prefixes from all neighbors:
Accept 131.108/16 or longer from router ID 10.10.255.2 and accept all prefixes from all other neighbors:
