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.

English  

English

Example: Disabling Normal TTL Decrementing in a VRF Routing Instance

Requirements

Before you begin:

• Configure the router interfaces. See the Network Interfaces Configuration Guide.

Overview

To diagnose networking problems related to VPNs, it can be useful to disable normal time-to-live (TTL) decrementing. The IP header includes a TTL field that serves as a hop counter. At every routed hop, the TTL is decremented by one; if the TTL reaches zero before the packet reaches its destination, the packet is discarded and (optionally) an ICMP TTL exceeded message is sent to the source. MPLS labels also have a TTL field. MPLS routers copy the TTL of an IP packet when it enters a label-switched path (LSP). An IP packet with a TTL of 27 receives an MPLS label with a TTL of 27. Junos OS decrements the MPLS TTL of an MPLS-encapsulated packet in place of the IP TTL, at every label-switched hop. Because the MPLS TTL is copied (or propagated) from the IP TTL, a traceroute lists every hop in the path, be it routed or label-switched. When the packet exits the LSP, the decremented MPLS TTL is propagated back into the IP TTL field.

By default, TTL propagation is enabled. The global no-propagate-ttl statement disables TTL propagation at the router level and affects all RSVP-signalled or LDP-signalled LSPs. When a router acts as an ingress router for an LSP and the router configuration includes the no-propagate-ttl statement, the router pushes an MPLS header with a TTL value of 255, regardless of the IP packet TTL. When a router acts as the penultimate router, it pops the MPLS header without propagating the MPLS TTL into the IP packet. Thus the IP packet TTL value is preserved, regardless of the hop count of the LSP.

Instead of configuring TTL propagation behavior at the router level, you can configure the behavior for the routes in a VRF routing instance. This example shows how to disable TTL propagation for the routes in a single VRF routing instance instead of at the global router level.

The per-VRF configuration takes precedence over the global router configuration. If you disable TTL propagation on the router and explicitly enable TTL propagation for a single VRF routing instance, TTL propagation is in effect for that routing instance. To explicitly enable TTL propagation on a VRF routing instance, include the vrf-propagate-ttl statement in the routing instance.

When you change the TTL propagation behavior, old next hops for VRF routes are deleted from the inet.3 routing table and new next hops are added.

You need only configure the vrf-propagate-ttl or no-vrf-propagate-ttl statement on the ingress routers.

Topology Diagram

Figure 1 shows the topology used in this example. Router PE1 and Router PE2 have two VPNs---VPN-A and VPN-B. Devices CE1 and CE4 belong to VPN-A. Devices CE2 and CE5 belong to VPN-B. In this example, Router PE1 has TTL propagation disabled on VPN-A but not on VPN-B. Packets received by PE1 on the interface connected to CE1 have TTL propagation disabled. This example shows the configuration on Router PE1. You do not need to include the no-vrf-propagate-ttl statement on the egress router (PE2).

Figure 1: Disabling TTL Propagation for a Single VPN

Configuration

CLI Quick Configuration

To quickly disable TTL propagation in a VRF routing instance, copy the following commands and paste the commands into the CLI.

Step-by-Step Procedure

1. Configure the loopback interface.

   [edit]user@PE1# edit interfaces[edit interfaces]user@PE1# set lo0 unit 0 family inet address 10.255.179.45/32 primary user@PE1# exit

2. Configure the routing protocols.

   The internal BGP neighbor address is the loopback interface address of Router PE2 in Figure 1.

   [edit]user@PE1# edit protocols[edit protocols]user@PE1# set mpls interface all user@PE1# set bgp group ibgp type internal user@PE1# set bgp group ibgp local-address 10.255.179.45 user@PE1# set bgp group ibgp family inet-vpn unicast user@PE1# set bgp group ibgp neighbor 10.255.179.71 user@PE1# set ospf area 0.0.0.0 interface fe-1/1/2.0 user@PE1# set ospf area 0.0.0.0 interface fxp0.0 disable user@PE1# set ospf area 0.0.0.0 interface lo0.0 user@PE1# set ldp interface all user@PE1# exit

3. Configure routing policies for VPN-A and VPN-B.

   [edit]user@PE1# edit policy-options[edit policy-options]user@PE1# set policy-statement VPN-A-export term a from protocol ospf user@PE1# set policy-statement VPN-A-export term a from interface ge-1/2/0.0 user@PE1# set policy-statement VPN-A-export term a then community add VPN-A user@PE1# set policy-statement VPN-A-export term a then accept user@PE1# set policy-statement VPN-A-export term b then reject user@PE1# set policy-statement VPN-A-import term a from protocol bgp user@PE1# set policy-statement VPN-A-import term a from community VPN-A user@PE1# set policy-statement VPN-A-import term a then accept user@PE1# set policy-statement VPN-A-import term b then reject user@PE1# set policy-statement VPN-B-export term a from protocol static user@PE1# set policy-statement VPN-B-export term a then community add VPN-B user@PE1# set policy-statement VPN-B-export term a then accept user@PE1# set policy-statement VPN-B-export term b then reject user@PE1# set policy-statement VPN-B-import term a from protocol bgp user@PE1# set policy-statement VPN-B-import term a from community VPN-B user@PE1# set policy-statement VPN-B-import term a then accept user@PE1# set policy-statement VPN-B-import term b then reject user@PE1# set policy-statement bgp-to-ospf from protocol bgp user@PE1# set policy-statement bgp-to-ospf then accept user@PE1# set community VPN-A members target:1:100 user@PE1# set community VPN-B members target:1:200 user@PE1# exit

4. Configure the VPN-A and VPN-B routing instances, including the no-vrf-propagate-ttl statement in VPN-A.

   [edit]user@PE1# edit routing-instances[edit routing-instances]user@PE1# set VPN-A instance-type vrf user@PE1# set VPN-A interface ge-1/2/0.0 user@PE1# set VPN-A route-distinguisher 10.255.179.45:100 user@PE1# set VPN-A interface ge-1/2/0.0 user@PE1# set VPN-A no-vrf-propagate-ttl user@PE1# set VPN-A vrf-import VPN-A-import user@PE1# set VPN-A vrf-export VPN-A-export user@PE1# set VPN-A protocols ospf export bgp-to-ospf user@PE1# set VPN-A protocols ospf area 0.0.0.0 interface ge-1/2/0.0 user@PE1# set VPN-B instance-type vrf user@PE1# set VPN-B interface so-0/1/0.0 user@PE1# set VPN-B route-distinguisher 10.255.179.45:300 user@PE1# set VPN-B vrf-import VPN-B-importuser@PE1# set VPN-B vrf-export VPN-B-export user@PE1# set VPN-B routing-options static route 10.255.179.15/32 next-hop so-0/1/0.0user@PE1# exit

5. Define the local autonomous system.

   [edit]user@PE1# edit routing-options[edit routing-options]user@PE1# set autonomous-system 1user@PE1# exit

6. If you are done configuring the device, commit the configuration.

   [edit]user@PE1# commit

Results

Confirm your configuration by entering the show interfaces, show policy-options, show protocols, show routing-instances, and show routing-options commands.

Verification

• See the TTL Action field in the output of the show route extensive table VPN-A command.
• See the TTL Action field in the output of the show route extensive table VPN-B command.
• On Device CE1, run the traceroute command to Device CE4's loopback address.
• On Device CE4, run the traceroute command to Device CE1's loopback address.