I always believed that a network node listen and accept multicast frames on a NIC only if the Kernel/OS is also listening to those specific groups. But seems not true for most of Cisco routers - and for a good reason.
On IOS-XR 4.2.3:
RP/0/RP0/CPU0:node1#<strong><strong>show controllers tenGigE 0/2/0/4</strong></strong> ... MAC address information: Operational address: 6400.f10e.1fc7 Burnt-in address: 6400.f10e.1fc7 No unicast addresses in filter <strong>Operating in multicast promiscuous mode </strong>
XR tells us that on a Ethernet level it will accept any kind of multicast frame. This choice is to prevent ethernet drivers to overload performances and so delegate any MC decision to Kernel/OS based on L3 information.
Another reason why NIC drivers may want to accept any multicast frame is because of the L2 to L3 ambiguous mapping.
As you can see, 5 upper bits are lost in the mapping and resulting MAC address address is not unique. This lead to 32 IPv4 multicast addresses mapped to the one Ethernet multicast address. Since we have potential ambiguity at L2, it is preferred to take any decision at the IP layer, which is aware of the exact information (IGMP/PIM membership, MRIB and so on).
2da5b52 @ 2019-07-20