topic Re: IGMP Snooping with SJA1110 in Other NXP Products

IGMP Snooping with SJA1110

sg_cnh — Wed, 05 Nov 2025 22:24:30 GMT

Hello,

I have an S32G with SJA1110 running bsp43 and am trying to enable IGMP snooping to dynamically route multicast streams. I have identified a few unique issues related to IGMP which I am not sure how to resolve. I have confirmed that disabling IGMP snooping causes multicast packets to flood the switch, so the IGMP snooping option is doing something... Just not the expected behavior.

Multicast traffic is always forwarded to the lowest enumerated active port
1. A stream egressing on port 4 with a node on port 3 requesting that traffic through IGMP will cause traffic to egress through port 1 (if that link is active) as if port 1 had requested the traffic. If the port 1 link is not active, traffic will be forwarded to port 2 if that link is active.
2. I am able to manually route the traffic with mdb, but my expectation is that IGMP snooping should be managing this automatically
Enabling multicast-querier does not cause membership queries to egress the switch ports
1. There are IGMP queries on the DSA bridge interface, but no IGMP queries are visible on other links connected to the switch
2. I suspect I may need to set up a tc rule to trap IGMP queries from the bridge port and redirect them to the switch ports?

I'm not clear if this is some issue with Linux configuration or a limitation from switch hardware.

Thanks for any suggestions.

Re: IGMP Snooping with SJA1110

sg_cnh — Mon, 02 Feb 2026 15:20:00 GMT

NXP has not responded to my support tickets and this post has also not been responded to, so I shall document what I've found here.

On BSP43. The SJA1105 DSA driver does not appear to support IGMP snooping for the SJA1110 when the ports are linked by a bridge. During driver setup, the sja1110 ports are setup in standalone mode where the dsa `tag_8021q` installs a different vlan-lookup rule on each port of the switch. The vlan-lookup rules tag ingress packets with the `tag_8021q` ethertype `0xDADB` and a vlan with metadata including the port ID. This creates a mechanism for the host processor to know which ports a packet was received from, and also egress packets on specific ports. When the ports are linked in a bridge, `tag_8021q` replaces the per port vlan-lookup rules with a single rule which is associated with the bridge. The host processor now not able to tell which port packets originated from and is not able to egress packets to specific ports. I believe using `vlan-filtering` will also break this mechanism as described here (the sja1110 is evidently of the second type because it calls `dsa_tag_8021q_bridge_join`).

IGMP querier packets created by the host processor are still tagged with the per port vlan, but the vlan-lookup only contains rules for the bridge so the IGMP querier packets are sent out into the void. They are thrown into the trash. They do not egress the switch. This behavior can be changed by modifying this line:

if (!dp->bridge) { tx_vid = dsa_tag_8021q_standalone_vid(dp); } else { tx_vid = dsa_tag_8021q_bridge_vid(dp->bridge->num); }

IGMP querier messages will now egress the switch, but this alone will not enable IGMP snooping because the host processor doesn't know what port the IGMP join/leave was received on because the `tag_8021q` is still bridge wide, not port specific. The switch must trap packets and apply the native sja1110 tag (ethertype 0xdadc) in order to enable IGMP snooping. The switch can trap packets and add the tag through the two `mac_fltres`, but the driver already uses these for PTP and STP. The userspace utility `tc` can be configured to trap packets, but this is implemented through virtual links which do not add the tag to trapped packets. The last two options are to use an l2-lookup or deep packet inspection. The l2-lookup can be used to enable IGMPv3 by trapping destination mac address 01:00:5E:00:00:16 with the trap bit set. This will also match any multicast IP group ending in *.0.0.22 and so is not a good solution. Deep packet inspection seems to be the only way to enable IGMP snooping when using a bridge. Whatever trapping mechanism is used, this commit is necessary or the sja1110 tag will be overwritten by the `tag_8021q` which again only represents the bridge.

Re: IGMP Snooping with SJA1110

sg_cnh — Wed, 04 Feb 2026 14:09:22 GMT

Note that the solution suggested above will send an IGMP query for each DSA port on the bridge... Reinstalling the vlan-lookup rules to egress the packets out of the correct ports could also be a solution, but I think port 0 would conflict with the vlan-lookup installed by the bridge, so also not a good solution. Sending too many IGMP queries doesn't seem to have any side effects beyond the additional traffic.