Multicast Distribution HowTo

Introduction

The intention of this document is to give an overview of available mechanisms in WeOS to control multicast distribution. Focus is on distribution on a LAN although multicast routing is also covered, albeit to a smaller extent.

The following topics are covered:

  • What is multicast?
  • Operating modes of IGMP
  • Ideal distribution

For additional information, please see the configuration guides on IGMP Snooping and Transparent Bridging.

Tips

The simplest of tools are often the best when debugging. Familiar tools like ping and tcpdump, when debugging unicast, are your friends also when debugging multicast.

However, when debugging routed multicast, remember the TTL. The default TTL value for multicast in most TCP/IP stacks is 1. This is because multicast in its unregulated form is broadcast. More on this below. Use -t TTL option to both ping and mcjoin.

sender $ ping -t 64 -i eth0 225.1.2.3

or

sender $ mcjoin -s -t 64 -i eth0 225.1.2.3

On the receiving side we must generate an IGMP report before we can see the multicast stream with tcpdump or wireshark:

receiver $ mcjoin -i eth0 225.1.2.3 &
receiver $ tcpdump -i eth0 dst host 225.1.2.3

If using the same Linux PC for both sending and receiving traffic, make sure to isolate your network interfaces from each other using network namespaces, ip netns. Otherwise the traffic will be short circuited in your host’s TCP/IP stack.

A tool like mcjoin1 is required on the receiver to tell the (Linux) PC to send an IGMP Join for the given group, it can also be used to send pure UDP multicast. Only after receiving the IGMP Join will the switches forward multicast in the direction of your receiver. More on IGMP Join and Membership Reports below.

Also, the switches switch most of the traffic, so you will likely not see any of your traffic reach the CPU of each switch. Only routers will get the traffic, but again not all traffic.

What is Multicast?

Without any active form of regulation, multicast is broadcast. So in networks with malfunctioning IGMP/MLD snooping devices, one option can be to disable the snooping entirely. Of course this is discouraged.

WeOS support two forms of regulation: automatic using IGMP/MLD snooping, and manual using static MAC FDB or IP MDB filters.

IGMP/MLD

Internet Group Management Protocol, IGMP, is an IPv4 protocol originally devised for multicast subscription on LANs between a multicast router and its end devices. Multicast Listener Discovery Protocol, MLD, is the IPv6 variant and works similarly to its IPv4 counterpart, but with different IP addresses and has another dedicated MAC address range.

The standards governing IGMP, MLD, and IGMP/MLD snooping (for switches), are defined in the following set of RFCs:

The IGMP/MLD protocol itself is fairly simple: periodically a Querier sends out an IGMP Query: Who wants multicast?, to which end devices, and all intermediate switches with IGMP snooping, reply with an IGMP Membership Report stating which groups they want (to join or leave).

  • The Querier is elected among all IGMP and IGMP Snooping capable devices based on the numerically lowest IP address. (Address 0.0.0.0 is reserved for so called “proxy queries”)
  • The Querier is the designated distribution point for all multicast on the LAN. This means all switches on the LAN must forward its known and unknown multicast to that point

Known multicast is that which has at least one receiver. Switches along the path from the receiver to the elected IGMP querier forward reports towards the querier and opens up forwarding of the given group(s) in the direction of the receiver.

Unknown multicast must also be forwarded to the querier so that when a receiver requests it the querier can immediately forward it.

An end device (receiver) may at any point leave or join a group. I.e., a membership report can be sent at any time in the query interval. The leave process is not immediate unless the switch port has Fast Leave enabled.

An end device that fails (or neglects to send leave) to respond to two queries will have its group memberships timed out.

Static Filters

WeOS also supports setting static multicast filters (MAC or IP group), as described in the transparent bridge configuration guide. This can help in some cases, but also has its limitations.

When IGMP snooping is enabled, a static filter is logically OR:ed with any dynamic filter from IGMP snooping.

When IGMP snooping is disabled, multicast is by default flooded like broadcast, or more specifically, controlled by the multicast-flood-unknown setting which is enabled by default. The exception is for matching static filters where traffic is only forwarded on the listed ports. However, in such a setup all multicast groups must be listed in the FDB; otherwise traffic to not listed groups will still be flooded on all ports. This is not obvious at first glance.

Tip

Usually, static FDB entries are best suited for opening up multicast on ports towards end devices that do not speak IGMP. In addition, static entries avoids flooding the given groups on other ports.

example:/#> configure
example:/config/#> fdb
example:/config/fdb/#> group 225.1.2.3 vlan 1 eth3,eth5
example:/config/fdb/#> leave
example:/#> copy run start

The above example adds 225.1.2.3 statically to ports eth3 and eth5 in VLAN 1.

IGMP/MLD Snooping

Note

WeOS supports IGMP snooping, while support for MLD snooping is pending. See the IGMP Snooping Configuration Guide for more information.

The IGMP/MLD snooping implementation in WeOS supports the following two modes:

  • Auto mode
  • Proxy mode

Note

Never mix IGMP modes on a LAN unless you know what you are doing!

Auto Mode

Auto and Proxy modes are very similar. In auto mode the switch will take part in the previously mentioned Querier election, in proxy mode it will not. Proxy mode is also the fallback mode on a VLAN where no IP address on the VLAN interface is found.

Note

Engineering the IP address plan for optimal placement of the Querier and its backups can be tricky. For more help, see the CLI commands ip multicast-router-timeout and ip multcast-querier-robustness in IGMP snooping configuration guide.

example:/#> configure
example:/config/#> ip
example:/config/ip/#> multicast-router-timeout 24
example:/config/ip/#> leave
example:/#> copy run start

Do not set a router timeout less than the IGMP querier interval.

Proxy Mode

In Proxy mode the switch does not take part in the Querier election (in any VLAN). By default, all queries sent in proxy mode use source address 0.0.0.0, which is exempt in the election process.

The most characteristic distinction Proxy mode has, compared to auto mode, is that it can do nothing unless explicitly asked.

  • Proxy mode never forwards a query from a neighbouring proxy mode switch
  • Proxy mode only responds with an IGMP Report to queries

This effectively means that multicast is localized as much as possible. Hence, proxy mode in combination with IGMP Fast Leave on trunk ports can be a very attractive option for setups with low-bandwidth trunks (DSL).

The proxy query mode can be disabled - then the unit will not act proxy querier, not even as fall-back mode in interfaces lacking IP address.

example:/#> configure
example:/config/#> ip
example:/config/ip/#> no multicast-proxy-query
example:/config/ip/#> leave
example:/#> copy run start

In a LAN with Proxy mode-only switches and with this feature is disabled, multicast distribution will be severely affected. It is recommended to have at least one device on the LAN send queries, either with an actual source IP address or address 0.0.0.0.

  1. https://github.com/troglobit/mcjoin ↩