IP Multicast

This article will cover IP multicast concepts, starting from the basics and continuing on to discuss the different types of multicast forwarding path trees and multicast routing protocols. It finishes with a configuration example using Cisco routers.

Introduction

There are three different methods to deliver IP packets:

• Unicast: The packet is sent to a single destination (one to one)
• Broadcast: The packet is sent to an entire network (one to all)
• Multicast: The packet is sent to a set (group) of hosts that can be on different networks (one to many)

As a side note, there is also the idea of many-to-many communication, where there are multiple sources for the same destination or where a source is also a destination. This type of communication is present in videoconferencing or online gaming applications.

With multicast, only the destinations that explicitly indicated that they want to receive the multicast traffic receive the messages sent. The routing devices’ job is to sit between the sources and receivers to determine the correct logical network topology for routing from the unicast and multicast points of view so they can correctly route the traffic. 

For example, if you have a video server acting as a multicast source that is broadcasting a live video feed, that stream of traffic can be sent only once by the server in a single stream of packets to a particular multicast address.  The multicast routers in turn will forward those multicast packets to all of the multicast receivers that are registered to that multicast address.

Multicast routing devices replicate the multicast packets from the incoming interface and send copies of them on the outgoing interfaces. 

The routing devices must prevent routing loops. It is essential to keep the flow of unwanted traffic at a minimum—a host that does not want to receive multicast traffic should receive zero (or close to zero) multicast messages.

IP Multicast Basics

IP Multicast has its own set of acronyms and terms that apply to routing devices and networks. 

IP Multicast has at its core the concept of a group. A multicast group is a set of receivers interested in receiving a particular set of data traffic. The hosts interested in receiving the data flow must join the group using the Internet Group Management Protocol (IGMP).

At a high level, the purpose of the routing device in the IP multicast network is to build a distribution tree that connects receivers to sources. The distribution tree has the source as its root. 

From the routing device point of view, the interface leading to the source is the upstream interface. The interface leading to the receivers is the downstream interface (a routing device can have multiple downstream interfaces).

The upstream interface is often called the incoming interface. The downstream interface is called the outgoing interface; as a matter of fact, most vendors use the terms “incoming” and “outgoing” in their CLI outputs.

Multicast uses the Class D IP address range (224.0.0.0 to 239.255.255.255). The source IP address of a multicast packet will always be a unicast IP address, and the destination IP address will be a multicast address.

The Class D range is split like this:

The Link Local Addresses range is reserved for the network routing protocols on a local network segment. A router will never forward packets with a destination IP address from this range.

When using IPv6, it is the ff00::/8 prefix that is used.  Like IPv4, there are specific IPv6 multicast ranges used for particular purposes.  Some have IPv4 equivalents, while others are specific only to IPv6.  Reserved IPv6 multicast addresses are also defined for use by certain protocols such as routing protocols, including OSPFv3, EIGRP, and RIP, and also for other protocols such as PIM, which we’ll talk about shortly.

At Layer 2, multicast deals with MAC addresses instead of IP addresses. Let’s consider a single VLAN with a single source and the rest being receivers. The source IP address of the packet will be the IP address of the source, and the destination IP address will be the multicast IP address of the group. The source MAC address will be the MAC address of the source, but what will be the destination MAC address of the frame?

For unicast, the 25th bit of the MAC address is set to 0, and for multicast, the 25th bit is set to 1. The range of MAC addresses for multicast groups is 0x01:00:5e:00:00:00 to 0x01:00:5e:ff:ff:ff.

There is a specific way to convert a multicast IP address to a MAC address (which we won’t be covering here). The most important point to take away is that 32 IPv4 multicast addresses could map to the same MAC multicast address.

Multicast Distribution Trees

As mentioned before, distribution trees are created to control the path that multicast traffic takes through the network. 

The simplest and cleanest form is the source tree, with the root at the source. Because this method uses the shortest path through the network, it is called Shortest Path Tree (SPT).

Below, the SPT for group 224.1.1.1 is rooted at the source, 192.168.0.1, and there is one receiver, 192.168.1.1:

