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
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:
- https://tools.ietf.org/html/rfc2236
- https://tools.ietf.org/html/rfc3376
- https://tools.ietf.org/html/rfc4604
- https://tools.ietf.org/html/rfc4541
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 MAC FDB and IP MDB (WeOS 5) filters, which 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, except for matching static filters where it 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.
Usually, static FDB entries are best suited for opening up multicast on ports towards end devices that do not speak IGMP.
All FDB entries are IPv4 to MAC encoded, as per RFC1112, since that
is what the Marvell SOHO family of chipsets support. On Dagger based
products it is also possible to set mdb
filters using the IP group
address.
Example: the multicast group 225.1.2.3 is encoded as 01:00:5e:01:02:03.
There are several default static FDB entries in the factory-config
,
they represent select groups from the reserved 224.0.0.* range, which
should always be forwarded on the LAN. Do not remove them unless you
know what you are doing.
example:/#> configure example:/config/#> fdb example:/config/fdb/#> mac 01:00:5e:01:02:03 eth3,eth5 vlan 1 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
The IGMP/MLD snooping implementation in WeOS 5 is in the Linux bridge
module, specifically br_multicast.c
. It supports the following two
modes:
- Auto mode
- Proxy mode
WeOS 4 also has a Forced Querier mode, which has been deprecated for quite some time and is not included in WeOS 5.
NOTE: never mix IGMP modes on a LAN unless you know what you are doing!
Auto Mode
Auto and Proxy mode 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
.
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. In WeOS 5 this “proxy query” can be disabled:
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 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.
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 querys
This effectively means that multicast is localized as much as possible. Hence, proxy mode in combination with Fast Leave on trunk ports can be a very attractive option for setups with low-bandwidth trunks (DSL).
Ideal Distribution
In setups with shared low-bandwidth links customers often want to limit multicast as much as possible to find the most ideal distribution. The best solution to that differs, of course, but it is important to first ask the question: what do you want to optimize for?
- Availability, or
- Bandwidth utilization
If availability is more important, then try to find a higher bandwidth link or aggregate links and use Auto Mode.
If bandwidth utilization is more important (you may not have a choice), then Proxy Mode and Fast Leave on all shared low-bandwidth links, or all links leading to/from those low-bandwidth links, is your best bet.
example:/#> configure example:/config/#> ip example:/config/ip/#> no multicast-querier example:/config/ip/#> multicast-fast-leave-ports X7,X8 example:/config/ip/#> leave example:/#> copy run start
For a combination of some low-bandwidth links and some high-bandwidth
links, on which part of the LAN availability is more important, then you
can use multicast-router-ports
to forward all multicast. This works
in all IGMP modes:
example:/config/ip/#> multicast-router-ports X31,X32 example:/config/ip/#> leave example:/#> copy run start
This setting is usually intended for fail-over scenarios with multiple multicast routers. E.g., when running VRRP both the master and backup router needs to have all multicast readily available when failing over, or failing back.