Multicast Basics

I purposely saved the best topic for last, or maybe I am just that much of a glutton for punishment that we didn’t discuss this first. We are going to cover everyone’s favorite topic: Multicast! Before configuring our environment, we need a foundation or understanding of how multicast works. It is such a massive topic that I had to keep it very short, so let’s dive into Multicast Basics without further adieu!

Why do we need Multicast?

Having worked for a media conglomerate, I often wondered why multicast exists. Was there some sadistic person who cooked up this nightmare? It turns out there are some pretty good use cases for why you would want to use Multicast; some of those are:

• Music on Hold
  • I know it is the bain of every network engineer’s existence. I still have nightmares from when a voice guy approached me and asked me to set up an entire multicast network so we could have that iconic Cisco hold music, IFKYK.
• Video Streams
  • This one makes more sense. Let’s have a bunch of servers serving up video streams, and people who want to watch them join the stream. There will be one constant stream for all viewers vs. one for all.
• Network Control Traffic
  • Specific routing protocols use link-local multicast to share routing information with their directly connected peers or peers on the same ethernet segment, for example:
    • OSPF: 224.0.0.5, 224.0.0.6
    • EIGRP: 224.0.0.10
  • Multicast DNS: 224.0.0.251
• Finally, in VXLAN, you can use multicast for underlay traffic between VTEPs.
  • This is so VTEPs can flood their MAC addresses more effectively.

How Does Multicast Work?

Multicast works on both Layer 2 and Layer 3. Internet Group Management Protocol (IGMP) is Layer 2 multicast, and Protocol Independent Multicast (PIM) is Layer 3 Multicast. It is not one or the other. You need both to route and deliver multicast across the network correctly.

Multicast falls under the range 224.0.0.0/4, and some more well-known multicast subnets are

• Link-Local – 224.0.0.0 – 224.0.0.255 (/24)
• Source-Specific Multicast (SSM) – 232.0.0.0 – 232.255.255.255 (/8)
• Administratively Scoped – 239.0.0.0 – 239.255.255.255 (/8)
  • Equivalent to RFC 1918 for multicast

Let us jump right into Layer 2 multicast.

This is in the host ↔ switch communication for multicast. Like DHCP snooping, which listens for DHCP packets, IGMP snooping listens for multicast reports and leaves. This causes less resource utilization on the switch by dealing with all the hosts who want to join or leave a multicast stream. The switch receives the frame and floods the multicast MAC out of all ports, even if hosts are not subscribed to the feed. When a host wants to join, the switch knows about the multicast stream; forwarding the join is unnecessary, and the switch will intercept it and send it down to the host.

IGMP

This is in the host ↔ router communication for multicast. A host signals via the upstream router that it wants to join a multicast group instead of the switch snooping for the join. There are three different versions of IGMP, each enhancing the protocol by adding some new features.

IGMPv1 RFC1112

IGMPv1 is legacy and has been replaced by IGMPv2. There are two two group membership reports that IGMPv1 sends;

• Host Membership Query
  • Used by the router to see if members of the group still exist
  • If multiple routers are on the same LAN, one is elected the querier, similar to how OSPF elects the DR
    • This is the device responsible for sending the query messages
• Host Membership Report
  • This is how a client joins a group
• Only supports group-specific joins (*,G)

IGMPv2 RFC2236

IGMPv2 extends IGMPv1 by adding:

• Querier election
  • If multiple routers are on the same LAN, an election is done to see who sends queries.
• Tunable timers
  • Can speed up query response times
• Group specific queries
  • A query is sent to the group address instead of all multicast hosts
    • Asks per group, not to 224.0.0.1, if anyone is listening
  • Explicit leave
    • When the client closes the application, A message is sent to the router to query that group.
    • Backward compatible with IGMPv1
    • Only supports group-specific joins (*,G)

IGMPv3 RFC3376

Used to support Source Specific Multicast (SSM), and supports source specific joins (S,G). This allows the receiver to pick the source it wants to pull the multicast stream from vs. just joining the group

Layer 3 Multicast – Protocol Independent Multicast (PIM)

Protocol Independent Multicast, or PIM, is the layer three component of multicast. It does not replace routing and full reachability between the receivers and sources. You need a routing protocol to be in place for PIM to work. There are two main PIM modes: PIM Dense Mode and PIM Sparse Mode. They are very different from each other.

PIM Dense-Mode

This can be thought of as the PUSH method for multicast traffic. Multicast traffic is sent regardless of whether you have subscribers to it. The shortest path tree (SPT) was built after the flooding.

The purple lines in the image above represent the multicast flow being “pushed” everywhere. As one can imagine, this is a huge waste of resources.

PIM Sparse-Mode

PIM-SM is the pull method for multicast traffic. A device called a Rendezvous Point (RP) is the root of the shared tree. This shared tree is from the multicast receiver to the RP and from the multicast source to the RP. When receivers join the multicast group, the join is sent toward the RP. The RP tells the receiver the shortest path tree. The receiver must contact the RP first.

I am going to stop here. Multicast is a vast topic that could be turned into a series just on its own. I wanted to ensure that there was a level setting in how multicast works for when we set up the underlay of our VXLAN environment.

Is this the first time you learned about multicast, or are you a seasoned multicast person? Let me know in the comments below or on my socials. In the next one, we will get the requirements from our manager on what is needed to build this new fabric. See you on the next one!