Multicast networking is based on the simple concept that a single packet can be sent by a server and it will be received by many receivers. Multicast is different from broadcast because it’s more selective.

Where broadcast packets are received by all receivers in a particular network segment (or broadcast domain), multicast packets are received only by receivers that want them. Also, multicast receivers can be distributed throughout a larger network behind routers.

Primary uses for multicast networking

In IPv6 networks, there’s no such thing as broadcast. Multicast is used for everything that broadcast was previously used for, including a number of standard network infrastructure things like router discovery, address allocation, and neighbour discovery (which replaces ARP).

Multicast has a couple of fundamental characteristics that dictate how it’s used. Because a server only needs to send each packet once and will reach all of the recipients, it’s useful for situations where a large number of receivers need to receive the same data. Since the replication and distribution of these packets is done by the network rather than the head end server, it scales well to extremely large numbers of receivers.
But because the multicast is one-way, any responses would need to be implemented using a separate protocol. This also means that dropped packets must either be unimportant, or the recovery mechanisms for lost data must be built separately. There are two really common places where these characteristics are great strengths.

man looking at stocks

Photo: Unsplash

1. Distributing AV data streams

The first is in distributing audio/visual data streams identically to a large number of users. This is the case, for example, with modern IP-based cable TV networks. The set-top box subscribes to a multicast data stream that represents a program or a channel, and the network starts forwarding that data stream to it. Change the channel and the set-top box unsubscribes from that data stream and subscribes to another. If a packet’s lost, it’s not usually even noticeable, although losing several packets in a row can cause that blocky choppy video effect we’re all familiar with.

2. Providing real-time stock-market data

The second common application is real-time stock market data. In this scenario, all market participants must receive the same information at the same time to ensure the market is fair, so multicast is an ideal way of distributing the data. But in this case, lost packets are a potentially serious problem since they all contain important data about prices and transactions. So these types of data streams are accompanied by other systems that allow market participants to recover lost data over standard TCP unicast protocols.

Multicast would also theoretically be useful for things like internet gaming, in which real-time game information needs to be distributed to a large number of players. However, I’m not aware of any internet services that provide multicast forwarding capabilities. The reason for this is obvious: If you could cause the network to arbitrarily replicate packets, this could be abused to create denial of service attacks.

Essential problems with multicast networking

There are two essential problems with delivering multicast data streams. The first is how to allow receivers to subscribe to the multicast data they want and how to unsubscribe from data they no longer want to receive. The second is how to forward those packets from the server to all of the receivers so each packet is forwarded once and only once, regardless of how things are inter-connected.

We solve these problems using two protocols. IGMP (Internet Group Management Protocol) handles the joining and leaving of multicast streams for individual receivers.

PIM (Protocol Independent Multicast) is the protocol that Layer 3 network devices such as routers use to build and manage the multicast delivery tree structures across the network.

1. IGMP

The first thing to mention about IGMP is, although the multicast IP addresses that appear in the “destination” field of the multicast packet header look like normal IPv4 or IPv6 addresses, they’re actually “group” addresses that refer to all of the members of the group.

A device can join a group by sending an IGMP “membership report” message to the group IP address. This packet is received by a multicast router on the segment, and the router does whatever is necessary to start forwarding the data stream to this device.

IGMP membership report packets are always sent with a TTL value of 1 so they can’t leave the current network segment.

There are three versions of IGMP: Version 1 provides the basic functionality of allowing devices to subscribe to multicast groups. Version 2 introduced the ability to also leave a multicast group. And in Version 3, devices were given the ability to request a multicast stream from a specific source device (Source Specific Multicast), instead of just generically from any sending device.

2. IGMP snooping

An important Layer 2 adjunct to IGMP is called IGMP snooping. This isn’t a protocol so much as a feature. With IGMP Snooping enabled, a Layer 2 device like an Ethernet switch listens to IGMP membership reports as well as the router. The switch then is able to use this information to ensure that only those devices that actually want to receive this multicast group get the data, instead of all devices on the segment.

In many implementations of IGMP Snooping, the switch also intercepts the membership reports and keeps track of which groups are required on each VLAN. It can become a proxy “querier” on behalf of the VLAN, requesting groups that are required and delivering them only to the right end devices. At the same time, it can keep track of when no devices on the segment are still interested in each group, and send a “leave” IGMP report up to the multicast router to tell it to stop forwarding this group.

