Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Example: Configuring MPLS TTL Propagation for LDP-signaled LSPs

Overview

The following figure depicts a typical scenario in which the no-propagate-ttl statement at the [edit protocol ldp] hierarchy is beneficial.

Topology

In the figure, you can see two native LDP clouds connected by a backbone with LDPoRSVP.

  • From Router R1, packets are encapsulated with the LDP label and sent to the destination R7.
  • On Router R3, the LDP label from a packet is stripped to an IP packet. The packet is then encapsulated with LDP over RSVP (LDPoRSVP) and sent across the backbone.
  • On Router R5, the LDPoRSVP labels are stripped to an IP packet, then the packet is again encapsulated in the LDP label and sent to the destination.

Purpose

The purpose is to do the following actions:

  • Hide the two LDP clouds by using no TTL propagation
  • Unhide the backbone (LDPoRSVP)

When a packet is sent from Router R1 to Router R7, these actions must be performed on two routers, R1 and R5. You cannot achieve this with the existing options. For example, when you use the global option (set protocol mpls no-propagate-ttl) on Router R5, it disables the TTL propagation LDPoRSVP backbone in the reverse direction (R7-R1). This happens because the option is applicable for both LDP and RSVP.

Use Case for the No Propagate TTL and the Propagate TTL behavior at LDP

LDP on Router R3 needs to support both no propagate TTL and the propagate TTL behavior.

From Router R3 with LDPoRSVP, in the R4 direction, the router needs to support the propagate TTL behavior. However, towards the native LDP (Router R2), the LDP needs to support the no propagate TTL behavior.

To achieve this result, we have introduced a new option, no-propagate-ttl under LDP that you need to configure for Router R3 and Router R5. This option disables the propagation of TTL for LDP paths.

In an LDPoRSVP scenario, propagation behavior depends on the RSVP no decrement TTL (no-decrement-ttl) option.

  • If you configure the no-propagate-ttl option in the LDPoRSVP scenario, and the no decrement TTL (no-decrement-ttl) is not configured, then the TTL propagation takes place.

    For example:

    On Router R3, in the case of the LDPoRSVP scenario, if you set the following configuration, then TTL propagation takes place.

  • If you configure the no-decrement-ttl option over the LSP between Router R3 and Router R5, then the TTL propagation is disabled.

    For example, on Router R3:

On Router R1, packets are encapsulated with the LDP label with TTL 255, as any of the no-propagate-ttl CLI is configured.

On Router R3:

  • The LDP label from a packet is stripped to an IP header, and the TTL is not copied from the LDP label to the IP header.
  • The packet is encapsulated with LDPoRSVP labels and sent across the backbone.
  • The new option ldp no-propagate-ttl with no-decrement-tll decides whether the TTL should be propagated or not.
  • The no-decrement-ttl option is not configured, so the usual TTL propagation occurs

On Router R5, the LDPoRSVP labels are stripped to the IP header. The new option is configured to support no-propagate-ttl for LDP protocol, and the IP packet is encapsulated with an LDP label with TTL 255 and sent across.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Results

We have modified the output of CLI command show ldp overview to display the TTL configuration.

Check the results of the configuration: