Applies to: GigaCore Gen2 switches running firmware v1.9.0 or later. The drop_igmp and drop_mld API parameters described in this article are not available on earlier firmware versions.

Overview

GigaCore switches support IGMP snooping to efficiently deliver multicast traffic. However, each switch has a finite Multicast Forwarding Database (MFDB) that limits the number of simultaneous multicast flows it can track. In large installations — such as stage or broadcast networks using thousands of sACN universes — this limit can be reached.

Gen2 GigaCore switches have 1024 MFDB entries, but note that some of those are already reserved by fixed registrations. GigaCore O26-I has 4096 MFDB entries.

GigaCore v1.9.0 introduces new API parameters (drop_igmp and drop_mld) that, combined with a carefully designed core–leaf topology, allow a single network to support far more multicast flows than any individual switch could handle alone.

Currently, most use cases involve a large number of IPv4 multicast flows, so the article is mainly based around IGMP. However, the same design and configuration can be used for IPv6 flows with MLD.

A typical use case is a network carrying thousands of sACN universes to lighting fixtures and/or LumiNode’s.

How It Works

The solution divides the network into two functional layers for the affected VLAN group(s):

With IGMP snooping disabled on the core and IGMP/MLD packets actively dropped (not forwarded between branches), each leaf switch independently manages its own set of multicast subscriptions. The total number of simultaneous flows across the network becomes the sum of what all leafs can handle individually, not what a single switch can handle.

A branch can consist of one or more switches. The switch connected to the core should be configured as the IGMP querier for the affected group in that branch. Inside a branch, IGMP will behave like in a normal IGMP network.

Example

This example network consist of 1 Core switch and 3 branches.
The red group is used for sACN traffic with 1000+ universes total, but each branch will use maximum 900 universes. This red group will be configured in core-leaf design.
The yellow group is used for MA3 data, to show that other multicast can still be used in other groups.

Requirements and Constraints

Read this section carefully before designing a network using this topology. Several constraints apply that do not exist in a standard snooping-based network.

• Multicast sources must be connected to the core, not to any branch switch. Traffic flows outward from the core to all branches.

• Receivers connect to branch switches only. Branches receive all multicast from the core and filter it locally based on IGMP subscriptions from their connected devices. Devices connected to the core inside the affected group will receive all multicast data, which can cause issues.

• Branches must not be connected to each other. Inter-branch links would allow IGMP queries or reports to leak between branches, undermining the isolation that makes this design work. Inside a branch, redundant connections can be used together with RSTP/RLinkX can be used to have redundancy.

• Core uplink bandwidth must cover total multicast bandwidth. Because multicast is flooded unconditionally to all branches, every branch receives all streams and its up to the querier inside the branch to filter according to what is needed. For example: with 9,000 sACN universes (~2 Gbps total), each uplink from the core to a branch must be capable of carrying the full 2 Gbps.

• Per-branch MFDB limit still applies. The number of multicast streams that can be subscribed to within a single branch is still bounded by the MFDB size of the IGMP querier in that branch. This topology distributes the load across multiple queriers, but does not eliminate the per-switch limit.

• Multicast MAC address collisions. A single multicast MAC address can map to multiple IP multicast addresses. With thousands of multicast groups, the likelihood of collisions increases. Carefully plan the IP multicast address range to minimise this risk.

Araneo Health Check Notices

Because each branch as an independent IGMP network for the affected group, with its own querier, Araneo will detect multiple queriers in the network and raise health check items. This is expected behaviour in this topology and does not indicate a fault. The items can be ignored once the design is understood and validated.

Because the IGMP settings differ between core and leave switches, Araneo will also flag inconsistent group settings. This is also expected behaviour in this topology and does not indicate a fault.

Configuration

Step 1 — Design your group

Identify the VLAN group(s) that carry the high-density multicast traffic. Configuration is applied per group. Other groups in the network are unaffected and continue to use standard IGMP snooping, but keep in mind that multicast in these other groups will also contribute to MFDB usage.

Step 2 — Configure branch switches IGMP settings

Branch switches use standard IGMP snooping configuration. Use Araneo software or the web interface to configure for the multicast group:

• “Snooping” enabled

• “Unknown flooding” disabled

If a branch switch has previously acted as a core switch and was not reset, ensure using API that drop_igmp and drop_mld are set to false. If necessary, follow the instructions in step 4 to change these parameters.

Step 3 — Configure the first switch in each branch as IGMP querier

Inside each branch, the switch that is connected to the core has to be the IGMP querier. This can be done inside Araneo or the web interface by configuring those switches:

• “Querier” enabled

• “Querier IP address”: ‘Primary’ IGMP address.

Step 4 — Configure the core switch via the API

On each core switch, set the target group to disable IGMP snooping and enable IGMP/MLD packet dropping. This can be done using the GigaCore REST API, available at:

Send a PUT to the group endpoint /api/groups/group/<group_id>/igmp with the following IGMP settings:

1. {

2. "snooping": false,

3. "drop_igmp": true,

4. "drop_mld": true,

5. "querier": false,

6. "unknown_flooding": true

7. }


Effect of these paramaters:

1. Snooping set to false: Multicast is flooded to all ports in the group — all branches receive all streams.
   
2. drop_igmp set to true: IPv4 IGMP control packets are dropped at the core and not forwarded between branches.
   
3. drop_mld set to true: IPv6 MLD packets are dropped at the core and not forwarded between branches.
   
4. querier set to false: The core switch does not act as an IGMP querier for this group. Is ignored anyway since snooping is disabled.
   
5. unknown_flooding set to true: Ensures multicast with no snooping entry is flooded (consistent with snooping disabled)

The drop_igmp and drop_mld parameters are new in GigaCore firmware v1.9.0. They instruct the switch to actively drop IGMP/MLD control packets rather than simply ignoring them. This is necessary because disabling snooping alone does not prevent IGMP queries from one branch reaching another.

Extended Topology: Branch Networks

In the basic design, each branch is a single switch. For larger deployments, a branch can itself be a small network of switches — forming a two-tier leaf structure.

When using extended branch networks, note the following:

• The switch(es) in each branch that connect directly to the core should be designated as the IGMP querier(s) for that branch. Use primary/secondary querier configuration where available to ensure a single active querier per branch.

• Only the direct-to-core uplinks in a branch need to carry the full multicast bandwidth. Downstream links within the branch only carry streams that have active subscriptions.

• Switches deeper in a branch network (not directly connected to the core) will only receive traffic for which a downstream subscription exists — this reduces bandwidth on inner-branch links.

• The total number of subscriptions across the entire branch must not exceed the MFDB capacity of the branch querier.

Summary: When to Use This Design

Condition	Recommendation
Fewer than ~1,000 multicast flows across all groups	Use standard IGMP snooping — simpler and fully supported by Araneo
1,000–10,000+ multicast flows (e.g. sACN at scale)	Use core–leaf design with drop_igmp/drop_mld on core switches.
Sources spread across multiple locations	Not directly supported — all sources must connect to core switches. Data from sources connected in branches will not be able to reach other branches. Depending on the application, the Luminex LumiCore with Advanced Networking configured can be an alternative solution.
Mixed traffic (some VLANs normal, some high-density)	Supported — apply this configuration only to the affected group(s)

API-only configuration: The drop_igmp and drop_mld parameters cannot currently be set from the GigaCore web interface. They must be configured via the REST API using the built-in REST client at http://<SWITCH_IP>/__rest-client.html.