Some Cisco switches implement a protocol called CGMP (Cisco Group Management Protocol), which uses the CDP (Cisco Discovery Protocol) to communicate group membership between the switch and the router. This is only relevant if you have Cisco switches and routers deployed on your network. CGMP was sort of a “stop gap” solution to some of the shortcomings of IGMP Version 1, and it should probably be avoided in favour of standard protocols now.

3. PIM

man looking at map

Photo: Unsplash

Because IGMP membership report packets are always sent with a TTL value of 1, they can’t be used to find a source on a different network segment. For that, we use PIM (Protocol Independent Multicast). The “protocol independence” here means that it can use any IP routing protocol, including static routes if need be. It doesn’t need to distribute its own routes or maintain a separate multicast routing table.

Routers take part in PIM. Each router uses its unicast routing table to discover the shortest path back to the multicast source. This is called RPF (Reverse Path Forwarding). Using RPF, each router is able to decide which interface it should receive the multicast group through. As long as all of the routers in the network agree on the unicast routing table, this will form a reliable tree structure that, like spanning tree, will be free from loops.

PIM has two operating modes: dense mode and sparse mode. I don’t really recommend using dense mode except for the very smallest and simplest of multicast networks. It doesn’t use network resources as efficiently as sparse mode.

The biggest practical difference to configuring coarse mode is the requirement for a “Rendezvous Point.”

4. Rendezvous Points

The Rendezvous Point (RP) in a PIM-sparse mode network exists to find the multicast group and source. A multicast router has received a request to forward some multicast group out through a particular interface. This could have come from a directly connected device via IGMP or from a downstream router via PIM. If the router already has this multicast stream, then it can simply start forwarding it to the destination. But if it doesn’t know anything about this group, it needs to somehow find it first.

The RP is another router on the network. When the source device starts sending its multicast packets, the first router, on the same segment as the source, picks up that packet and forwards it to the RP router. This first step, which is called “registration,” is done using unicast.
The first hop router already knows the address of the RP. There are several mechanisms for this information to be learned, but the simplest and arguably the most effective and secure is to just configure it statically in each router.

Each multicast group has a RP. It’s common to have a single device act as the RP for a large number of multicast groups. The RP has two functions: It maintains a table of all of the sources for each group, and it also receives and redistributes all of the groups that it is responsible for.
When another router on the network receives a request for a multicast group that it doesn’t already know about, it sends a PIM “join-group” message to the next upstream router in the direction of the RP. That upstream router does the same, and the process continues until the chain of routers reaches all the way to the RP. The RP then starts forwarding the group along that path, and ultimately the device that made the request using IGMP starts to receive the multicast group as well.

As soon as the first multicast packets from the RP arrive at the “first hop” router, the one that received the original IGMP join request from the receiving device, that first hop router has an important new piece of information—it now knows the source IP address for the group.

Now that it knows the real source IP address, it can get the multicast data stream directly from the source, instead of from the RP. So it uses PIM joins to create a new multicast tree that goes directly to the source IP (the “source-rooted tree”). And, if the RP-rooted multicast tree uses a different interface from the source-rooted tree, then it will tear down the RP-rooted tree to avoid receiving multiple copies of the multicast packets.

There are other various adaptations to this process such as Source-Specific Multicast and Bi-directional PIM, which use other tricks to improve the efficiency in finding the source and creating the source-rooted tree, but the ultimate goal is the same.

How to create a multicast application on your network

As I mentioned earlier, multicast group IP addresses look like regular addresses. They’re different because they come from a special range. In IPv4, that range is 224.0.0.0/4 (224.0.0.0 – 239.255.255.255). Any packet that’s addressed to one of these IP addresses is automatically assumed to be a multicast, and is delivered according to the multicast forwarding tables in the router (or dropped if there’s no known multicast recipient for this group, or if multicast isn’t configured).

Within this broad range, some multicast addresses and ranges of addresses are reserved for specific purposes and you’re prohibited from using them for other purposes. For example, the first block, 224.0.0.0/24, is reserved for well-defined standard multicast protocols that are constrained to the local segment, such as OSPF and EIGRP. The general allocation of IPv4 multicast addresses is documented here.

If you plan to create a multicast application on your local network, you can do it in one of three ways.

1. Local scope

The first way—which is useful in purely local environments and labs—is to use the organization local scope from the administratively scoped ranges, 239.192.0.0/14. These addresses are similar to the private IP address ranges such as 10.0.0.0/8 in that anybody can use them locally within their own network. However, network admins are expected to ensure that they don’t leave the local network. For more information on these addresses, please refer to RFC 2365.

