I recently spent quite amount of time, in a pre production lab, investigating a multicast issue where the traffic was broken between the first-hop router (the one right after the source) and its next-hop towards the receiver. The MC stream was generated by a video application on a Linux server, and then eventually, after trying almost everything (TTL checking as well), I decided to start the same flow from a different application. And this new stream worked right away.
So what was wrong with first failing application data stream?
Let’s capture directly on the source (since is Linux box in this case , tcpdump is a must) and then compare the two .pcap. Indulging on the ethernet header I noticed two different destination mac addresses: one containing a proper reserved L2 multicast address , and one the mac address of the default gateway - not hard to guess which one has problems.
Beside the fact that sending IP multicast traffic over Ethernet unicast is against IETF/IEEE specification, this could also break most of routers MC forwarding mechanism.
Routers expect ingress MC to have a mapped L2 destination address, in the range of 0100.5e00.0000 through 0100.5e7f.ffff, in order to handle switching properly and fast (and through hardware ASIC).
If MC traffic has the gateway’s mac address destination, than it has to be process switched by the router and most likely fail due to unsupported forwarding architecture.
Having correct multicast encapsulation helps a switch to perform at wire speed, since it understands when a frame is either unicast or multicast by looking at one single bit in the left most Ethernet header (well explained here by Brad Hedlund).
ac41a23 @ 2019-11-20