Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

Disabling Normal TTL Decrementing

By default, the time-to-live (TTL) field value in the packet header is decremented by 1 for every hop the packet traverses in the LSP, thereby preventing loops. If the TTL field value reaches 0, packets are dropped, and an Internet Control Message Protocol (ICMP) error packet is sent to the originating router.

If the normal TTL decrement is disabled, the TTL field of IP packets entering LSPs are decremented by only 1 on transiting the LSP, making the LSP appear as a one-hop router to diagnostic tools, such as traceroute. Decrementing the TTL field by 1 is done by the ingress router, which pushes a label on IP packets with the TTL field in the label initialized to 255. The label’s TTL field value is decremented by 1 for every hop the MPLS packet traverses in the LSP. On the penultimate hop of the LSP, the router pops the label but does not write the label’s TTL field value to the IP packet’s TTL field. Instead, when the IP packet reaches the egress router, the IP packet’s TTL field value is decremented by 1.

When you use traceroute to diagnose problems with an LSP from outside that LSP, traceroute sees the ingress router, even though the egress router performs the TTL decrement. The behavior of traceroute is different if it is initiated from the ingress router of the LSP. In this case, the egress router would be the first router to respond to traceroute.

You can disable normal TTL decrementing in an LSP so that the TTL field value does not reach 0 before the packet reaches its destination, thus preventing the packet from being dropped. You can also disable normal TTL decrementing to make the MPLS cloud appear as a single hop, thereby hiding the network topology.

• On the ingress of the LSP, if you include the no-decrement-ttl statement, the ingress router negotiates with all downstream routers using a proprietary RSVP object, to ensure all routers are in agreement. If negotiation succeeds, the whole LSP behaves as one hop to transit IP traffic.
  no-decrement-ttl;

  For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

  Note: The RSVP object is proprietary to the Junos OS and might not work with other software. This potential incompatibility applies only to RSVP-signaled LSPs. When you include the no-decrement-ttl statement, TTL hiding can be enforced on a per-LSP basis.

• On the ingress router, you can include the no-propagate-ttl statement. The no-propagate-ttl statement applies to all LSPs, regardless of whether they are RSVP-signaled or LDP-signaled. Once set, all future LSPs traversing through this router behave as a single hop to IP packets. LSPs established before you configure this statement are not affected.
  no-propagate-ttl;

  You can include this statement at the following hierarchy levels:

  • [edit protocols mpls]
  • [edit logical-systems logical-system-name protocols mpls]

  The operation of the no-propagate-ttl statement is interoperable with other vendors’ equipment. However, you must ensure that all routers are configured identically.

  To configure the TTL behavior for a single VRF routing instance, include the no-vrf-propagate-ttl or the vrf-propagate-ttl statement in the routing instance configuration at the [edit routing-instances instance-name] hierarchy level. The no-vrf-propagate-ttl or the vrf-propagate-ttl statement overrides the behavior configured globally for the router. If the router is operating in default mode with normal TTL decrementing, the no-vrf-propagate-ttl overrides the global behavior for the routing instance on which the no-vrf-propagate-ttl statement is configured.