Basic Multicast Topology
Since I’m knee-deep in preparing for my CLUS 2019 breakout, I figured I’d pull some double duty and post an update to my blog. Currently, I’m working on labbing some multicast scenarios and building a topology that will help teach most of the multicast solutions/features. Let’s take a look at what I’ve got so far and step through the most basic of multicast explanations.
In this topology, we have two multicast receivers connected to the same layer 2 segment. Two routers are providing a layer 3 gateway with HSRP. Since the routers are connected to the receivers, in multicast terminology we refer to them as Last Hop Routers. I’ll explain more about that in a bit.
At the other end of the network are two multicast senders (or sources) which will be used to generate traffic to multicast groups. The router that they are connected to is referred to as the First Hop Router using multicast terminology. Again, we’ll examine this a bit further on. For now, it’s more important to understand the labels we are using and the unicast routing flow.
In this network we are using EIGRP for routing. All routers are establishing EIGRP adjacency on all connected links. Multicast Routers A and B are injecting their Loopback0 IP addresses into EIGRP as well.
A short ping test confirms that one of the LHR can ping the multicast senders as well as the Loopback0 of the A/B side routers. For brevity, this test is repeated but not shown with the other LHR; it also has full reachability. This is very important, as multicast routing will rely upon the unicast routing table to decide how the traffic will flow.
The Stage is Set
Now that we’ve verified that the unicast topology is stable, let’s discuss some basic principles so we can see how traffic will flow.
Let’s consider a standard client/server transaction. In traditional unicast, routers advertise networks that they can reach, whether those networks be directly connected or multiple routers away. When a router advertises the network to which a server belongs, reachability to that server is possible.
When a client wishes to transact with the server, whatever application is in use will attempt to send a connection to the server IP (for simplicity’s sake we will not consider DNS and other client/server features which aren’t relevant). The router (or multi-layer switch) which serves as the layer 3 gateway of the client has received the advertised network of the server, and so traffic will follow the best path toward the destination.
When the server receives the connection request, it will swap the source/destination IP address to send a reply back to the requesting client. Because the layer 3 gateway for the server has received an advertisement for the client’s network, traffic can flow back toward the client. This is destination-based routing, where control-plane advertisement goes from a network outward to advertise a path. This allows traffic in the data plane to be routed toward that destination. Decisions on forwarding traffic are based on the destination of the packet. So how is multicast different?
Multicast Routing is Source-Based
A lot of material says that ‘multicast routing is backwards’. It’s not so much that it’s backwards as that it is concerned with the source of the traffic, not the destination. Why, you ask? Well, let’s consider how multicast works for the answer; once you understand the next part, it should be clear that it couldn’t work any other way.
Imagine that there was a radio station. Pick your favorite. That radio station broadcasts on a particular frequency. When you want to listen, you tune your radio to that frequency and start receiving the station’s feed. This is basically how multicast works! The sender (or source) would be the radio station itself, transmitting its feed to the network, not knowing if anyone was tuning in. Your car radio would be the receiver, and you would be signalling your interest in the radio station’s feed by tuning it to the correct frequency. Now imagine, how would destination-based routing work in this scenario? It’s impossible for the radio station to know who is tuned in, it just transmits on a particular frequency. Radio listeners tune in and tune out all the time based on interest. The only thing that can be relied upon in multicast, therefore, are the senders (radio stations) and their frequencies (multicast groups).
The only way to route multicast traffic from a source to its interested receivers is outward and downward . Therefore, the routing isn’t destination-based, but source-based! Receivers are interested in receiving traffic from a source, but sources are unaware of the receivers in the same way that a radio station can’t identify its individual listeners. Multicast routing isn’t backwards, because it still relies on the unicast routing table to advertise reachable paths, and to determine the best way to reach specific sources. It is source-based, which differs from the unicast method of destination-based routing. In multicast, the destination is the multicast group itself, which is a logical construct. Receivers signal interest by joining this group, thereby asking the network to deliver the multicast traffic being sent to that group.
The Multicast Tree
In this way, multicast can be thought of as a tree rooted at the source, with its leaves being spread outward into the network based solely on the interest of receivers. As receivers join a multicast group, new leaves will graft themselves onto this tree. As receivers leave the group, dead leaves in the network will be pruned. Following the radio station analogy, the station would be the root of this tree, and as listeners tune in and out, the feeds would be grafted and pruned. In real life, of course, the radio station broadcasts using radio frequencies over air waves, which aren’t as intelligent as a network could be. By planning multicast network deployments, we can optimize the resources used to ensure only the traffic which is desired gets delivered.
Couldn’t We Do This With Unicast? Broadcast?
The short answer is yes, and yes. The long answer is that either end of the spectrum comes with a boatload of inefficiencies and the inability to scale. Multicast is, at it’s core, a scaling technique and network optimization solution.
In the case of unicast, we’d need a separate connection for every receiver as unicast is one-to-one. Each receiver would get exactly the same replicated stream from the source, multiplied by the number of receivers. If it were a 1Mbps stream, perhaps an audio or video feed, this 1Mbps would be multiplied by the number of receivers. More troubling, the source server would have to create an entirely new socket and stream for every interested receiver. This could quickly become a DDoS on the server without the ability to put a load balancer in front of a server farm. Clearly, 1:1 scaling is no scaling at all.
Broadcast has an immediately obvious issue: Most modern networks aren’t all in the same broadcast domain! Of course even if we had some way of sending the broadcast to the whole network, it would be incredibly inefficient. On a network with 100 interested receivers on a network of 10,000 endpoints, most endpoints would receive the broadcast and ultimately discard the traffic.
Unicast May Be Inefficient, but Multicast is Too Hard!
Multicast isn’t a corner case solution; it’s already alive and well in your network! Routing protocols use a link-local version of multicast to form adjacency (in most cases). VOIP solutions can use multicast also, by signalling phone endpoints to tune into a multicast stream when placing someone on hold in order to play audio. Streaming video and collaboration solutions can use multicast. Most network fabric solutions such as ACI and SDA use multicast in order to deal with broadcast, unknown unicast and multicast traffic. Multicast is not difficult, and it’s not a corner case solution. Multicast is easy to understand once you learn the fundamentals. Most of the complexity in multicast is around how receivers find the sources in order to receive the feed. Depending on the multicast solution used, this can itself be very simple or very complex. In future posts we’ll dig into the different ways multicast can be implemented and what challenges are present/solved with each.
I hope this basic primer on multicast has been helpful, and sparks an interest in learning more about it. I’ll cover some of the ways to design and implement multicast next. And, of course, I’ll be delivering the Introduction to IP Multicast breakout at Cisco Live US 2019, hope to see you there!
