IGMP Proxy

IGMP Proxy

IGMP Proxy provides a simple mechanism for forwarding multicast traffic across network boundaries without the complexity of full multicast routing protocols like PIM-SM. In RouterOS, the IGMP proxy operates by learning group memberships from downstream interfaces and propagating IGMP messages toward upstream interfaces, enabling service providers to deliver IPTV and other multicast streams through simple router configurations.

The proxy approach is particularly well-suited for scenarios where the upstream network does not support multicast routing protocols but does understand IGMP, such as many commercial IPTV deployments. By terminating IGMP on the router and re-originating requests upstream, the router can bridge multicast between network segments while maintaining proper group membership tracking.

RouterOS implements IGMP Proxy in accordance with RFC 4605, supporting both IGMPv2 and IGMPv3 for IPv4 multicast, and MLDv1/MLDv2 for IPv6 multicast. The implementation maintains a Multicast Forwarding Cache (MFC) that tracks active multicast streams and their downstream receivers, enabling efficient packet replication only to interfaces with active subscribers.

Summary

The IGMP Proxy feature in RouterOS provides a lightweight alternative to full multicast routing protocols for networks where simple multicast forwarding is required. Unlike PIM-SM, which requires complex RP election, bootstrap mechanisms, and neighbor discovery, IGMP proxy requires only basic interface configuration to establish multicast connectivity.

The proxy operates with two distinct interface roles. Upstream interfaces connect toward the multicast source and receive the actual multicast data streams. Downstream interfaces connect toward subscribers who request specific multicast groups. The router monitors IGMP membership reports on downstream interfaces and sends corresponding IGMP queries toward the upstream interface, creating a unidirectional proxy relationship that enables multicast data to flow from source to receivers.

Key capabilities include automatic group membership tracking, querier election on downstream interfaces, and static MFC entries for predictable multicast behavior. The implementation supports both Layer 2 bridging and Layer 3 routing modes, allowing deployment in various network topologies including pure bridged environments, routed networks, and combinations thereof.

This documentation covers IGMP proxy configuration, interface settings, troubleshooting procedures, and practical deployment scenarios for IPTV and other multicast applications.

How IGMP Proxy Works

Understanding the IGMP proxy operation requires familiarity with how IGMP manages group membership on local network segments and how the proxy translates between downstream subscriber requests and upstream source discovery.

Interface Roles

The IGMP proxy distinguishes between upstream and downstream interfaces based on their role in the multicast distribution tree. The router can have exactly one upstream interface that connects toward multicast sources, while downstream interfaces serve local subscribers requesting multicast content.

When the router receives an IGMP membership report from a downstream interface, it adds the requesting interface to the Multicast Forwarding Cache entry for that group. Simultaneously, the router sends a corresponding IGMP membership report toward the upstream interface, signaling interest in receiving that multicast stream. When all downstream members for a particular group leave, the router sends an IGMP leave message upstream to terminate the stream.

The upstream interface does not generate IGMP queries itself; it responds to queries received from the upstream network. This reflects the hierarchical nature of the proxy relationship where the router acts as a single subscriber toward upstream providers while serving as a multicast router toward downstream clients.

Multicast Forwarding Cache

The Multicast Forwarding Cache (MFC) maintains the state necessary for forwarding multicast packets. Each MFC entry contains the multicast source and group address, a list of downstream interfaces with active members, and statistics about packet forwarding. The router uses MFC entries to determine where to replicate incoming multicast packets.

MFC entries are created dynamically as IGMP membership reports are received on downstream interfaces. The router also supports static MFC entries for scenarios requiring predictable multicast behavior or when testing configurations without live subscribers. Static entries remain in the cache permanently and take precedence over dynamically learned entries.

The MFC can be inspected using the /routing igmp-proxy mfc command, which displays all active multicast flows and their associated interfaces. This visibility is essential for troubleshooting multicast forwarding issues.

Querier Election

On downstream interfaces, multiple routers may compete to be the IGMP querier responsible for periodically sending general queries to discover group members. RouterOS implements standard querier election based on IGMPv2 rules: the router with the lowest IP address becomes the querier, and all other routers become non-queriers.

The querier sends periodic general queries at the configured query interval, and hosts respond with membership reports for any groups they wish to join. Non-queriers listen for membership reports and maintain their own MFC entries based on reports they observe, but do not send queries themselves.

If the querier fails to send queries within the configured timeout period, remaining routers initiate a new querier election. This provides resilience in networks with multiple IGMP-capable devices.

Configuration

IGMP proxy configuration in RouterOS involves enabling the feature, defining interfaces with appropriate roles, and adjusting parameters for specific deployment requirements.

Enabling IGMP Proxy

The IGMP proxy feature is enabled globally with a single command:

/routing igmp-proxy enable

After enabling, interfaces must be configured with their proxy role to establish the multicast forwarding topology.

Interface Configuration

Each interface participating in IGMP proxy requires explicit configuration to define its role in the proxy topology:

/routing igmp-proxy interface add interface=ether1 upstream=yes
/routing igmp-proxy interface add interface=ether2 upstream=no

The upstream parameter distinguishes the single upstream interface from all downstream interfaces. Only one interface can be configured as upstream; attempting to configure multiple upstream interfaces results in an error.

Interface configuration includes several parameters that control IGMP behavior on that segment:

Parameter	Description
interface	Name of the interface to configure
upstream	Whether this interface connects toward the multicast source
threshold	Minimum TTL required for multicast packets to be forwarded
alternative-subnets	Additional subnets from which to accept IGMP membership
query-interval	Interval between IGMP general queries (downstream only)
query-response-interval	Maximum time for hosts to respond to queries
last-member-interval	Time between repeated membership queries before group removal
robustness	Variable that compensates for unreliable networks

