10-15-2014 07:43 AM - edited 03-04-2019 11:58 PM
Hi,
This question has been asked before but I couldn't find a definitive solution to the issue (CISCO suggestion was to increase TTL on the sender side).
I have incoming multicast packets with TTL=1 from a third party station/applications. I cannot change the sender/applications on the remote station to increase the TTL but I must route the multicast UDP packets through my CISCO series 2900 (T15) for valid reasons.
Is it possible to configure the CISCO to do that ?
I tried to:
- Create extended ACL and set permit for ttl eq 1 but that didn't worked.
- Set class/policy-mapping and relax cef-restriction but that didn't worked neither.
I was considering creating a GRE tunnel between ingress and egress interfaces but not sure how that would work. Also I am exploring MPLS.
Any help will be appreciated.
Robert Le Van Mao
Solved! Go to Solution.
10-15-2014 08:51 AM
Unfortunately, no.
I've been looking for a solution for this for some time, but the problem is this:
When a packet is received on an interface, one of the very first things that happens is decrementing the TTL. If the TTL is 0 at this point, the device drops the packet with no further processing. This is a very low-level process and occurs before any other kind of packet processing takes place, so ACLs and policies will never see it.
The only solution I have been able to come up with is to eliminate the IP processing for these packets and bridge them to their final destinations. MPLS L2TPv3 pseudowires might work in this case, but the challenge is in moving only the packets that you want without having to bridge everything.
The short answer is that it can't be done with routing.
10-15-2014 08:51 AM
Unfortunately, no.
I've been looking for a solution for this for some time, but the problem is this:
When a packet is received on an interface, one of the very first things that happens is decrementing the TTL. If the TTL is 0 at this point, the device drops the packet with no further processing. This is a very low-level process and occurs before any other kind of packet processing takes place, so ACLs and policies will never see it.
The only solution I have been able to come up with is to eliminate the IP processing for these packets and bridge them to their final destinations. MPLS L2TPv3 pseudowires might work in this case, but the challenge is in moving only the packets that you want without having to bridge everything.
The short answer is that it can't be done with routing.
10-15-2014 10:15 AM
Hi Jody,
Thanks for the reply. I am wondering if you tried the MPLS L2TPv3 pseudowires solution that you suggested.
Also, if yes, could you please give an example/snippet on how to configure the 29K to move multicast UDP with TTL=1 using MPLS (consider me a noob on that router :)?
For now, I am just interested in a very specific multicast group (239.4.X.X) and non-reserved port (N). Just want to see the packets make it through the egress.
10-15-2014 12:14 PM
I haven't and only mentioned them because you were considering MPLS. Essentially, the pseudowires allow for bridged connections across an MPLS infrastructure.
The problem we still run into is that you want to bridge only the multicast group and nothing else. Bridging (whether using pseudowires or not) is an all-or-nothing thing.
10-16-2014 07:36 AM
Again thanks.
And the answer to my initial question seems to be ... unfortunately no (paraphrasing).
I have to deploy a laptop at router 1 with an apps to boost the TTL. This solution sucks but this is the best that I can have for now.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide