Configuring Miscellaneous LDP Properties
The following sections describe how to configure a number of miscellaneous LDP properties:
- Configuring LDP to Use the IGP Route Metric
- Preventing Addition of Ingress Routes to the inet.0 Routing Table
- Multiple-Instance LDP and Carrier-of-Carriers VPNs
- Configuring MPLS and LDP to Pop the Label on the Ultimate-Hop Router
- Enabling LDP over RSVP-Established LSPs
- Enabling LDP over RSVP-Established LSPs in Heterogeneous Networks
- Configuring the TCP MD5 Signature for LDP Sessions
- Configuring LDP Session Protection
- Disabling SNMP Traps for LDP
- Configuring LDP Synchronization with the IGP on LDP Links
- Configuring LDP Synchronization with the IGP on the Router
- Configuring the Label Withdrawal Timer
- Ignoring the LDP Subnet Check
Configuring LDP to Use the IGP Route Metric
Use the track-igp-metric statement if you want the interior gateway protocol (IGP) route metric to be used for the LDP routes instead of the default LDP route metric (the default LDP route metric is 1).
To use the IGP route metric, include the track-igp-metric statement:
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
Preventing Addition of Ingress Routes to the inet.0 Routing Table
By configuring the no-forwarding statement, you can prevent ingress routes from being added to the inet.0 routing table instead of the inet.3 routing table even if you enabled the traffic-engineering bgp-igp statement at the [edit protocols mpls] or the [edit logical-systems logical-system-name protocols mpls] hierarchy level. By default, the no-forwarding statement is disabled.
To omit ingress routes from the inet.0 routing table, include the no-forwarding statement:
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
Multiple-Instance LDP and Carrier-of-Carriers VPNs
By configuring multiple LDP routing instances, you can use LDP to advertise labels in a carrier-of-carriers VPN from a service provider provider edge (PE) router to a customer carrier customer edge (CE) router. This is especially useful when the carrier customer is a basic Internet service provider (ISP) and wants to restrict full Internet routes to its PE routers. By using LDP instead of BGP, the carrier customer shields its other internal routers from the Internet. Multiple-instance LDP is also useful when a carrier customer wants to provide Layer 2 or Layer 3 VPN services to its customers.
For an example of how to configure multiple LDP routing instances for carrier-of-carriers VPNs, see the Multiple Instances for Label Distribution Protocol Feature Guide.
Configuring MPLS and LDP to Pop the Label on the Ultimate-Hop Router
The default advertised label is label 3 (Implicit Null label). If label 3 is advertised, the penultimate-hop router removes the label and sends the packet to the egress router. If ultimate-hop popping is enabled, label 0 (IPv4 Explicit Null label) is advertised. Ultimate-hop popping ensures that any packets traversing an MPLS network include a label.
To configure ultimate-hop popping, include the explicit-null statement:
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
![]() | Note: Juniper Networks routers queue packets based on the incoming label. Routers from other vendors might queue packets differently. Keep this in mind when working with networks containing routers from multiple vendors. |
For more information about labels, see Label Description and Label Allocation.
Enabling LDP over RSVP-Established LSPs
You can run LDP over LSPs established by RSVP, effectively tunneling the LDP-established LSP through the one established by RSVP. To do so, enable LDP on the lo0.0 interface (see Enabling and Disabling LDP). You must also configure the LSPs over which you want LDP to operate by including the ldp-tunneling statement at the [edit protocols mpls label-switched-path lsp-name] hierarchy level:
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
Enabling LDP over RSVP-Established LSPs in Heterogeneous Networks
Some other vendors use an OSPF metric of 1 for the loopback address. Juniper Networks routers use an OSPF metric of 0 for the loopback address. This might require that you manually configure the RSVP metric when deploying LDP tunneling over RSVP LSPs in heterogeneous networks.
When a Juniper Networks router is linked to another vendor’s router through an RSVP tunnel, and LDP tunneling is also enabled, by default the Juniper Networks router might not use the RSVP tunnel to route traffic to the LDP destinations downstream of the other vendor’s egress router if the RSVP path has a metric of 1 larger than the physical OSPF path.
To ensure that LDP tunneling functions properly in heterogeneous networks, you can configure OSPF to ignore the RSVP LSP metric by including the ignore-lsp-metrics statement:
You can configure this statement at the following hierarchy levels:
- [edit protocols ospf traffic-engineering shortcuts]
- [edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts]
To enable LDP over RSVP LSPs, you also still need to complete the procedure in Section Enabling LDP over RSVP-Established LSPs.
Configuring the TCP MD5 Signature for LDP Sessions
You can configure an MD5 signature for an LDP TCP connection to protect against the introduction of spoofed TCP segments into LDP session connection streams.
A router using the MD5 signature option is configured with a password for each peer for which authentication is required. The password is stored encrypted.
LDP hello adjacencies can still be created even when peering interfaces are configured with different security signatures. However, the TCP session cannot be authenticated and is never established.
To configure an MD5 signature for an LDP TCP connection, include the session and authentication-key statement:
For a list of hierarchy levels at which you can include these statements, see the statement summary section for the session statement.
Use the session statement to configure the address for the remote end of the LDP session.
The md5-authentication-key (password) can be up to 69 characters long. Characters can include any ASCII strings. If you include spaces, enclose all characters in quotation marks.
You can also configure an authentication key update mechanism for the LDP routing protocol. This mechanism allows you to update authentication keys without interrupting associated routing and signaling protocols such as Open Shortest Path First (OSPF) and Resource Reservation Setup Protocol (RSVP).
To configure the authentication key update mechanism, include the key-chain statement at the [edit security authentication-key-chains] hierarchy level, and specify the key option to create a keychain consisting of several authentication keys.
To configure the authentication key update mechanism for the LDP routing protocol, include the authentication-key-chain statement at the [edit protocols ldp] hierarchy level to associate the protocol with the [edit security authentication-key-chains] authentication keys.
For more information about the authentication key update feature, see Configuring the Authentication Key Update Mechanism for BGP and LDP Routing Protocols.
Configuring LDP Session Protection
An LDP session is normally created between a pair of routers that are connected by one or more links. The routers form one hello adjacency for every link that connects them and associate all the adjacencies with the corresponding LDP session. When the last hello adjacency for an LDP session goes away, the LDP session is terminated. You might want to modify this behavior to prevent an LDP session from being unnecessarily terminated and reestablished.
You can configure the Junos OS to leave the LDP session between two routers up even if there are no hello adjacencies on the links connecting the two routers by configuring the session-protection statement. You can optionally specify a time in seconds using the timeout option. The session remains up for the duration specified as long as the routers maintain IP network connectivity.
For a list of hierarchy levels at which you can include this statement, see the statement summary section.
Disabling SNMP Traps for LDP
Whenever an LDP LSP makes a transition from up to down, or down to up, the router sends an SNMP trap. However, it is possible to disable the LDP SNMP traps on a router, logical system, or routing instance.
For information about the LDP SNMP traps and the proprietary LDP MIB, see the Network Management Configuration Guide.
To disable SNMP traps for LDP, specify the trap disable option for the log-updown statement:
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
Configuring LDP Synchronization with the IGP on LDP Links
LDP is a protocol for distributing labels in non-traffic-engineered applications. Labels are distributed along the best path determined by the IGP. If synchronization between LDP and the IGP is not maintained, the LSP goes down. When LDP is not fully operational on a given link (a session is not established and labels are not exchanged), the IGP advertises the link with the maximum cost metric. The link is not preferred but remains in the network topology.
LDP synchronization is supported only on active point-to-point interfaces and LAN interfaces configured as point-to-point under the IGP. LDP synchronization is not supported during graceful restart.
To advertise the maximum cost metric until LDP is operational for synchronization, include the ldp-synchronization statement:
To disable synchronization, include the disable statement. To configure the time period to advertise the maximum cost metric for a link that is not fully operational, include the hold-time statement.
For a list of hierarchy levels at which you can configure this statement, see the statement summary section for this statement.
Configuring LDP Synchronization with the IGP on the Router
You can configure the time the LDP waits before informing the IGP that the LDP neighbor and session for an interface are operational. For large networks with numerous FECs, you might need to configure a longer value to allow enough time for the LDP label databases to be exchanged.
To configure the time the LDP waits before informing the IGP that the LDP neighbor and session are operational, include the igp-synchronization statement and specify a time in seconds for the holddown-interval option:
For a list of hierarchy levels at which you can configure this statement, see the statement summary section for this statement.
Configuring the Label Withdrawal Timer
The label withdrawal timer delays sending a label withdrawal message for a FEC to a neighbor. When an IGP link to a neighbor fails, the label associated with the FEC has to be withdrawn from all the upstream routers if the neighbor is the next hop for the FEC. After the IGP converges and a label is received from a new next hop, the label is readvertised to all the upstream routers. This is the typical network behavior. By delaying label withdrawal by a small amount of time (for example, until the IGP converges and the router receives a new label for the FEC from the downstream next hop), the label withdrawal and sending a label mapping soon could be avoided. The label-withdrawal-delay statement allows you to configure this delay time. By default, the delay is 60 seconds.
If the router receives the new label before the timer runs out, the label withdrawal timer is canceled. However, if the timer runs out, the label for the FEC is withdrawn from all of the upstream routers.
By default, LDP waits for 60 seconds before withdrawing labels to avoid resignaling LSPs multiple times while the IGP is reconverging. To configure the label withdrawal delay time in seconds, include the label-withdrawal-delay statement:
For a list of hierarchy levels at which you can configure this statement, see the statement summary section for this statement.
Ignoring the LDP Subnet Check
In Junos OS Release 8.4 and later releases, an LDP source address subnet check is performed during the neighbor establishment procedure. The source address in the LDP link hello packet is matched against the interface address. This causes an interoperability issue with some other vendors’ equipment.
To disable the subnet check, include the allow-subnet-mismatch statement:
This statement can be included at the following hierarchy levels:
- [edit protocols ldp interface interface-name]
- [edit logical-systems logical-system-name protocols ldp interface interface-name]