2. GLOP addressing

The second way is to use GLOP addressing (GLOP isn’t an acronym, it just means glop). This scheme, which is defined in RFC 3180, uses a registered BGP ASN to create a multicast address range.

Since BGP ASNs were originally two bytes long, the GLOP scheme takes the 233.0.0.0/8 range of addresses and encodes that 2-byte ASN into the second and third bytes of the address. So, if you had a BGP ASN of 65525, the GLOP range would be 233.255.245.0/24. This is because 65525 in hex would be FFF5. FF equals 255 and F5 equals 245, giving the second and third octets of the address.

The problem with GLOP addressing is that it assumes that your BGP ASN is the old-style 2-byte ASN. It doesn’t work well with the newer expanded ASN values. So RFC 6034 introduced another way of accomplishing the same thing using registered public IP addresses instead of ASNs.

3. Permanently assigned addresses

And the third way to get a permanently assigned address in the ranges 224.0.2.0-224.0.255.0 and 224.1.0.0-224.1.255.255 by applying to the IANA. These addresses are in relatively short supply, though. So, unless you have a multicast application that you intend to share with a large number of downstream clients, it’s probably better to use one of the other methods.

Kevin Dooley

About Kevin Dooley

Kevin has 15+ years of experience as a network engineer. He has designed and implemented several of the largest and most sophisticated enterprise data networks in Canada and written several highly regarded books on networking for O'Reilly and Associates, including Designing Large-Scale LANs and Cisco IOS Cookbook. Kevin holds a Ph.D. in theoretical physics and numerous industry certifications.