For SPT, the multicast state is (S, G), pronounced “S comma G.” S is the IP address of the source, and G is the multicast group address. Considering this, the above SPT will be (192.168.0.1, 224.1.1.1). This type of notation means that a separate SPT exists for each source sending to the multicast group. 

The second type of distribution tree is the shared tree, which uses a common root placed somewhere in the network. The shared root is called the Rendezvous Point (RP).

Below is a shared tree for group 224.1.1.1, with the root located at router R3.

Source traffic is sent to the RP over a source tree and then forwarded over a shared tree to all the receivers.

Because all the sources use the shared tree, it is represented by a (*, G) entry, which in this case will be (*, 224.1.1.1).

The advantage of SPT is that it creates the optimal path between the source and the receivers. The disadvantage is that the routers must maintain state for each source.

Conversely, the advantage of the shared tree is that routers need to keep less multicast state, but the disadvantage is that sometimes the path between the source and the receivers is not optimal, which might introduce latency.

Multicast Forwarding

In multicast forwarding, the source sends the traffic to a group of hosts. The router keeps track of which interfaces are incoming and which are outgoing. Reverse Path Forwarding (RPF) is forwarding the traffic away from the source.

RPF is a core concept in multicast forwarding. RPF uses the unicast routing table to determine the upstream and downstream neighbors.  The router will forward the multicast packet only if it comes from an upstream interface (incoming interface). This RPF check ensures a loop-free distribution of the multicast traffic. The traffic is forwarded if the packet passes the RPF check; otherwise, the packet is dropped. 

The RPF check works like this:

• The router checks in the routing table to see if the source of the multicast traffic is reachable via the same interface through which the router received the traffic.
• If it is the same, it passes the RPF check, and the traffic is forwarded.
• If the RPF check does not pass, the traffic is dropped.

IGMP

The Internet Group Management Protocol (IGMP) is used to register the hosts in a multicast group on a LAN. Multicast routing devices use IGMP to learn which groups have members in their connected networks.

The multicast routing device can be a querier or a non-querier. A querier device sends query messages to determine if hosts are still interested in any multicast group traffic. Hosts send report messages to confirm that they are still interested in specific groups.

The above is valid regardless of the version of IGMP.

IGMPv2

IGMPv2 superseded IGMPv1 but is compatible with it. The difference between IGMPv1 and IGMP2 is the Leave Group message that hosts can use to communicate with the router and leave the group. The router sends a group-specific query to determine if other hosts are interested in that traffic.

The existence of the Leave Group message reduces unwanted and unnecessary traffic.

IGMPv3

IGMPv3 supports inclusion and exclusion lists. With the help of an inclusion list, one can specify which sources can send to a multicast group. This range of such multicast groups is known as source-specific multicast (SSM), and the address is 232.0.0.0/8.

IGMPv3 also supports source filtering, allowing routing devices to inform their neighbor routing devices about which sources are of interest.

Protocol Independent Multicast (PIM)

To route multicast traffic dynamically, a router must use a multicast routing protocol.  Protocol Independent Multicast (PIM) is the most popular multicast routing protocol used today and enables multicast routing devices to build what are known as distribution trees. As its name suggests, PIM is not dependent on a specific unicast routing protocol. PIM uses the unicast routing table to perform the RPF check, and it does not send or receive routing updates between routers.

PIM can operate in dense or sparse mode. The mode determines how the multicast routing table is populated and how the router forwards multicast traffic to its connected interfaces.

PIM Dense Mode

PIM Dense Mode (PIM-DM) assumes that all the hosts in the network are interested in receiving the traffic. Once the multicast traffic received passes the RPF check, the router sends the traffic to all its PIM neighbors. PIM-DM supports only source trees.

PIM-DM pushes multicast traffic everywhere in the network. Routers that do not have downstream neighbors prune the traffic, and the whole process repeats every 3 minutes. The model used by PIM-DM to send multicast traffic is efficient only in situations where active users are present in every subnet of the network.

A router sends a Prune message to a second router so that the second router will remove the link on which the Prune message is received from the (S, G) SPT. 

