Remedial Networking 102: How Multicast Works

Date March 20, 2012

Did you ever have anything in your life that you just kind of...ignored until it went away? Or at least, ignored it until you forgot about it or pretended it went away? That's kind of what I did with multicast.

For a long, long time, I would hear people mention multicast, and I would be like, "oh, multicast, yeah, talking to lots of hosts at one time, yeah, that's cool..." then do my best to not join in that conversation, because I had less than nothing to add. In fact, all I could do was show my ignorance, and THAT'S no fun.

So my shame of not knowing it drove me deeper into my cave. "It's not like anyone even uses it. I've been doing networking for years and its never come up".

Then I started learning more about IPv6, and multicast would creep into the conversation. And I'd ignore it, and sure enough, the next paragraph wouldn't mention it anymore, and I could go back to pretending it didn't exist. But it kept coming up, and one day I slipped.

I thought to myself, "so, I know that multicast is all about sending data to lots of hosts at once, but how could it really do that?" And so I slipped into the inescapable void of my curiosity.

As it turns out, it's really not all that crazy, and it's really not that difficult, at least on the surface. There are two sides of the proverbial coin. There's the theory of how it works, and there's the practical application. Lets look at the practical side.

A prototypical example use-case would be video streaming. Every multicast application (and by application, here, I mean every solution, such as a NASA video stream and the like) picks or is assigned a particular multicast IP address, then everyone on the internet that wants to watch the stream joins that multicast IP address...and when I say it joins that multicast IP address, I mean that the machine uses a protocol called IGMP to tell its local router that it wants in on the action.

The local router is hopefully configured to know about IGMP so it listens. If it's configured properly, then it uses a protocol called PIM (or one much like it) to let the next closest router to the video source know that it has someone who wants to watch. That router then sends PIM updates to the router it thinks is closer to the source than it, and so on.

Eventually, you wind up with a tree starting with the root being the video server, and forming the branches are all of the routers who have clients that used IGMP to let them know that they wanted to watch. The video source sends out one packet, to its closest router, and the router remembers which connections joined that group and sends the packets to those routers, which send the packets to the next routers, and the packets eventually wind up at the clients who are watching the stream.

No one machine sends a ton of packets, and no routers have to remember much besides which interfaces belong to which groups. It works out nicely, even though, and I say this with the greatest apology now that you've read the preceding paragraphs, almost no one uses it like this.

Sure, there are some internal networks that use it for things like teleconferencing, but I bet yours doesn't. Except you Googlers and Yahoos out there. Your university probably does, I guess, especially if it's on that whole Internet2 thing, but the vast majority of you will never have to deal with multicast video streams.

That doesn't mean that multicast is going away. Actually, with IPv6, it's getting more airtime.

The biggest difference between IPv4 and IPv6, in my opinion, is the idea that your interface isn't going to belong to only one layer 3 (IP) network.

You know how, right now, you are probably on a private block, like 192.168.whatever? Well, with IPv6, you're still going to have a private block, only it's called link-local. Your machine, and every other machine, will have a link-local network address on their interface. It doesn't route to the internet at all. When you have one machine that wants to talk to another local machine, it's going to happen over the link-local interface.

Of course, your computer will also want to talk to the internet, probably, so you're going to have an IP with the "real" network prefix (which is probably going to be assigned automatically by the IPv6 autonegotiation process, which I'll write more about later). This "real" network IP will allow you to communicate with the outside world (and it with you, unless you set up your firewall rules correctly). That's two IP addresses so far. How many more?

