Anytime we're talking about multicast, what we're really talking about is efficiency. We want to
make the network responsible for generating lots of copies of the same packet. So as a general
example set, what we have here is we have a device on the network, we'll call this our
multicast server, and it wants to send to a bunch of hosts out here. So maybe we have hundreds or
possibly even thousands of hosts out on the network that want to receive this. So a lot of
them are maybe stacked up on one network, but a lot of them down here might be stacked up on another
network, and we could have these across all kinds of subnets throughout the entire organization.
And so if we wanted to send the same stream to thousands of different hosts, well if we were to
use unicast, I'd have to send it to that host, and I have to send it to that host, and that host,
and every single packet that I want to send, I would have to send a thousand times. As we can
imagine, not only is this poorly efficient, but it might actually cause performance problems on the
server itself. Instead, we are going to task the network with the replication, and we're going to
do this in a very efficient way. Rather than me sending directly to the host, I will send a single
packet to my upstream router, and then it will figure out what to do from there. So for example,
let's say we've got a couple of routers this way that connect down to these subnets, and at this
point this router here that just received the packet knows to send a copy here. Again, just a
single copy of the packet to each one of these routers, at which point it will send it downstream
to the individual hosts. Usually we have intelligence on the layer 2 side in order to
make it so that it only goes to the hosts that need to see it. Otherwise, we'd be flooding it
to hosts that don't want to see that stream, and that's not as efficient as it could be.
But we can see that this mechanism is far superior to the concept of sending thousands
of unicast packets every single time a packet needs to be sent. Now there's a few things to
keep in mind with multicast. First of all, we're going to use the concept of a class D address,
at least in the world of IPv4. A class D address is anything from 224 to 239 in that first octet.
So 224 through 239, and then dot something, dot something, dot something. And this is known,
by the way, as a group address rather than a destination address. So that's something to keep
in mind. If I say that I want to receive a stream, I'm going to try to join this particular group or
a particular group. Second of all, we have a couple of different mechanisms at play here.
We have a protocol known as IGMP that is helping us out at layer 2. So we are expecting IGMP to
be running here. And then we also have PIM that is running at layer 3. So PIM is running here
throughout the routed environment. It would also be running up here among these routers. Now lastly,
we have two different types of multicast at this point. We have the traditional any source multicast
where a host joins a group. Let's say we want to join this group of, actually, let's just use
something like 239.1.1.1. Anything starting with 239 is sort of a private IP address within the
world of multicast. So a lot of our streams start with 239. So I might just want to join
a particular group and I don't care where the source is or for that matter which source I join.
Sometimes we have multiple servers sharing the same stream. So that would be any source
multicast. I don't care which source I join. Or we can have source-specific multicast.
And that's a little bit more of a modern version of multicast. And that would mean that I'm going
to specify the source. I want to join specifically this host 10.100.1.3. So I'm specifying the source.
That would be source-specific multicast. Or I'm not specifying the source. That would be any source
multicast. The last thing to keep in mind is that we are running the concept of a multicast tree,
specifically a loop-free tree. For example, if I were to connect these other two routers
like this, then we certainly wouldn't want to see this packet get sent up to this router and
then back around and forming a loop. That would be really bad. Instead we're going to form a
loop-free tree. So in our case the tree would look like this and we wouldn't include this third link.
It would be fine for using for unicast traffic, but we wouldn't use it as part of our multicast
flow or multicast topology. And that's because PIM created for us a loop-free tree. The question is
how to form this loop-free tree. We have a little bit of a chicken and egg problem in the world of
multicast, which is if I know where I'm building, then the way I form this multicast tree is I build
toward the source. And I can just look up in my routing table where this source is and I can
figure out how to join the tree. I send a join message towards the originating router. But the
question is how do I form this tree if I don't know where the source is? This is where we have
that infamous concept of the rendezvous point. I'm going to build my tree to the rendezvous point
and because the rendezvous point in theory knows where all of the sources are, it can then build
towards the source. So these are some basic concepts in the world of multicast. We really
need to understand some of this in order to then apply this to the world of SD-WAN.
So as we talk and move our conversation toward SD-WAN, the question is how exactly do we support
multicast? Here's the good news. We do support any source multicast and we support
SSM, source-specific multicast. So both of these are supported. That is good news.
But we're going to do it in a rather unique fashion. We are not going to participate in PIM,
at least across the SD-WAN, and we are going to support this using unicast communication,
which might feel like a step backward and in some ways it might be. But we have to address
the fact that we need to participate in this loop-free tree, but in a way that makes sense
for a wide area network environment that could have thousands of edge nodes. So let's go ahead
and draw an SD-WAN environment here and we'll just focus on a single transport for right now.
All of this applies to multiple transports. We have edges that are communicating with one another,
potentially lots and lots of edges. Again, we might have thousands of edges.
And put another one up here and down here. So we've got lots and lots of edges in this
environment. They're all forming tunnels to one another. And now we have a network downstream
here on the service side in a VPN where we have our listeners. So we have our multicast listeners
here that potentially want to join a stream. So remember, we have to worry about both of
these protocols, IGMP and PIM, as far as how to help build out trees. So what are we going to do
here? Well, in this environment, we are going to use IGMP, which allows us to join a particular
group. And then this router, this edge here, is going to be responsible for building out towards
the source. Furthermore, this could actually be built out in a couple of different ways. For
example, another edge might actually have downstream router connections. And then we have listeners
that are trying to send an IGMP join this way. Well, at this point, the IGMP join isn't received
directly by the edge. Instead, we're going to send a PIM message upstream. So these devices
down here are participating in PIM. So we send PIM join messages, we form a loop-free tree,
whatever makes sense from that perspective. So either an edge is receiving an IGMP join,
or the edge is receiving a PIM join message. But in either case, the edge is now responsible for
connecting these listeners to wherever the source lives. We might expect that they would do what
normal routers do, which is to send the PIM join message upstream, again, via PIM. Maybe the source
we know is over here. But that's not actually what we're going to do. And there's a good reason for
that. It's because we are already managing all kinds of tunnel relationships through the WAN.
And again, we might have hundreds or thousands of edge devices, and it's just not going to scale
for us to have that many PIM adjacencies and PIM neighborhoods to manage. So instead, all we're
going to do here is advise the SD-WAN controller to let them know, hey, we have listeners
for a specific group, whatever that address is. Maybe, again, 239.1.2.3 in this case.
So we have listeners that want to join this group. And as far as these edges are concerned,
they're done. They've accomplished exactly what they wanted to do. Mission complete.
But we know that the listeners aren't receiving a stream yet. So these edges are done with what
they were supposed to do. But there's going to have to be a second part of this conversation,
which leads us to talking about the server side. So over here, let's say that we've got a network
that has the server. So this is our multicast source, and it is sending traffic to that 239.1.2.3
into the network. The good news is because of OMP, and remember, this is part of OMP as well.
So because of OMP, I know where there are listeners. Here's the unfortunate part.
I'm not participating in PIM. We, again, don't have PIM adjacencies, so I can't form a multicast
tree in this fashion. So what are we going to do in this case? We know that we have a source,
we know where to send it, and that's where we're kind of stuck. We want to do something in as
efficient of a way as possible. And so the answer to this is going to be to assign an edge node into
a special role known as a multicast replicator. The replicator is going to advertise into OMP
that is configured for this role. So we see that OMP is going to be the glue that connects
everything together. But what exactly is the replicator doing? Well, now that everybody knows
pretty much everything, we know where the replicator is, we know where the listeners are,
and we have a source that we need to send, this edge is now responsible for sending traffic to
the replicator. So we are sending the actual traffic, the multicast traffic flow,
each packet to this replicator. And it's going to do it inside of its unicast tunnels,
meaning that I'm truly just encapsulating a multicast packet and sending it directly to
the replicator. The replicator is going to do exactly what its name might imply. It's going
to replicate those packets, and it's going to send it to all of the listeners. Now here's the
bad news. It's going to leverage unicast at least as far as getting across the SD-WAN topology,
meaning that I'm not going to send a single packet into the network and allow the network
to send it out to all of these edges. First of all, we've said we don't want to participate
necessarily in PIM. The other problem is, does the underlay even support multicast? A lot of
underlays, especially the internet, don't actually natively support multicast. So at that point,
we wouldn't actually be able to take advantage of it anyways. This is one of the reasons why,
and we can see we've got several reasons, why we're using this unicast method. So instead,
I'm going to unicast this traffic to each individual edge that needs it. Now this might
be a hundred edges. I might be sending a hundred packets into the network. I'm going to target each
individual edge that requires it, but at least every single edge is the limit of what I'm sending.
I don't have to send it to each listener. If I have a thousand listeners, I don't have to
send it to all one thousand listeners. I only need to send it to the edges where the listeners
exist. At that point, we revert back to traditional multicast configuration and we
send the traffic downstream to allow the network to be replicating as if we were running traditional
multicast. So is it super efficient? Not necessarily. We're not leveraging multicast
here inside the underlay. We can't do it across VPN0. We're going to have to use unicast. So is
it a problem? And the answer is no. This will scale out pretty well. The entire purpose of
the replicator is to sit and replicate traffic. We're offloading that role to a device that's
intended to specialize in the replication, and therefore we can scale this up using whatever
level of hardware we need to. We don't have to worry about remote edges having enough hardware
to perform this role because we've decided which device in the network is going to serve as our
replicator. And in most cases, as we might imagine, we can have redundant replicators as well. And so
that is how multicast works across the SD-WAN. Our takeaway from this conversation shouldn't be
that we have to dive deep into the world of multicast and really understand how PIM and IGMP
work. Just understanding sort of these one, two, three concepts in the top right, as well as then
the role of the replicator in the multicast framework for SD-WAN, that's really what our
primary takeaway is in understanding multicast so we can then turn around and possibly deploy
it into our enterprise networks.