Complete Configuration Example

A typical IPTV deployment with the router between an ISP’s multicast source and local subscribers:

/routing igmp-proxy enable

/routing igmp-proxy interface add interface=ether1 upstream=yes

/routing igmp-proxy interface add interface=bridge-local upstream=no

/routing igmp-proxy interface set [find upstream=yes] query-interval=3125

This configuration enables IGMP proxy, sets ether1 as the upstream interface toward the ISP, configures the local bridge as downstream for subscribers, and adjusts the query interval to 3125 centiseconds (approximately 31 seconds) for more responsive group membership tracking.

Alternative Subnets

In some deployments, the downstream network may contain hosts on multiple IP subnets, and IGMP membership reports may arrive from addresses not matching the interface’s primary subnet. The alternative-subnets parameter allows specifying additional prefixes that should be accepted:

/routing igmp-proxy interface set [find upstream=no] alternative-subnets=10.20.0.0/16,192.168.100.0/24

This allows IGMP membership from hosts in the 10.20.0.0/16 and 192.168.100.0/24 subnets to be accepted on the downstream interface.

Troubleshooting

IGMP proxy issues typically manifest as multicast streams not reaching subscribers, or streams arriving at subscribers who have not requested them. Systematic diagnosis requires checking multiple components.

Verifying Interface Status

Confirm that interfaces are configured correctly and are operationally active:

/routing igmp-proxy interface print

This command shows all configured interfaces, their upstream/downstream status, and whether they are enabled. Verify that exactly one interface shows upstream=yes and that all expected downstream interfaces are present.

Checking the Multicast Forwarding Cache

The MFC displays all currently active multicast streams and their downstream interfaces:

/routing igmp-proxy mfc print detail

For each multicast group, verify that the expected downstream interfaces are listed. If an expected group is missing entirely, subscribers have not successfully sent membership reports. If the group exists but is missing an interface, that interface’s IGMP membership may not have been learned.

Capturing IGMP Traffic

Use packet sniffing to observe IGMP messages on an interface:

/tool sniffer quick protocol=igmp interface=ether2

This reveals membership reports, leave messages, and queries flowing on the interface. Verify that:

• General queries arrive on downstream interfaces (from the querier)
• Membership reports are sent when subscribers join groups
• Leave messages are sent when subscribers leave groups

Common Issues

Multicast stream not arriving on downstream interface

1. Verify the upstream interface is configured and receiving the stream
2. Check that a membership report has been sent upstream for the group
3. Confirm the downstream interface has an MFC entry for the group
4. Verify firewall rules are not blocking the multicast traffic

IGMP membership not being tracked

1. Confirm IGMP snooping is not enabled on the same interface (conflicts with proxy)
2. Verify the interface is configured as downstream
3. Check that query intervals are appropriate for the network

Stream stops after brief period

1. Increase the robustness variable on unreliable links
2. Verify IGMP queries are arriving at regular intervals
3. Check for upstream network issues causing IGMP message loss

Firewall Considerations

Firewall rules must permit IGMP traffic for the proxy to function:

/ip firewall filter add chain=input protocol=igmp action=accept
/ip firewall filter add chain=forward protocol=igmp action=accept

Multicast packets themselves also require explicit firewall rules:

/ip firewall filter add chain=forward protocol=udp dst-address=224.0.0.0/4 action=accept

Without these rules, IGMP messages and multicast data packets are dropped, breaking the proxy functionality.

Debug Logging

Enable debug logging for detailed IGMP proxy operation information:

/system logging add topics=igmp-proxy,debug action=memory

The logs contain detailed information about membership changes, MFC updates, and interface state changes. This information is invaluable for diagnosing complex issues.

Examples

Basic IPTV Setup

This example shows a common residential deployment where the router receives IPTV from an ISP on WAN and serves local clients:

/interface vlan add vlan-id=100 interface=ether1 name=vlan100-ipTV

/routing igmp-proxy enable
/routing igmp-proxy interface add interface=vlan100-ipTV upstream=yes
/routing igmp-proxy interface add interface=bridge-local upstream=no

/ip firewall filter add chain=forward in-interface=vlan100-ipTV protocol=udp action=accept
/ip firewall filter add chain=forward out-interface=bridge-local protocol=udp action=accept

The configuration creates a VLAN for IPTV traffic from the ISP, configures IGMP proxy on both the VLAN interface and local bridge, and ensures multicast traffic can be forwarded between them.

Multiple Subscriber Networks

When serving multiple downstream networks, each network segment requires its own downstream interface configuration:

/routing igmp-proxy interface add interface=vlan10 upstream=no
/routing igmp-proxy interface add interface=vlan20 upstream=no
/routing igmp-proxy interface add interface=ether1 upstream=yes

Each downstream interface maintains independent group membership tracking, allowing subscribers on different VLANs to independently join and leave multicast groups.

Static MFC Entry

For always-on multicast streams or testing purposes, static MFC entries ensure the stream is always forwarded:

/routing igmp-proxy mfc add source=192.168.100.5 group=239.255.1.1 downstream-interface=bridge-local

This static entry ensures that traffic from source 192.168.100.5 to group 239.255.1.1 is always forwarded to bridge-local, regardless of whether any hosts have sent IGMP membership reports.

See Also

• PIM-SM - Protocol Independent Multicast Sparse Mode for complex multicast routing
• Bridge IGMP Snooping - Layer 2 multicast optimization
• Multicast Routing Overview - General multicast concepts in RouterOS