1

I'm looking at some traces where a TTL exceeded in transit ICMP message with ipsrc as mcast is captured. The ICMP message is referencing the original ip header with a correct structure [ipsrc ucast, ipdst mcast, TTL=1]. My only assumption is that the original L3 box is doing a TTL into L3 lookup on a ucast ipsrc address to which it does not provide a gateway - thus when generating the TTL exceeded message (TTL=1) it reverses the ipsrc/ipdst.

Have you ever encountered an ipsrc/ipdst rewrite like this?

Improve this question
6
  • Are you using PIM or are you trying to forward multicast as unicast? Please add relevant configuration details to your question.
    – Zac67 ♦
    Nov 18, 2022 at 19:17
  • The trace is being generated on the IPS when the packet is dropped. The IPS being quite "deep" in the forwarding path - does not help me identify the endhost where the mcast originates or the L3 box which in-answer generates the ICMP message. This is the crux of why my question is so vaguely defined. I cannot really answer if PIM or multicast routing is being utilized (generally it is not), because I cannot identify where the traffic is from - the actual hits on the IPS are with the mcast ipsrc / ucast ipdst, thus are forwarded as ucast traffic in the environment.
    – nseu0
    Nov 18, 2022 at 20:11
  • Where's the problem tracing it back? The traffic originates from the source IP address in the ICMP message's header reference.
    – Zac67 ♦
    Nov 18, 2022 at 21:09
  • Yes right, however, that IP address has no gateway in our environment, thus no arp record, but importantly the IP address matches a summary prefix in our routing tables and this makes my only assumption for now - The original correct mcast (as destination) is sent > an L3 box for some reason does a L3 lookup > TTL check which fails > TTL exceeded message is being generated > L3 lookup gets a match on summary prefix (route towards the IPS) > the L3 box incorrectly uses the original mcast ipdst as ipsrc > ipsrc mcast hit on IPS.
    – nseu0
    Nov 18, 2022 at 21:27
  • Then you'll need to trace the original packet and backtrace using the MAC source address.
    – Zac67 ♦
    Nov 18, 2022 at 21:39

1 Answer 1

Reset to default
1

Multicast groups can only be used as destination addresses, not source addresses. If an application or device is using a multicast group as a source address, it is non-standard and incorrect.

Sending a packet to a multicast (or even unicast) destination where the TTL expires should generate an ICMP timeout with the source address of the device where the TTL expired, and a destination address of the original source address. There will be more information in the ICMP message.

Improve this answer
4
  • In general ICMP time-exceeded isn't sent for forwarded multicast, since multicast doesn't have the same "hard destination" as unicast.
    – Ricky
    Nov 18, 2022 at 19:56
  • yes Ron, I agree with what you stated .. I only wanted to know if anyone encountered a device which would process a TTL exceeded like what i described (the process being incorrect or unexpected is obvious)
    – nseu0
    Nov 18, 2022 at 20:02
  • Such a device is either off-topic here, or there is a bug that needs to be reported for an on-topic device. In neither case can we help. You have not given us the specific device and software, so all we can answer is to the protocol theory.
    – Ron Maupin ♦
    Nov 18, 2022 at 20:06
  • yes I understand, this was more of a shot in the dark - that someone with tens of years of experience could have encountered such buggy behaviors and would point me to a software family or vendor where he seen it etc. (as I cannot identify the device in question)
    – nseu0
    Nov 18, 2022 at 20:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.