TTL Handling

In some cases you want to hide your mpls backbone to your vpn customers and  prevent traceroutes (…and annoying questions….). There are some options to achieve this.

First of all tell your customers they don’t have to do this. Yes, and they will do it 😉

Think about it, you can configure a RE firewall filter and filter all traceroute traffic. Really? No, we don’t want additional host-bound traffic which we than drop by a firewall rule, thats stupid and wasting of ressources.

The best option will be the prevention of ttl handling during the mpls push/pop operations on the ingress or egress PE. You customer can decrease the ttl value as he like, but the value won’t get copied into the mpls header. The TTL value in the mpls header will be fixed on 255 on ingress PE.

There are two options in JunOS:

no-decrement-ttl – This is only valid for RSVP LSPs and signaled as OBJC_LABEL_REQUEST per LSP. This is not clearly stated on Juniper command description, but here. However this is a proprietary value. From my point of view, this wouldn’t be the best way to do this.

no-propagate-ttl – This is usual option for changing the ttl behavior. The ttl value of the ip packet won’t get copied into the ttl field of the mpls header on ingress and egress PE.

You can configure no-propagate-ttl on a global level:

protocols {
    mpls {

Or per VRF:

routing-instance {
    your-vrf-name {
        no-vrf-propagate-ttl;               # or "vrf-propagate-ttl"

VRF is more specific, so for e.g. you can disable ttl propagation globally and enable it on a single VRF if needed.

You can verify the ttl opration on every vpn prefixes in your VRF routing table:

admin@router> show route table <your-vrf-name> <vpn-prefix> extensive
Label TTL action: no-prop-ttl

You can see the options no-prop-ttl or prop-ttl.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.