Well, there is also going to be the "All Nodes" multicast group, FF01::1 for "node-local" (AKA "all interfaces on the same machine") and FF02::1 for the link-local (AKA "the local broadcast domain" because routers don't forward link-local packets) group. Your machine will belong to these multicast groups, because things like ARP are going away with IPv6.

Instead of ARP (and ping and passive IP collision detection), IPv6 includes a protocol called NDP, which provides for all kinds of things...and most of those features come from using multicast addresses.

So what happens is really just a smaller version of above, where the host tells the router that it wants to join a multicast group. Except that in IPv6, we don't use IGMP anymore, we use MLD, but it works mostly the same way. The router sends us any packets that are sent to that IP address, and things go swimmingly.

If the machine that you're working on IS the router, well, then it's going to join any number of IPv6 multicasts...the "All Routers" multicast (ff02::2), maybe the All DHCP Servers group (ff02::1:2), and seriously, a ton of other multicast groups.

The big reason for all of these groups is service discovery. It's kind of like, in IPv4, if you had a specific private IP block for, say, DNS servers. If you just knew that somewhere in 192.168.32.0/24, there would be a DNS server, you could join that network, ping the broadcast, and the DNS server would respond. You could use that to add it to your configuration. It's kind of like that, but instead of a broadcast, it's multicast.

If you're the rare networking wonk who didn't know multicast, you've probably already asked, "yeah, but how does that work at the switch?", in which case I invite you to read the wiki entry on IP Multicast: Layer 2 Delivery.

So despite my earlier fears, multicast doesn't operate by magic, just by protocols that I've never configured because they didn't matter to me. But even with the scant knowledge that I just imparted, you can feel a little bit better about needing to use multicast all over the place with IPv6.

3 Responses to “Remedial Networking 102: How Multicast Works”

  1. chris marget said:

    Hey Matt,

    Nice meeting you last week!

    Your article is right on, but only has scratched the surface. Fortunately, you don't need to worry about it. Multicast is a much bigger headache for network admins than for system admins.

    If you ever turn up a multicast application, please consider the scope size (this building? whole continent?) then ask your network admin for a group address. If they don't help, put it somewhere in 239.192/14 (enterprise scope) or 239.255/16 ("smallest" scope), but not x.0.0.x or x.128.0.x. These ranges overlap the L2 addresses used by the network control block. That's about all sysadmins probably need to worry about.

    Here are some of the fun multicast details that keep your network admins up at night:

    1) You said that the leaf router uses PIM "to let the next closest router to the video source know that it has someone who wants to watch"

    When somebody says "multicast" they usually mean Any Source Multicast (ASM). This is the common flavor in which the clients don't know who the source is, only the group they're interested in receiving. You can turn the television on without knowing where the broadcast tower is. Same story here. How does the leaf router know which direction the subscription message should go if it doesn't know the source? This is why we need a Rendezvous Point (RP) in every network. It keeps track of who is talking and on what group.

    2) You said: "the router remembers which connections joined that group and sends the packets to those routers, which send the packets to the next routers"

    Unfortunately, just knowing the group isn't enough for a router to decide what to do with a given multicast packet. What if we have sources talking on the same group in the east and west ends of our network? Intermediate routers will need to send some packets east while other packets get sent west. Routers consider both the Source and group (S,G) when making forwarding decisions.

    3) I don't think we'll ever see multicast on the Internet. Here's why. Consider screwups like this one:
    http://www.broadbandexpert.com/blog/service-outages/level3-infrastructure-crashes-by-juniper-routers-cause-a-gigantic-internet-outage/

    Service providers are concerned not just about the size of their routing tables, but also about the rate of updates. Adding and withdrawing routes is hard work, especially when you consider that most internet routers have less CPU power in their control plane than I have in my cell phone... Bug that triggered this bug was bad not only for the routers that crashed, but also for their neighbors. And their neighbor's neighbors. And their neighbor's neighbor's neighbors...

    The good news is that routes in the Internet don't usually change all that much. If they change a lot, it means that something is wrong and people get worried about it.

    Now think about multicast: A multicast enabled Internet would allow *end*users* to influence forwarding tables in Internet routers. End users who channel surf, installing and removing forwarding entries at their whim. This is a problem that is unlikely to scale. Ever.

  2. cheap iphone accessories cases said:

    00, the Tom - Tom comes with Bluetooth for hands-free cell phone talking.
    Their large amount of grant and loan programs makes
    Phoenix a great place for small-business owners to get started.
    I looked around and found a few accessories that
    you don't have to go broke buying but still are good quality.

  3. cheap iphone accessories cases said:

    00, the Tom - Tom comes with Bluetooth for hands-free cell phone talking.
    Their large amount of grant and loan programs makes
    Phoenix a great place for small-business owners to get started.
    I looked around and found a few accessories that
    you don't have to go broke buying but still are good quality.

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

*