A router sends a Graft message to an upstream neighbor to which previously it has sent a Prune message so that the upstream router will add the link on which the Graft message is received to the (S, G) SPT. 

PIM Sparse Mode

PIM Sparse Mode (PIM-SM) works in the opposite way as PIM-DM: It assumes that no hosts are interested in the multicast traffic until they specifically ask to receive it. 

PIM-SM routers create the shared tree by sending PIM Join messages to the RP. The shared tree is rooted at the RP.

A router will send PIM Join messages in these two situations:

• The router receives a PIM Join message on any interface other than the one used to route packets to RP.
• The router receives an IGMP Report message from a host on a connected subnet.

The router to which the source is connected is called Source DR. When the source starts sending multicast traffic, the source DR sends a PIM Register message to the RP. The register message is sent as unicast and encapsulates the multicast traffic.

Suppose the RP does not know any hosts interested in the multicast traffic. In that case, it will send a Register-Stop message back to the source DR.

If the RP knows that hosts are interested, because it has received a PIM Join for a multicast group, it decapsulates the multicast traffic and forwards it. The traffic is being delivered over the shared tree up to this point.

When the multicast traffic arrives at the router where the receivers are connected, the router sees the source of the multicast traffic. Based on the unicast routing table, it sends a PIM Join over the interface through which the source is reachable, essentially creating an SPT with the root at the source.

This interface might be or might not be the same one through which the RP is reachable.

IP Multicast Configuration

This section describes the configuration of several Cisco routers to support IP multicast traffic forwarding.

The topology below depicts the network we’ll use in our discussion.

To ensure IP connectivity, OSPF runs on all the routers.

Because the multicast routing protocol is PIM-SM, we need an RP, which is the R3 loopback IP address, 1.1.1.1. In this example, the RP IP is set statically on all the routers.

The source, 192.168.0.100, sending to the multicast group 224.1.1.1, is connected on Ethernet0/0 on R1, and the receiver, 192.168.1.100, is connected on R4 Ethernet0/0.

The following configuration on R1 enables multicast routing to specify who the RP is and the interfaces that PIM-SM runs on.

ip multicast-routing
!
interface Ethernet0/0
 ip pim sparse-mode
!
interface Ethernet0/1
 ip pim sparse-mode
!
interface Ethernet0/2
 ip pim sparse-mode
!
ip pim rp-address 1.1.1.1

We have identical configurations on R2, R3, and R4. The only minor difference is the particular interfaces on which PIM-SM runs.

If everything is correct, each router should see neighboring routers as PIM neighbors. 

These are the interfaces on R1 on which PIM-SM runs:

R1#show ip pim interface

Address          Interface                Ver/   Nbr    Query  DR         DR
                                          Mode   Count  Intvl  Prior
10.0.3.1         Ethernet0/1              v2/S   1      30     1          10.0.3.4
10.0.0.1         Ethernet0/2              v2/S   1      30     1          10.0.0.2
192.168.0.1      Ethernet0/0              v2/S   0      30     1          192.168.0.1
R1#

This is the output from R1, where we can see the PIM neighbors:

R1#show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      P - Proxy Capable, S - State Refresh Capable, G - GenID Capable,
      L - DR Load-balancing Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
10.0.3.4          Ethernet0/1              00:53:38/00:01:44 v2    1 / DR S P G
10.0.0.2          Ethernet0/2              04:22:32/00:01:27 v2    1 / DR S P G
R1#

Because the source did not start to send traffic for the multicast group, but an IGMP Join was received from the receiver, the routers create only the (*, G) entry.

Here we can see that R1 has received the IGMP Join

R4#show ip igmp groups 224.1.1.1 detail

Flags: L - Local, U - User, SG - Static Group, VG - Virtual Group,
       SS - Static Source, VS - Virtual Source,
       Ac - Group accounted towards access control limit

Interface:      Ethernet0/0
Group:          224.1.1.1
Flags:
Uptime:         00:31:32
Group mode:     EXCLUDE (Expires: 00:02:32)
Last reporter:  192.168.1.100
Source list is empty
R4#

