GMRP Multicast Registration: Join, Leave and IGMP Differences

Why multicast traffic should not be sent to every terminal

Multicast is used to deliver one copy of a service to a group of receivers that need it. In an industrial network there may be video, status distribution, or other multicast applications; if the switch does not know which ports need the corresponding destination address, it may, according to the device policy, copy the traffic to a larger range. GMRP is a Layer 2 multicast registration mechanism that helps participating devices maintain the relationship between multicast MAC addresses and the relevant outgoing ports. It is not a technology for increasing optical port speed.

First distinguish multicast from broadcast. Broadcast faces the relevant devices within the same broadcast domain, while multicast uses a group address to represent a group of receivers; the two are not the same destination address. Multicast being copied to multiple ports does not mean the packet has become broadcast. When you want to limit unnecessary traffic, you should first confirm what address the service uses, how the terminals join, and which membership management method the switch supports.

The registration table is different from an ordinary MAC learning table

Ordinary unicast address learning mainly records “which port the source MAC entered from.” GMRP, however, is based on the GARP generic attribute registration framework, letting participating devices declare the multicast MAC attributes that need to be registered, and establishing relevant forwarding information accordingly. The GARP application that registers multicast is called GMRP, while GVRP, which registers VLANs, is another application; when names look similar, one function must not be treated as the other.

Suppose the multicast source is on the S1 side and the receiving terminal is connected through S3, with S1, S2, and S3 forming a switching chain. Registration information propagates along the participating devices, helping upstream devices know which direction still has a need; multicast data is then sent from the source along the arranged outgoing ports. Control packets update the forwarding basis, while service packets carry the video or data. The direction and purpose of the two kinds of packets should be observed separately.

How Join and Leave change outgoing ports

Join indicates that the relevant attribute needs to be registered, and participating devices maintain information and propagate it according to their own state and protocol rules. Leave expresses the intention to deregister the relevant attribute, but it cannot be understood as “as soon as one terminal leaves, the entire branch immediately cuts off all receivers.” Other participating entities may still need that group, and the deregistration process needs to wait and reconfirm according to the mechanism, avoiding directly deleting forwarding needs that are still valid.

LeaveAll provides an opportunity to re-register once, helping clean up old attributes that no longer have valid participants. It is different from the IP membership query sent by a querier in IGMP, and GMRP must not be written as exactly the same query-and-response protocol. The relevant timing mechanisms affect declaration, merged transmission, and deregistration waiting. Parameter ranges and default values are determined by the implementation; fixed millisecond values in old interfaces cannot be applied to all models.

Adjust timing only after understanding the mechanism. Overly aggressive deregistration may cause traffic interruptions, while waiting too long may delay cleanup. A stable baseline should first be established using default supported configurations, and controlled adjustments should be made only when clearly needed and supported by documentation; do not set all periods to the minimum just to be “faster,” and do not equate registration convergence time with application recovery time.

IGMP Snooping and GMRP cannot be freely interchanged

IGMP is used for IPv4 multicast membership management, and an IGMP Snooping switch maintains Layer 2 outgoing ports by observing the relevant messages. GMRP registers multicast MAC attributes and requires the corresponding endpoints or switching devices to participate. A terminal only sending IGMP does not prove that it will also generate GMRP registrations; merely enabling GMRP also does not guarantee that an existing IP video system will immediately limit copying as expected.

If some devices do not support the selected dynamic registration mechanism, static multicast tables or other methods need to be evaluated according to the model’s supported range, and their relationship with the current VLAN and links must be checked. The handling of unregistered multicast, control packet filtering, and the priority of static and dynamic tables may differ. “No table entry” cannot be uniformly interpreted as dropping or flooding to all ports; it should be confirmed through the specific manual and testing.

Old protocols and later registration frameworks should be checked separately

IEEE 802.1ak replaces the GARP registration framework with MRP, and the corresponding later MAC registration mechanism MMRP and GMRP are not merely different by one spelling.

Protocol registration also does not provide service encryption or strong terminal identity authentication. If external devices can inject registration information, management boundary problems increase. Limit participating ports and functions according to project needs, and keep records of static configurations and dynamic changes; functions that are not needed can be disabled according to local requirements, rather than enabling everything to make the feature list look good.

How to put FCTEL M12 devices into the solution

The FCTEL product 3187 M12 IP68 managed 16-port gigabit electrical switch page lists both GMRP and IGMP Snooping V1/V2/V3. It provides public evidence for two functional directions, but it does not prove that terminals automatically support them, nor does it prove that the two kinds of table entries can be mixed unconditionally. In practice, firmware, participating ports, VLANs, table capacity, and unregistered traffic handling should be checked.

The M12 connection form is suitable for corresponding mechanical and environmental requirements, while multicast registration solves the packet outgoing port problem; the two do not have an automatic causal relationship. It is also necessary to calculate the total traffic of video sources, shared uplinks, replication outgoing ports, and fault detour load. Limiting unnecessary ports can reduce useless traffic, but it will not increase the capacity of a single link, nor can it replace queue, bandwidth, or loop protection design.

Verify with membership changes, not just by looking at the switch

In an isolated test network, establish one multicast source and a clearly defined receiver, check whether registration information appears in the expected VLAN and port, and then observe the actual data outgoing ports. Add a second receiver, remove the first, and confirm that the branch still needed is not incorrectly removed; after all have left, check deregistration and unregistered traffic handling. Record control messages, table entries, port counters, and application results each time.

For the formal site, keep a list of topology, protocols, and firmware, and separately test normal membership changes and approved link fault recovery. Video displaying only proves the current received service; it does not prove that unrelated ports are not receiving copies; the existence of a table entry also does not prove that data has reached the correct application. The role of GMRP should be explained by controlled registration and reviewable outgoing-port evidence, and “enabled” cannot replace complete multicast acceptance.

Translated from the Chinese technical article. Source first published: 2022-11-24. Source last revised: 2026-10-13. Read the Chinese source