16 comments on “What Is Multicast Networking and How Does It Work?”

  1. Alan says:

    Are there ways to coordinate IPv6 multicast protocols with the Layer 1 networks. Satellites and non-directional antennas tend to be broadcast links.
    I should get good bandwidth efficiencies if I can send my multicast packets down these links when there are receivers at the other end. With the new merging LEOs this a question of growing interest. I assume all the devices in a multicast group would have permanent IPv6 addresses. Finally, I assume that some IGMP packets would have to have TTL over 1; otherwise how can it be used by other network segments?

    1. Kevin Dooley says:

      Hi Alan.

      Multicast over satellite networks is an interesting topic and one that I know very little about. You are right that standard protocols like PIM don’t work well over these links. In particular, it’s hard to keep track of when ground devices leave the group. I understand that some satellite networks have implemented special-purpose protocols for handling this problem.

      I don’t think I would want to run IGMP over that satellite network, though. Instead, I would connect a switch or a router to the ground station and run PIM between them. Then the entire satellite cloud would just look like a PIM forwarding domain to the networks connected to the ground stations. How many TTL hops your packets would count as they cross the satellite depends on the provider’s implementation. They might hide it all from you by encapsulating your multicast packets in tunnels.

      The other big question in such a design would be how to handle the Rendezvous Points. Again, I expect that this would depend on the provider’s implementation.

  2. Convergence1 says:

    ben there, seen it, done it
    224.0.1.145 Satcast One 1999-08-01
    224.0.1.146 Satcast Two 1999-08-01
    224.0.1.147 Satcast Three 1999-08-01

  3. Maninder Singh says:

    Does a device who want to receive multicast packets need to set a route?, e.g. route add -net 224.0.0.0 netmask 240.0.0.0 eth0 ?

    1. Kevin Dooley says:

      Great question. In general, yes, the receiving device needs to know where to send its IGMP packets. So you will usually see routes in your routing table for 224.0.0.0/4 and, equivalently in IPv6, for ff00::/8. Then the receiving device will also need a route that points to the multicast source’s IP address so that it can do a reverse path validation to ensure that it is receiving it on the right interface.

  4. Justin Lee says:

    If I want to send multicast data over to an external network(with multicast enabled) across DMZ with proxy server behind the perimeter router facing the external network, is there a best common practice for this type of use case?

    end user (multicast destination) ——– external network ——–proxy server ———-internal network ——– multicast source.

    1. Kevin Dooley says:

      Yes, when sending multicast to external networks there are a few things that you should watch out for. Just like with external unicast networking, you should be using public multicast IP ranges. There are two main ways of getting public multicast addresses. The first is to register the range with IANA from one of the “ad hoc” address blocks. The second is to take advantage of the GLOP range, which uses your registered BGP ASN to create a unique publicly routable range. Refer to RFCs 5771 and 3180 for more information on these public multicast address ranges.

      Then you need to make sure that the external parties have routes to the multicast sources and rendezvous points. So, again, these should be public registered addresses, so they can be routed. In principle, you can use multicast NAT to translate private source addresses, but multicast data is often sensitive to latency and jitter. So it’s better to avoid too much packet level processing.

      For fault tolerance, it is useful to have redundant connections between the networks and use a routing protocol like BGP to advertise the source and RP addresses. Generally I like to advertise these addresses across network boundaries as both /32 and some larger prefix (such as /24) so that the external network can easily manage their traffic engineering and failover using BGP inbound route filtering.

      There are protocols such as MSDP for distributing RP information between networks, but I haven’t seen them used much for this purpose. It’s more common (and simpler to configure) to use static RP configuration in the routers. Fault tolerance will take advantage of the best route to the RP changing with BGP instead. I do like to use MSDP to create multiple redundant RP’s inside the source network, however. This clever trick, which is called “anycast RP”, is described in RFC 4610.

      I hope this helps.

  5. Justin Lee says:

    Thanks for your detailed explanation! In terms of multicast data traversing across DMZ to an external network, how does proxy server handle the multicast stream? Since the multicast data is UDP and you can’t proxy udp as it is a connection-less protocol… Is there a best common practice for multicast stream to traverse DMZ network?

    1. Kevin Dooley says:

      Generally, since multicast packets only go from source to receiver, a proxy server probably doesn’t have useful role to play here.

  6. LH says:

    Thanks for publishing this. I found it incredibly insightful, but unfortunately for different than others who posted. I recently ran an “ifconfig” process and to my horror (and longtime suspicion) discovered 8-9 ACTIVE configured connections on my device, each of them flagged with these flagged characteristics definitions “UP,POINTOPOINT,RUNNING,MULTICAST,ARP”. I did not authorize or set up any of these portals. Each connection has a different name such as “awdlo” “ipsec0” “pdp_ip1” “ipsec3” “llwo” etc etc…
    This article unfortunately seems mostly written mainly for people to appreciate this MULTICAST NETWORKING as a super cool & interesting new thing (and it probably is!)… But seems to maybe have grim and far reaching security implications for people whose data is being “multicast” without their permission or against their will.
    Any advice for us?? Looking for more info on 1) what the connections mean and 2) how to ** not** multicast my networking!! Would deeply appreciate any insight! Thanks.

  7. nooneimportant says:

    that’s right, your every move is being broadcast to the world. That’s what you get for using a mac.

    …oh, wait, those are just standard services:

    llw0: a WLAN low-latency interface
    awdl0: Apple Wireless Direct Link used for AirDrop, Airplay, bluetooth, etc.
    pdp_ip1: used for 3g & cellular data
    ipsec0: possibly used for wifi calling in FaceTime (e.g., from your phone to your laptop)

    in all, this reminds me of the super deadly teddybear virus that afflicted Windows

  8. Saundra Goodson says:

    How can I capture multicast gaming packets using something like wire shark?

    1. Kevin Dooley says:

      Wireshark actually makes this extremely simple. When you start a capture, you can specify a capture filter. If you want to capture all multicast packets, you can just use the capture filter keyword “multicast” and start capturing. Or, if you know the multicast address used by the application that you’re interested in, you can specify that as the destination address in a capture filter such as “dst host 239.1.1.1”.

      1. Saundra Goodson says:

        Awesome! Thank you!

  9. Ray Campbell says:

    In a server which has multiple clients joining a multicast group, does the server get on message and then distribute it to every client connected and joined to the group or does the switch send a message to every connected client on the server?? Thank you in advance for your response.

    1. Kevin Dooley says:

      Generally, the server that provides a multicast data stream doesn’t know anything at all about its clients. The server just sends the multicast packets and the first hop router (the Designated Router or DR) picks up those packets and forwards them to the Rendezvous Point (RP). Client devices send their IGMP requests to join the group, and those requests are picked up by their first hop router, which builds a tree towards the RP. Then, once the packets start to flow, it rebuilds that tree towards the DR. The important things are, first, the data packets themselves play an essential role in establishing and maintaining the distribution tree, and second, the routers do all the multicast packet replication and forwarding. When the routers stop seeing packets, the routers start tearing down the distribution trees. The server just sends data packets with no awareness of what happens to them.

Leave a comment

Got something to say? Name and email are required, but don't worry, we won't publish your email address.

*