This triggers the creation of (*, 224.1.1.1) in the routers. The following is for R4:

R4#show ip mroute 224.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector, p - PIM Joins on route,
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 00:05:41/00:02:25, RP 1.1.1.1, flags: SJC
  Incoming interface: Ethernet0/2, RPF nbr 10.0.2.3
  Outgoing interface list:
    Ethernet0/0, Forward/Sparse, 00:05:41/00:02:25

R4#

As can be seen above, the outgoing interface for the multicast traffic on R4 is Ethernet0/0, and the incoming interface is Ethernet0/2, the interface to the RP.

Similar output is seen on R3 (the RP) and the outgoing interface is Ethernet0/1, the interface to R4:

(*, 224.1.1.1), 00:03:17/00:02:35, RP 1.1.1.1, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet0/1, Forward/Sparse, 00:03:17/00:02:35

R3-RP#

Once the source starts to send traffic, the RP creates the (S, G) entry, but there is no interface in the outgoing list because there is no receiver attached to the RP:

(*, 224.1.1.1), 00:09:04/stopped, RP 1.1.1.1, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet0/1, Forward/Sparse, 00:09:04/00:02:41

(192.168.0.100, 224.1.1.1), 00:00:07/00:02:56, flags: PT
  Incoming interface: Ethernet0/1, RPF nbr 10.0.2.4
  Outgoing interface list: Null

On R1, the (S, G) entry is created and the outgoing interface is Ethernet0/1, the interface to R4:

(*, 224.1.1.1), 00:01:38/stopped, RP 1.1.1.1, flags: SPF
  Incoming interface: Ethernet0/1, RPF nbr 10.0.3.4
  Outgoing interface list: Null

(192.168.0.100, 224.1.1.1), 00:01:38/00:01:55, flags: FT
  Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet0/1, Forward/Sparse, 00:01:38/00:02:50

R1#

On R4, the entry looks like this:

The (S, G) entry is created on R4 as well:
(*, 224.1.1.1), 00:11:18/stopped, RP 1.1.1.1, flags: SJC
  Incoming interface: Ethernet0/2, RPF nbr 10.0.2.3
  Outgoing interface list:
    Ethernet0/0, Forward/Sparse, 00:11:18/00:02:48

(192.168.0.100, 224.1.1.1), 00:02:46/00:00:12, flags: T
  Incoming interface: Ethernet0/1, RPF nbr 10.0.3.1
  Outgoing interface list:
    Ethernet0/0, Forward/Sparse, 00:02:46/00:02:48

R4#

The incoming interface is Ethernet0/1, the interface to R1. It is this interface and not Ethernet0/2 (the interface to RP) because the forwarding was switched over the shortest-path tree once R4 saw that the source (192.168.0.100) is reachable via Ethernet0/1:

R4#show ip route 192.168.0.100
Routing entry for 192.168.0.0/24
  Known via "ospf 1", distance 110, metric 20, type intra area
  Last update from 10.0.3.1 on Ethernet0/1, 01:10:30 ago
  Routing Descriptor Blocks:
  * 10.0.3.1, from 192.168.0.1, 01:10:30 ago, via Ethernet0/1
      Route metric is 20, traffic share count is 1
R4#

This is a basic IP multicast configuration along with some commands to check the operation of multicast routing protocols.

Conclusion

The article covered some of the basics of IP multicast.

We saw why multicast is essential and how it helps keep the traffic in the network at a minimum by avoiding replicating the traffic as many times as the number of hosts interested in receiving the traffic.

We covered the different versions of IGMP, the differences between them, and how it helps inform the routers that hosts are interested in receiving the traffic.

We discussed the multicast traffic flows in an L3 network using the unicast routing table and the information provided by the multicast routing protocols.

The article continued with the two most commonly used multicast routing protocols: PIM Sparse Mode (which assumes that there are no receivers interested in the traffic unless they request it) and PIM Dense Mode (which assumes that all the hosts in the network are interested in the traffic unless they opt out).

Finally, to see how all this works, we used a simple topology consisting of several routers configured to support IP Multicast.

FAQs