ttl issue across tunnel interfaces

Unanswered Question
Nov 14th, 2008
User Badges:

I have a lot of environments in which a server in a central office send multicast traffic to one or several remote offices. These remote offices are connected across aframe relay network. Multicast server sends always multicast traffic with minimum ttl required = 3.

Well, now we are involved in a migration planning from frame-relay to metroeth/MPLS network in which we are using tunnel interfaces across this network. Now central offices and remote offices are connected across tunnel interfaces. After to migrate some remote offices, we noticed this multicast application stopped to work in some of them.

I have been investigating obtaining multicast packet debugs in central office and remote office, and I have found in these remote offices that remote router decreases 2 in ttl, not 1. Take a look to this sample. This is a packet obtainted from central router in which you can see ttl=4

Nov 14 12:39:54: IP(0): IP tos=0x0, len=33, id=24102, ttl=4, prot=17

Nov 14 12:39:54: IP(0): s= (FastEthernet0/1) d= (Tunnel3)

id=24102, prot=17, len=33(33), mforward

On , in remote office we might see a ttl=3 for the same packet, but...

Nov 14 12:39:54: IP(0): IP tos=0x0, len=33, id=24102, ttl=2, prot=17

Nov 14 12:39:54: IP(0): s= (Tunnel3) d= (Ethernet0/0) id=

24102, prot=17, len=33(33), mforward

You can see a TTL=2 ¿¿??. Remember these routers are directly connected across tunnel interface. Can you help me to troubleshoot why this ttl is wrong?.

I have tested to go back to initial situation with frame-relay, and ttl is decreased 1

I have tested too configuring tunnel interface across frame-relay network and ttl is decreased 2

We can workaroung this issue increassing ttl from 3 to 4 or 5, but we want understand why we see this behavior.


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
owillins Thu, 11/20/2008 - 07:33
User Badges:
  • Silver, 250 points or more

TTL is decreased on GRE IP header, not original packet IP header. That is the reason you see the original TTL after "packets gets out of a tunnel".


This Discussion