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=18.104.22.168 (FastEthernet0/1) d=22.214.171.124 (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=126.96.36.199 (Tunnel3) d=188.8.131.52 (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.