Chapter 3. IP Multicast at Layer 3
As discussed in Chapter 1, many unique applications leverage multicast for efficient packet delivery. In most cases, these applications use the network merely as transport for application data. Multicast senders and receivers are typically IP host machines that run these applications.
Because of the abstraction of the logical layer from the physical in the OSI model, almost any computing device can be a multicast host. Potential multicast hosts include set-top cable boxes, smartphones, tablets, laptops, personal computers, servers, routers, and so on. With this kind of ubiquity, an engineer might assume that a fully converged IP unicast network is simply multicast ready and that hosts may begin participation in multicast by simple virtue of the host’s IP connectivity. Unfortunately, that assumption is incorrect. It is true that most IP devices have some minor inherent multicast capability built in, such as support for specific link local applications. However, most operating systems do not come preconfigured to participate in specific administrative multicast groups; that function is dictated by the level of multicast participation (described by IETF RFC 1112) and by any multicast-enabled application(s) running on the host device.
It is important to understand multicast networking from the perspective of the IP host. It is equally important to understand which groups may apply to the operating system specifically and which may apply to specific applications. IP hosts that are fully multicast-aware must interact with the network to manage the flow of multicast packets, maintaining the highest level of efficiency in packet flow. After this interaction, network devices can overlay an IP multicast forwarding topology on top of the established IP unicast network, similar to other technologies like MPLS or IPSec VPNs.
In this chapter, we explain the functionality of clients and servers and what constitutes membership to a group. You learn about the different types of multicast trees and how they are built using protocol independent multicast (PIM). Finally, we explain the relationship between routing and forwarding and what this looks like from the perspective of a Layer 3 device. The elements in this chapter are critical to understanding how multicast works. Be sure you have a good understanding of what is explained in this chapter before you move on.
Multicast Hosts
Most major multicast applications function in a specific client/server model. Many engineers make the mistake of assuming that a server is always a network multicast sender, and that clients are the receivers. Remember, multicast application flow models (one-to-many, many-to-one, many-to-many) vary widely depending on the needs of the application.
In a many-to-many implementation, it is not uncommon for servers to both send and receive multicast messages. Clients in a many-to-one model may be the multicast packet senders, updating a single server acting as a receiver. Another one-to-many application may support the traditional server as sender, and clients as receivers (host model). More intricate still are multicast applications that include these functions only within the networking infrastructure, applications that have no traditional IP hosts listening to or sending to the infrastructure multicast groups. These applications often enable network operations or network transport of other packets. This warrants an exploration of how clients, servers, and network devices support host-based multicast applications, as well as which established IP multicast groups (or group blocks) are used to identify these applications.
Networked Groups: Client/Server
An IP multicast group is also known as a host group. The original idea behind a host group was that one IP host, perhaps a server, would act as a source, sending IP datagrams toward hosts acting as receivers. The host group is the identifier for those hosts. It is accepted that there are no restrictions on the hosts that can participate in a group or on where those hosts are located. All hosts in the host group are equal, and any host may send packets toward the group, regardless of group membership. A host may also be interested in, or send packets to, more than one group at any given time. To manage this process, hosts need to have a dynamic mechanism to join or leave a group.
Chapter 2 introduced the basic concept of multicast routing, switching, and forwarding. Routers that act as gateways must have a way of knowing if a host on a given segment wishes to receive multicast packets. Gateway routers need that information to build forwarding trees with other routers in the forwarding path between sources and receivers. Without this membership information, routers could not build a multicast routing or forwarding tree. Consequently, a join or leave by an IP host in the group is the mechanism used to notify the network of membership to a specific group.
Note
It is important to note that the IGMP RFC language specifically calls these membership reports join/leave messages. However, to avoid confusion with PIM join/prune messages, many Cisco documents simply refer to the IGMP join/leave as a membership report. Both are accurate; this text uses the RFC terminology.
Hosts must manage group membership dynamically. A host may join a group at any time and may also leave at any time, or it can also simply leave through natural attrition with timers. Hosts can participate in many groups at once. Additionally, host group numbers can change, if necessary. Some host groups are permanent, meaning the group is assigned a “well-known address,” whereas other host groups can be dynamically assigned through dynamic group assignment protocols or applications. IPv4 hosts that need to join and leave host groups do so by sending updates to routers through Internet Group Messaging Protocol (IGMP), and IPv6 hosts use Multicast Listener Discovery (MLD). RFC 1112 specifies three levels of IP multicast host interest: levels zero through two. Table 3-1 shows the differences between each host level.
Each of the various host operating systems can accommodate any of these three levels of multicast participation. Host and server operating systems can also use Dynamic Host Configuration Protocol (DHCP) and Multicast Address Dynamic Client Allocation Protocol (MADCAP) services to dynamically assign IP addresses and IP multicast group assignments for certain applications. To learn more about host multicast configuration, consult the operating system user manual for the device in question.
Network Hosts
In certain cases, network devices (routers and switches) can function as either an IP multicast receiver or sender as though they were a networked host system. For the most part, the applications that require network device participation in the group are related to network infrastructure. In fact, most of the IP multicast communication between network hosts is for protocol intercommunication, and much of this traffic only travels between network devices connected to a common local segment. The Local Network Control block of addresses facilitates this communication; these addresses are universally assigned and managed by Internet Assigned Numbers Authority (IANA). Routing protocols, such as OSPF and EIGRP, are common examples of this type of IP multicast traffic.
Note
Many protocols require special configuration and packet handling on non-broadcast media. Layer 2 non-broadcast domains, like Frame Relay, do not forward broadcast or multicast packets to all destination ports by default. Additional considerations for many protocols, including Enhanced IGRP (EIGRP), are often necessary within an OSI Layer 2 domain.
There are other important infrastructure protocols that use multicast communications and require packets to flow beyond local segments. Some of these protocols may not need routing beyond a local router or switch, from one local network to another. A fully functional IP multicast network is requisite for those protocols that require communication to travel beyond a particular networking device. Example infrastructure protocols that need full network forwarding are multicast virtual private network (mVPN), heartbeat and cluster applications, and virtual extensible local-area network (VXLAN).
Note
The original VXLAN standard uses IP multicast for infrastructure communications—broadcast, unicast, and multicast messages (BUM). More recent standards can also use unicast protocols as well.
Some infrastructure protocols have specific IANA assigned host groups from the Internetwork Control, Ad-Hoc, or other multicast blocks. Other protocols require domain-specific administrative assignment and management from the Administratively Scoped IPv4 block or private IPv6 ranges. For troubleshooting purposes, network administrators may simply want to join a network device to a particular group. The network device then participates to the extent of its required capabilities in any multicast groups that have been assigned to it. This means that each IP multicast packet must be decapsulated, read, and sent to the device processor for additional processing, if the device is a member of the destination host group.
Multicast Routing: An Introduction to Protocol Independent Multicast and Multicast Trees
A routing protocol is used to facilitate communication between devices on different segments of a network. Providing a method of communication might be the primary function, but there are other purposes for a routing protocol, including loop prevention, path selection, failure detection, redundancy, and so on. Originally, multicast required a unique routing method that was completely autonomous to the unicast routing protocol. Distance Vector Multicast Routing Protocol (DVMRP) and Multicast Open Shortest Path First (MOSPF) are two examples of these protocols. Specific multicast routing protocols are no longer required because you can take advantage of the underlying unicast routing protocol. Consequently, DVMRP and MOSPF have fallen out of favor.
A unicast routing protocol is forward-looking, and the routing information or routes stored in the routing database provide information on the destination. The opposite is true for multicast routing. The objective is to send multicast messages away from the source toward all branches or segments of the network interested in receiving those messages. Messages must always flow away from the source, and never back on a segment from where the transmission originated. This means that rather than tracking only destinations, multicast routers must also track the location of sources, the inverse of unicast routing. Even though multicast uses the exact inverse logic of unicast routing protocols, you can leverage the information obtained by those protocols for multicast forwarding. Why? Because a multicast source is an IP host, a possible unicast destination, whose location is tracked by the unicast routing table, like any other IP host in the network.
This allows a network to avoid using another full routing protocol, minimizing the memory space that needs to be consumed. All of the functionality that is built into the unicast routing protocol, including loop prevention, path selection, failure detection and so on, can be used for multicast. Modern IP multicast routing uses protocol independent multicast (PIM), which leverages unicast routing information, to forward messages to receivers. The process of determining where the multicast messages are to be sent is referred to as building the tree.
Seeing the Forest Through the Trees
Anyone who engages in the study of networking inevitably encounters the concept of network trees. For example, Spanning Tree Protocol is a well-known tool for switches to build Layer 2 forwarding trees that are devoid of network loops. Trees are important because they allow routers and switches to calculate forwarding tables that follow a prescribed and specific path for frames and packets without making mistakes or causing network loops. In fact, the design of complex forwarding chips known as application-specific integrated circuits (ASICS), the “special ingredient” to hardware forwarding, depends on complex tree mathematics and discrete algebraic logic gates.
Trees are also convenient in that they can be visually represented. Visual trees can make complex forwarding decisions easier to understand by human beings. But what is a network tree really and why are they important? This section introduces the uninitiated to basic tree theory and, in particular, to those trees used in multicast forwarding. Understanding this information is a fundamental requirement for understanding how multicast protocols create loop-free forwarding topologies.
What Is a Network Tree?
Trees and tree building are an important part of mathematics and computer science. Mathematically, a network tree is essentially a graph, or directed graph (digraph), that represents a hierarchical logical structure. Like real trees, graphical trees have roots, branches, and leaves. Leaves always diverge away from the root of the tree. Figure 3-1 depicts a network that is translated into a graph with a root, branches, and a leaf. The graph is directional because traffic is forwarded from R1 and toward Host B, the end of the network tree being the last-hop router (LHR), or R7.
The root of a tree is the beginning of the graph. A branch is anywhere the tree diverges into two or more separate paths and a leaf is any place in which the tree ends. Each of these components can be represented mathematically, through mechanisms such as algebraic Boolean equations.
Network devices share information with each other in order to build trees. A network tree allows routers and switches to act together in creating forwarding paths. The network can build the forwarding path based on any desirable outcome (such as loop avoidance, efficiency, shortest path management, predictive failover, and others). Although it is true that each network device can make separate decisions, the hope is that the network will collectively build trees that map ideal paths through the network.
One example of a network tree are the shortest path trees built by Open Shortest Path First (OSPF) routers. OSPF routers build a database of possible paths from each router interface (root) to each possible IP destination (leaf). There may be many paths to a destination. The router compares and then ranks each path and creates a list of shortest (often meaning fastest) paths. Messages are forwarded toward the destination using the best path. The next-best paths are kept in memory so that the router may failover to a secondary path if the primary path becomes unusable.
Multicast routers make extensive use of network trees. The primary purpose of a multicast tree is to build an efficient loop-free forwarding path from the source of the multicast stream toward all the receivers. Looking at the entire network is a unidirectional way to look at the end-to-end path and not just next-hop in the forwarding path, which is the local view on any given network router.
The root of the tree from the perspective of the network is the router closest to the source (server) of the packet stream. A leaf is any router with an attached IP receiver (client) for the given stream. A branch in a multicast tree is any router that must perform replication to connect the root to the leaves that are not in the same segment.
Looking at each individual router, the tree is built from the interface(s) closest to the source toward the list of interfaces that are in the path, including leaves and branches. Understanding multicast trees requires an understanding of how routers represent each component of the tree, how they build a loop-free topology, and how multicast messages are forwarded to the destination.
Concepts of PIM Group States
Spanning Tree Protocol is a well-known tool for switches to build Layer 2 forwarding trees that are devoid of network loops. Multicast trees serve the same purpose. These trees are built by the PIM protocol. Command line routers cannot represent the tree visually, just like STP on command line switches. Instead, routers create and display a state table, which represents the state of each multicast tree maintained by the router. You can display the IP multicast state table in most of the Cisco platforms using the show ip mroute command, as demonstrated in Figure 3-2.
The output of the command is divided into two parts, network flags and multicast group state along with interface flags. The first part of the output provides generic platform and multicast state flags. These flags change based on the platform consideration and provide the information of multicast flow in the multicast group state section.
The multicast group-specific information in the multicast group state is (*,G) and (S,G). This provides tree information for each maintained multicast flow in the form of a “state table.”
The RP is the rendezvous point for the multicast group, which is discussed in greater detail later in the section “Two Types of Trees.”
Flags provide information such as the type of multicast stream and the control-plane information in use. These flags change slightly based on platform, and it is important to refer to the definitions in the first part of the output to clearly understand this information.
Note
Routers use reverse path forwarding (RPF) checks to keep the multicast topologies loop-free. At its most basic, an RPF check is a comparison of incoming packets to the vector established in the unicast routing table for the source of the packet. It is the inverse of a unicast forwarding lookup, being more concerned with where the packet came from rather than where it is going. In this example, the RPF check is in the direction of the RP. RPF checks are discussed in more detail in the subsection “Reverse Path Forwarding.”
Outgoing interface list (OIL) and incoming interface list (IIL) are also provided in this output. The OIL lists the outgoing interfaces local to the node for the multicast state entry. The IIL in the output shows the incoming interface list for the multicast state for this node. These two lists are created by routers after the RPF check has been performed.
Generally speaking, show ip mroute is the first command that an administrator executes to understand the state of multicast flow on the Layer 3 device.
The (*,G) State Entry
A (*,G) entry in an mroute table represents a router’s relationship to the leaves of a tree. Remember that IGMPv1 and IGMPv2 hosts use the (*,G) to signal intended membership to upstream routers. The router adds the (*,G) to the mroute table. Figure 3-3 shows an example network in which a host is connected to Router 7 (R7) and is sending an IGMP join request for multicast group 239.1.1.1. The sender is connected to R3 and has an IP address of 192.168.20.1.
Examine the output from the show ip mroute command on R7 in Example 3-1.
Example 3-1 show ip mroute Command Output
R7#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 10:50:13/00:01:56, RP 192.168.1.1, flags: SJCF
Incoming interface: Null, RPF neighbor 0.0.0.0
Outgoing interface list: FastEthernet1/0, Forward/Sparse, 01:35:17/00:02:22
The table output shows that R7 has learned of group 239.1.1.1 and the router calculating the tree knows that the host members are downstream from interface FastEthernet1/1. In this case, the outgoing interface represents the path toward the host receivers. Although this router has only one leaf-facing interface, it is possible to have many downstream interfaces, consequently creating tree branches. All of the leaf-facing interfaces are added to an outgoing interface list (OIL). Using PIM messaging, the router forwards this (*,G) entry to routers upstream. Each PIM router in the path adds the (*,G), and the interface that the update was received on to the OIL for that multicast group.
The (S,G) State Entry
The (S,G) entry in the mroute table represents the router’s relationship to the source of the multicast stream. In order to build a tree with an (S,G) the router needs to receive and identify packets from the source, or receive some type of notification either from the network or from hosts using an (S,G) join via IGMP. After a source for a group is known by the router it adds the (S,G) to the table using the show ip mroute command, as demonstrated in Example 3-2.
Example 3-2 (S,G) Entry Added to the mroute Table
R7#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 10:50:13/00:01:56, RP 192.168.1.1, flags: SJCF
Incoming interface: FastEthernet0/0, RPF nbr 192.168.2.2
Outgoing interface list: FastEthernet1/0, Forward/Sparse, 01:35:17/00:02:22
(192.168.20.1, 239.1.1.1), 01:55:30/00:03:26, flags: CFT
Incoming interface: FastEthernet0/0, RPF nbr 192.168.2.2
Outgoing interface list: FastEthernet1/0, Forward/Sparse, 01:55:30/00:03:12
In this output (using the previous example topology), the router has received packets destined to group 239.1.1.1 from host 192.168.20.1. The router updates the table, which now shows that the (*,G), entry (*, 239.1.1.1) has an incoming interface of FastEthernet0/0 with Reverse Path Forwarding (RPF) Neighbor (nbr) 192.168.2.2. This indicates the router has determined that 192.168.20.1 is upstream on interface FastEthernet0/0, which is not in the path of the leaf, using a RPF check. The (S,G) entry (192.168.20.1, 239.1.1.1) also has an incoming interface and an OIL.
Routers can forward packets using either the (*,G) or the (S,G) entries, as long as the paths are determined to be loop-free. In fact, each type of entry represents a different type of tree; the incoming and outgoing interfaces being the path of the tree from the root, to branches, and finally to the leaves. These two different types of trees are discussed in the next section.
Reverse Path Forwarding
Under normal unicast routing rules, packet-forwarding decisions are based on the destination address of the packet arriving at a router. The unicast routing table consists of learned networks and the associated exit interfaces for each destination network. Thus, the unicast routing table is used for destination lookups by routers so that each packet is forwarded in the most appropriate direction. The primary responsibility of each unicast routing protocol is to find and populate the routing table with the best path toward the destination, while preventing any packets from looping back toward the packet sender (source). The router’s primary role is to select paths from among many protocols, again ensuring a loop-free topology.
Using IP multicast, the router forwards the packet based on a lookup of where the source is, the exact reverse of the unicast forwarding methodology. The router’s multicast forwarding state runs more logically by organizing tables based on the reverse path, from the receiver back to the root of the distribution tree. Consequently, the multicast network is a true overlay of the unicast network and even uses the unicast routing table to ensure a loop-free multicast forwarding tree. This process is known as reverse path forwarding (RPF). For (*,G) entries, the root of the distribution tree is the RP. The RP is at the center of the PIM sparse-mode state logic and it maintains the path toward all sources and receivers in each sparse-mode multicast domain. You will learn more about RP functionality in the PIM section. For the (S,G) entries, the root for the distribution tree is the router that connects to the multicast source. In short, incoming multicast packets will not be accepted/forwarded unless they are received on an interface that is the outgoing interface for the unicast route to the source of the packet. Figure 3-4 and Figure 3-5 represent this process occurring on R4.
Figure 3-4 shows a multicast packet coming inbound to R4 on interface E0/0. The source IP of the multicast sender is 192.168.20.1. The router performs an RPF lookup on that source to check that E0/0 is indeed in the direction of the route for network 192.168.20.1. A show ip route on R4 shows that the IP unicast network 192.168.20.0/24 is in fact located via E0/0. The show ip rpf output for source 192.168.20.1 also shows that the router has confirmed the reverse path to be E0/0 for network 192.168.20.1. With this confirmation, the router can now confidently forward the multicast packet, knowing that a network loop is unlikely.
Figure 3-5 shows this same process, except that for some unknown reason the source multicast packet is received on interface E0/2. Using the same lookup information, the router can easily determine that the reverse unicast path for network 192.168.20.0 is not in fact located out E0/2. This indicates that there is likely a forwarding loop in the multicast topology. This can occur for many reasons, especially in the event of misconfiguration. The router drops this packet to prevent further propagation of the multicast packet loop. In this case, the PIM tree has served its purpose and prevented the router from creating or continuing a network loop.
This section is meant only to introduce you to the concept of RPF checking. For a more in-depth discussion of RPF checking and the associated mechanics, see Chapter 5.
Two Types of Trees
The two types of trees used in multicast networks to control the distribution of traffic are source trees and shared trees. A source tree originates from the device sending the multicast messages. A shared tree originates from a device in the network called a rendezvous point (RP). The RP manages information about the sender or source of the multicast messages, but is not the real source of the tree. When a receiver is interested in getting multicast messages from a stream that uses a RP, its gateway router contacts the RP, and, in turn, the RP matches the receiver with the real source of the tree. When the connection is made between the receiver and the source, the RP will no longer be in the path; more information on that in the following sections.
Source Trees (Shortest Path Trees)
The most common type of multicast tree is the source tree. A source tree is one in which the network routers build a tree for each (S,G) state in the network. From the perspective of the network, the root of the source tree is the router closest to the source. The tree extends from the root router in a direct path toward all of the group members. This creates a tree in which the path might look similar to the one shown in Figure 3-6.
Network trees can sometimes be difficult to understand. This is true regardless of what protocols are building the tree. As shown in Figure 3-6, the tree overlays the entire network. This is simple enough; however, each router in the network must calculate the tree independently based on the information it has received, whether by dynamic protocol updates (PIM), or by configuration. From each router’s perspective, the tree is smaller but has a similar structure built on a root, leaves, and replication points, or branches. In essence, the mroute table entries represent the smaller trees local to each router.
An incoming interface (the one closest to the source) and an OIL connect the source packets to the group members. Using reverse path forwarding, the router checks for loops and creates the OIL from the best (sometimes called shortest) paths from the unicast routing information base (RIB). For this reason, a source tree is also called the shortest path tree. The path is calculated and added to the mroute table, which is also called the multicast routing information base (MRIB).
The tree can only be calculated if there is a valid, sending source; otherwise, it has no root. Any (S,G) installed in a router’s MRIB essentially represents a source tree. If all the routers in the network have correctly calculated the direction of the source and all subscribed hosts, following the path should be as simple as following the packet path from each incoming interface through each OIL in the network.
A source tree will, of course, branch any time a router must forward group multicast packets for an OIL with more than one interface. After the local tree (the router’s mroute table) is populated, it performs any necessary packet replication through the network tree. In the example network, the source tree is replicated only at R3, as depicted earlier in Figure 3-6.
Note
Trees are usually drawn to only include Layer 3 (IP) path and replication. The tree does not generally include replication or flooding that may occur at Layer 2 of the OSI model, because an mroute entry is not required for this type of same-segment forwarding.
The network continues to build trees for each group and each source. Depending on the location of the packet sources and the group members, the shortest path may be different for each (S,G) pair. A separate and distinct tree is maintained for each unique (S,G) entry. Figure 3-7 shows the same example network with two source trees, one for each (S,G) pair, for groups 239.1.1.1 and 239.2.2.2 respectively.
Shortest path trees are an efficient way to use bandwidth and links in an IP multicast network; however, depending on how the tree is constructed (or, in other words, which protocol is building the tree), the administrative and control-plane overhead can become overly burdensome. For this reason, the multicast engineers at the IETF introduced another type of network tree: the shared tree.
Shared Trees
A shared tree uses a different philosophy for distributing multicast packets. One problem with a source tree model is that each router in the path must share and maintain state information. Having a large number of groups, which consequently results in having a large number of trees, puts additional strain on control-plane resources.
The shared tree, on the other hand, uses a shared point in the network from which to build the distribution tree (this is used in PIM sparse mode). This location is called a rendezvous point or RP and is therefore the root of the tree. The (*,G) state information is shared upstream from the IGMP member routers to the RP and the routers in the path build the tree from the RP. Each router still uses reverse path forwarding (RPF) checks to keep the topology loop-free, but the RPF check is in the direction of the RP, not the source. Figure 3-8 depicts a shared tree built from the root RP to the routers with host group members.
Notice the RP placement has no relation to the IP multicast source. The RP may or may not be in the direct path (shortest path) between the group source and the group client(s). In fact, it can be placed outside of the path entirely. For this reason, a shared tree is also sometimes called a rendezvous point tree (RPT).
The advantage to using this type of tree is that all non-RP routers can conserve control-plane resources during stream establishment or during host maintenance. Each (*,G) is a single tree, regardless of the location of the source and only one tree is required for the group, even if there are many sources. This means that each non-leaf and non-RP router need only maintain the (*,G) for the entire group. In addition, the network path is pre-determined and predictable, which leads to consistent network operations.
Branches on a Tree
Branches are built when a router needs to send information to multiple destinations that require the use of multiple outgoing interfaces, such as, for example, more than one interface entry in the OIL. Remember, we are building a tree and must eliminate any loops that may cause duplicate information to be sent to a receiver.
Examining Figure 3-9, we now see two receivers requesting information from the same multicast stream. Based on the shortest path learned from the routing protocol, R3 becomes a branch in the tree. In the case of the receiver connected to R6, the decision for R3 only has one option, which is to send the multicast information to R6. With the receiver connected to R7, R3 has the option of sending it to R1 or to R4 and needs to decide which neighbor will receive the stream. In this example, the best path to the client connected to R7 is via the R4-R5-R7 path.
PIM Neighbors
The primary purpose of PIM is to share multicast source/receiver information and to build loop-free trees. With most unicast routing protocols, routers need to build neighbor relationships in order to share information. PIM has the same neighbor requirement as these unicast protocols. The PIM process begins when two or more routers establish a PIM neighbor adjacency on a given segment. To begin the adjacency process, any interfaces participating in multicast routing must be configured for PIM communications. In Cisco IOS, using the ip pim interface command with the selected PIM mode enables PIM communications on a specific interface.
Routers discover PIM neighbors by sending PIM hello messages to the link-local multicast address 224.0.0.13 out each PIM-enabled interface. The hello messages are sent every 30 seconds to refresh neighbor adjacencies. Hello messages also have a neighbor hold-time value, typically 3.5 times the hello interval, or 105 seconds. If this hold time expires without a refresh from the neighbor, the router assumes a PIM neighbor failure on that link and tears down the associated PIM adjacency. The router continues to send hello messages on any PIM-enabled links every 30 seconds to ensure adjacency occurs with any connected routers or if the failed router returns to service.
To improve security, an MD5 hash can be used to authenticate PIM hello messages with neighbors. You may also choose to add a PIM neighbor filter using an access control list (ACL). This provides you with the ability to control which devices you will receive PIM messages from.
In Example 3-3, the output from R4 shows that it has learned about four PIM-enabled neighbor routers on interfaces Ethernet0/0 through Ethernet0/4. Each corresponding neighbor router also has PIM enabled on the interface connected to R4. Pay very close attention to the flags indicated by Mode: in the output.
Example 3-3 PIM Neighbors Table
R4#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
192.168.54.5 Ethernet0/0 06:25:54/00:01:33 v2 1 / DR S P G
192.168.42.2 Ethernet0/1 06:27:10/00:01:20 v2 1 / S P G
192.168.41.1 Ethernet0/2 06:27:10/00:01:28 v2 1 / S P G
192.168.43.3 Ethernet0/3 06:27:10/00:01:34 v2 1 / S P G
Designated Routers
A single network interface and IP address may connect to a multipoint or broadcast network, such as Ethernet. If the network is PIM-enabled, many neighbor adjacencies can occur, one for each PIM-enabled IP neighbor. If every PIM router on the segment were to attempt to manage the tree state, confusion and excess traffic could occur. Similar to OSPF, IETF versions of PIM use a designated router (DR) on each segment. Much like an OSPF DR, the PIM DR manages state information and PIM updates for all the routers on the segment.
The DR selection process occurs when all neighbors on a segment have replied to PIM hello messages. Each router on a segment selects one router to function as the DR. The DR router is chosen using the PIM DR priority parameter, where the highest priority router is selected as the DR. The DR priority is configurable and sent in the PIM hello message. If the DR priority value is not supplied by all routers, or the priorities match, the highest IP address is used to elect the DR, which is the IP address of the interface sending the PIM message. By default, all interfaces have a PIM DR priority of 1. All routers on the segment should select the same DR router, consequently avoiding conflicts.
When the DR receives an IGMP membership report message from a receiver for a new group or source, the DR creates a tree to connect the receiver to the source by sending a PIM join message out the interface toward the rendezvous point, when using any-source multicast (ASM) or bidirectional PIM (BiDir), and to the source when using source-specific multicast (SSM). When the DR determines that the last host has left a group or source, it sends a PIM prune message to remove the path from the distribution tree.
To maintain the PIM state, the last-hop DR (the DR for the router pair closest to the group receivers using IGMP) sends join-prune messages once per minute. State creation applies to both (*, G) and (S, G) states as follows:
State creation of (*,G) tree: IGMP-enabled router receives an IGMP (*, G) report. The last-hop DR sends a PIM join message toward the RP with the (*,G) state.
State creation of (S,G) tree at source: Router receives multicast packets from the source. The DR sends a PIM register message to the RP. In the case of the (S,G) entry, this is the DR closest to the source or the first-hop DR.
State creation of (S,G) tree at receivers: IGMP-enabled router receives an IGMP (S,G) report. The last-hop DR sends a PIM join message toward the source.
Figure 3-10 shows the efficiency of using designated routers on a LAN segment in a PIM sparse-mode (PIM-SM) design. In the diagram, the connecting interface on SW1 has a default PIM DR priority of 1, whereas SW2’s interface has a configured priority of 100.
Note
Both SW1 and SW2 are operating in L3/routed mode.
SW2 is selected as DR, and only one PIM register message is sent to the rendezvous point (RP).
The configured DR priority and DR-elected router address for each interface can be shown by issuing the command show ip pim interfaces in IOS/XE or show pim interface in IOX-XR. For NX-OS, use the show ip pim neighbors command instead. The output in Example 3-4 is from an IOS router. Notice the DR Prior field and the DR address fields in the output.
Example 3-4 Displaying the DR Priority and DR-Elected Router Address for Each Interface
CR1#show ip pim interface
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
192.168.63.3 Ethernet0/0 v2/D 1 30 1 192.168.63.6
192.168.43.3 Ethernet0/1 v2/S 1 30 1 192.168.43.4
192.168.31.3 Ethernet0/2 v2/S 1 30 1 192.168.31.3
192.168.8.1 Ethernet0/3 v2/S 0 30 1 192.168.8.1
PIM Messages: Join, Leave, Prune, Graft, and Assert
Routers build trees using multicast state information shared between all the IP multicast routers in the network. Different types of state messages help the router build the tree appropriately. These messages draw their nomenclature from tree-related words: join, leave, prune, and graft.
The most current version of PIM for IPv4 is PIMv2, whereas PIM6 is the current version for IPv6. When PIM is enabled globally on Cisco routers, the protocol defaults to PIMv2 and PIM6. PIM uses negotiated neighbor adjacencies similar to OSPF to build a network of routers for multicast information sharing.
There are several types of PIM messages, but all contain the same PIM message format or header, as shown in Figure 3-11, the key fields for which are described in the list that follows:
Version is the PIM version used
Type:
1. Hello message sent to all PIM neighbors and may contain a hold-time value and/or the LAN prune delay time. The hold-time signifies how long the neighbor will keep the neighbor relationship without receiving an update. The LAN prune delay is used on multi-access networks for propagation delay.
2. A register message is sent by a DR or a PIM multicast border router (PMBR) to the RP, indicating that a source is sending traffic to a particular multicast group.
3. The register-stop message is a unicast message sent by the RP to the DR after the SPT is created.
4. Join/prune messages are sent by routers to the upstream sources and RPs. As the name indicates, join messages are sent to join a stream and prune messages to leave a stream.
5. Bootstrap messages contain several entries for the election of the bootstrap router (BSR).
6. Assert messages are used to elect the PIM forwarder.
7. Graft messages are used in a PIM-DM environment to indicate the desire to receive a multicast stream.
8. A graft acknowledge or graft-ack is sent to the graft originator upon receipt of an (S,G) entry.
9. A candidate RP advertisement is used to send advertisements to the BSR.
10. Checksum is a one’s complement sum of the entire message.
Routers and L3 switches running PIM send periodic hello messages on PIM-enabled interfaces to discover neighbors. These messages are sourced with the IP address of the outgoing interface and are sent to all PIM routers with the multicast destination address of 224.0.0.13. They contain information such as the hello period time, hello hold-time, capabilities, IP address, and so on. The packet capture in Example 3-5 demonstrates a hello message. Pay special attention to the highlighted areas, the destination multicast addresses at Layers 2 and 3, the PIM version (v2), the DR priority, and the PIM message type (Hello).
Example 3-5 Hello Message Packet Capture
Ethernet Packet: 72 bytes
Dest Addr: 0100.5E00.000D, Source Addr: AABB.CC00.0430
Protocol: 0x0800
IP Version: 0x4, HdrLen: 0x5, TOS: 0xC0 (Prec=Internet Contrl)
Length: 58, ID: 0x04CB, Flags-Offset: 0x0000
TTL: 1, Protocol: 103 (PIM), Checksum: 0xE818 (OK)
Source: 192.168.43.4, Dest: 224.0.0.13
PIM Ver:2 , Type:Hello , Reserved: 0 , Checksum : 0x23E1 (OK)
Type: 1 , Length: 2 , Holdtime: 105
Type: 20 , Length: 4 , GEN_ID: -389360719
Type: 19 , Length: 4 , DR Priority: 1
Type: 21 , Length: 4 , State Refresh: 16777216
The packet capture in Example 3-6 shows an example of a join/prune message for the group 239.1.1.1. The output also indicates the source of the multicast stream (192.168.8.8) and the number of sources joined to the group. Although the destination address is the multicast address of 224.0.0.13, the PIM header contains the destination IP address, which is 192.168.43.3, and indicates a type of join/prune (see highlighted sections). This message was sent from 192.168.43.4 to 192.168.43.3.
Example 3-6 Join/Prune Message Packet Capture
Ethernet Packet: 68 bytes
Dest Addr: 0100.5E00.000D, Source Addr: AABB.CC00.0430
Protocol: 0x0800
IP Version: 0x4, HdrLen: 0x5, TOS: 0xC0 (Prec=Internet Contrl)
Length: 54, ID: 0x0508, Flags-Offset: 0x0000
TTL: 1, Protocol: 103 (PIM), Checksum: 0xE7DF (OK)
Source: 192.168.43.4, Dest: 224.0.0.13
PIM Ver:2 , Type:Join/Prune , Reserved: 0 , Checksum : 0x308C (OK)
Addr Family: IP , Enc Type: 0 , Uni Address: 192.168.43.3
Reserved: 0 , Num Groups: 1 , HoldTime: 210
Addr Family: IP , Enc Type: 0 , Reserved: 0 , Mask Len: 32
Group Address:239.1.1.1
Num Joined Sources: 1 , Num Pruned Sources: 0
Joined/Pruned Srcs:
Addr Family: IP , Enc Type: 0 , Reserved: 0
S: 1 , W: 0, R:0, Mask Len: 32
Source Address:192.168.8.8
Join
When a host wishes to join an IP multicast stream, it does so with a join message. A join for IGMPv2 includes the (*,G) entry, and the router that receives the initial join prepares to join the larger network tree. Using a PIM join/prune message, the router shares the join with other upstream neighbors, joining the router to the larger network tree. This process requires the addition of a rendezvous point (RP) that will be discussed shortly.
Leave and Prune
When a host no longer wishes to receive the stream, it can issue a leave message to the upstream router. If the upstream router has no other downstream hosts with a desire to receive the stream, it will remove the associated (*,G) from the MRIB and send a PIM prune message to neighboring routers. A prune may also be sent if IGMP has not updated the upstream router’s join timer, or if it is a non-leaf router that is not a part of the network path. As the name implies, a prune essentially cuts the router from any paths in the large network tree.
Graft
Because multicast networks are dynamic, a previously pruned router may need to rejoin the stream. In the case of dense-mode operation, the pruned router sends a graft message to upstream neighbors, informing the network that downstream host(s) once again desires the stream. The graft message is sent during the three-minute prune expiration time; otherwise, the router will send another join message.
Assert
Finally, what happens to a tree when there are two or more routers upstream from a single host or server? Remember, the purpose of multicast is to create more efficient forwarding over loop-free topologies. Having two routers sending replicated packets for a single stream while also managing upstream protocol communication would defeat this purpose. In a situation where multiple routers have the same distance and metric values, one of the routers must have a way to assert control over that part of the tree. The router with the highest IP address is the winner and the assert message tells upstream routers which router should forward the stream. Any router that loses the assert will suppress multicast tree building for each asserted group until such time as the assert expires, which may be caused by a failure in the asserting router.
The way routers use joins, leaves, prunes, grafts, and asserts (if at all) depends entirely on the type of multicast routing protocol being used in the network. This subsection serves only to introduce the terms as they relate to a network tree. For detailed information on how these messages are used to build complex topologies, refer to Chapter 7, “Operating and Troubleshooting IP Multicast Networks.”
PIM Modes
PIM uses unicast routing information to forward multicast messages. One of the key elements is the “I” in PIM. “Independent” indicates that any routing protocol can be used to build multicast trees and forward to the appropriate destination. Forwarding of the multicast messages can operate in the following modes: dense, sparse, and sparse-dense.
PIM Dense-Mode
In dense-mode (DM) operation, multicast messages are flooded throughout the entire DM network. When a downstream router receives the multicast packet but does not have a downstream receiver interested in the multicast stream, it responds with a prune message. Consequently, multicast messages are flooded and then pruned approximately every three minutes. This can be a serious issue for large networks or networks with slower connection speeds as in a wide-area network (WAN). The amount of traffic generated may cause network outages.
This does not mean that DM is bad. It means that you need to use the proper tool for the job. DM is extremely easy to implement because there is no need to have a RP and consequently no (*,G) entries. Where DM makes the most sense is in a small network with high-speed connections. The use of the PIM-DM state refresh feature keeps pruned state from timing out, allowing even greater scalability.
The IETF implementation of PIM dense-mode (PIM-DM) is often referred to as a push model for tree building. The name is derived from the fact that all dense-mode nodes assume that all other PIM neighbors have an interest in each source tree. The PIM-DM router floods (pushes) (S,G) path updates for each PIM neighbor, regardless of expressed interest. PIM-DM routers may have to process and maintain unnecessary PIM updates, making PIM dense-mode very inefficient for most multicast implementations. The use of dense mode assumes a very limited number of sources and a network in which each subnet is likely to have at least one multicast receiver for each (S,G) tree in the MRIB (multicast routing information base).
In the push model, joins, prunes, and grafts are very important to maintaining a tree. After the (S,G) tree is flooded throughout the network, any dense-mode routers without downstream listeners will prune themselves from the tree. The router places the removed path in a pruned state in the MRIB, and the path is not added to the mFIB (multicast forwarding information base).
PIM-DM routers that maintain the (S,G) state information must continue to flood multicast traffic (forwarding) down tree branches that have not been pruned. During the convergence of the PIM-DM network, unwanted traffic may reach routers that do not require the multicast stream, resulting in these routers sending the traffic to the bit bucket.
The pruning PIM-DM routers send PIM prune messages back upstream toward neighbors, and those neighbors then prune that particular tree branch, preventing traffic from flooding on that branch. This flood prune process repeats every three minutes. Excessive traffic flooding and PIM management processing make PIM dense-mode very inefficient and undesirable in larger networks.
Tip
In dense mode, the Layer 3 device assumes that all routers in the Layer 3 domain configured with PIM dense-mode needs the multicast stream, consequently forwarding to all Layer 3 devices. If there are no directly connected members, the router will send a prune message to the router connected to the source.
When a new receiver on a previously pruned branch of the tree joins a multicast group, the PIM DM device detects the new receiver and immediately sends a graft message up the distribution tree toward the source. When the upstream PIM-DM device receives the graft message, it immediately places the interface on which the graft was received into the forwarding state so that the multicast traffic begins flowing to the receiver.
All of this constant communication to maintain the source trees can be burdensome on the network. For this reason, PIM dense-mode is not optimal and suitable for large-scale deployment. The next generation Cisco network devices do not have the support for PIM dense-mode. (Nexus platform does not support PIM dense mode.)
PIM Sparse-Mode
Protocol independent multicast sparse-mode (PIM-SM) is a protocol that is used to efficiently route multicast packets in the network. In multicast terminology, PIM sparse-mode is an implementation of any-source multicast (ASM). It interacts with the router’s IP routing table to determine the correct path to the source of the multicast packets (RPF). It also interacts with IGMP to recognize networks that have members of the multicast group. As the name implies, it does not depend on any particular unicast routing protocol. Based on the RFC 4601, the basic mechanism of PIM-SM can be summarized as follows:
A router receives explicit join/prune messages from those neighboring routers that have downstream group members. The router then forwards data packets addressed to a multicast group (G) only onto those interfaces on which explicit joins have been received.
A designated router (DR) sends periodic join/prune messages toward a group-specific rendezvous point (RP) for each group for which it has active members. The RP acts as the gatekeeper and meeting place for sources and receivers. In a PIM-SM network, sources must send their traffic to the RP. For this to work, the router must know where the RP is located, meaning it must know the IP address of the RP for a specific multicast group. Every group for which the router is receiving joins must have a group-to-RP mapping. To show this mapping in IOS, use the command show ip pim rp-mapping, as shown in Example 3-7.
Example 3-7 PIM RP to Group Mappings
R7#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 192.168.0.2 (?), v2v1
Info source: 192.168.0.2 (?), elected via Auto-RP
Uptime: 1d15h, expires: 00:02:53
After the traffic is sent to the RP, it is then forwarded to receivers down a shared distribution tree. By default, when the last-hop router in the tree (the router closest to the receiver) learns about the source, it verifies the best reachability path to the source from unicast routing table. If a path exists, then it will send a join message directly to the source, creating a source-based distribution tree from the source to the receiver. This source tree does not include the RP unless the RP is located within the shortest path between the source and receiver.
Each router along the path toward the RP builds a wildcard (any-source) state for the group and sends PIM join messages on towards the RP. When a data source first sends to a group, its DR (designated router, also the FHR) unicasts register messages to the RP with the source’s data packets encapsulated within. The RP sends a register stop message towards the FHR, the FHR then sends the multicast data packets towards the RP. The RP forwards the source’s multicast data packets down the RP-centered distribution tree toward group members (receivers for the multicast group). The last-hop router verifies the existence of a more optimal path to the source. This depends on the interior gateway protocol (IG) and congruent PIM relationships along the path. If such a path exists, a (S,G) join is sent, and the flow moves to the alternate path as defined by the IGP. Finally, the last-hop router sends a prune to the RP.
Figure 3-12 and the list that follows review a step-by-step approach of a tree build-up using the multicast flow in the figure.
Step 1. Receiver sends an IGMP request to the last-hop router (LHR). The LHR reviews its configuration for RP information for the requested group and sends a request in PIM control protocol towards the RP. The RP is a gatekeeper that holds all information on active multicast receivers and sources.
Note
PIM sparse-mode and this process is based on RFC 4601.
The communication between the LHR and the RP is represented as a shared tree and is referred to as a (*, G).
Step 2. The (*, G) update is used to provide the RP information of an active receiver for the multicast group.
Step 3. The source sends the multicast stream to the first-hop router (FHR).
Step 4. The FHR, configured with PIM sparse-mode and relevant RP information, encapsulates the multicast stream in a unicast packet called the register message and sends it to the RP.
Step 5. In this example, the RP already has an interested receiver that wants to join the multicast group using the (*, G) entry. Consequently, the RP sends an (S,G) PIM join towards the FHR. It also sends a register stop message directly to the FHR.
Step 6. After receiving the register stop message, the FHR sends the multicast stream to the RP as an (S,G) flow.
Step 7. Based on the interested receiver, the outgoing interface list is populated, and the (S,G) flow is sent to the LHR via the PIM-enabled interfaces aligned to the unicast routing table. From the LHR, the multicast packet flows to the receiver.
Step 8. At the LHR, the router checks its unicast routing table to reach the source.
Step 9. If the check verifies an alternate path is more optimal based on the unicast routing protocol, the (S,G) join is sent to the source from the LHR.
Step 10. The source sends the multicast flow to the LHR via the (S,G) state and is created in the multicast routing table. When the data flow has migrated to the shortest path tree (S,G), the multicast LHR sends an RP prune message towards the RP.
PIM Sparse-Dense Mode
Sparse-dense mode was developed to address the issue of distributing RP information in some dynamic RP mapping environments. For example, when using the Cisco dynamic RP mapping protocol, Auto-RP, the address of the RP is distributed using dense mode, and additional multicast streams would use the RP as a shared tree.
One of the challenges with sparse-dense mode occurs during RP failure. If the network is not configured appropriately, all the multicast traffic reverts to DM, consequently causing undue stress on the network. If the RP fails, any new sessions requiring the interaction of the RP will also fail. Using sparse-dense mode (PIM-SD) is one method to ensure delivery of multicast messages for new connections. In the event of a RP failure, the multicast mode of operation reverts to or falls back to the least common denominator, which is dense mode (PIM-DM) flooding of multicast messages.
The behavior in a PIM-DM configuration is to flood multicast messages. Routers in the multicast network without downstream clients interested in receiving the multicast traffic send a prune message. This becomes a constant flood and prune, which may overwhelm a network with many senders and/or limited bandwidth. Caution should always be used any time PIM-DM could be initiated.
Because of this additional burden of maintaining dense-mode source trees during misconfiguration or router failures, the authors do not recommend using sparse-dense mode. Additional tools and features have been developed for Cisco routers to avoid dense-mode.
For this reason, it is desirable to have high availability of RP systems. There are many ways to achieve this, depending on the PIM mode in use. For information about dynamic RP mapping and propagation, as well as RP redundancy, please refer to Chapters 4 and 5.
Multicast Flow at the Leaf
The overall multicast flow is a combination of the Layer 2 and 3 environments. IGMP is the most common mechanism to control multicast messages at Layer 2, and the PIM control plane is used to manage multicast traffic to flow from the source to the receiver at Layer 3. Let’s examine the flow of the multicast tree establishment for a sender and receiver multicast flow at the last-hop router (LHR).
To understand this, let’s look at a slightly different example network, shown in Figure 3-13. There are three routers that makeup the network, R1, R2, and R3. R3 is connected to VLAN 8, and this is where the source of the multicast stream is located. R2 is connected to VLAN 7, and this is where the client is located.
In this example, the source Sender-1 is sending a multicast stream to 224.64.7.7. Because the network is configured using PIM dense-mode, the multicast group is flooded and pruned throughout the network. Using the show ip mroute 224.64.7.7 verbose command demonstrated in Example 3-8, you can see that the ‘P’ flag has been set, indicating that the multicast route has been pruned.
Example 3-8 Verifying a Multicast Route Has Been Pruned
R2#show ip mroute 224.64.7.7 verbose
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,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.64.7.7), 00:12:38/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/0/2, Forward/Dense, 00:12:38/stopped
GigabitEthernet0/0/1, Forward/Dense, 00:12:38/stopped
(192.168.8.10, 224.64.7.7), 00:09:37/00:01:18, flags: PT
Incoming interface: GigabitEthernet0/0/1, RPF nbr 192.168.32.3
Outgoing interface list:
GigabitEthernet0/0/2, Prune/Dense, 00:00:35/00:02:24, A
When a host is interested in receiving a particular multicast stream, it sends an unsolicited membership report to the multicast group it is interested in joining. In our example, it is Receiver-1 (192.168.7.3).
Note
In this example, we have turned off IGMP snooping on the switch for VLAN 7 to better explain the effect of IGMP on the router.
The high-level steps involved for the host to begin receiving the multicast stream are as follows:
Step 1. The host (Receiver-1) sends a multicast IGMP join report to a group address, 224.64.7.7.
Step 2. The router receives the report from Receiver-1, and, using the debug ip igmp command on R2, we can see the logging message as shown here:
IGMP(0): Received v2 Report on GigabitEthernet0/0/0 from 192.168.7.3 for 224.64.7.7
Step 3. The (*,G) entry (*, 224.64.7.7) is added to the multicast routing table (MRT)—not to be confused with the maximum response timer. The entry matches packets from any source as long as the packet is received from an interface that matches the reverse path forwarding (RPF) check. In dense mode, the route is 0.0.0.0. The output is shown using the debug ip mrouting command on R2:
MRT(0): Update (*,224.64.7.7), RPF /0.0.0.0
Step 4. The router now updates the multicast routing information base (MRIB) table with the outgoing interface, this is where Receiver-1 is located and the outbound interface list (OIL) is added. The following output is generated using the debug ip mrib route command on R2.
MRIB: Table = Default, Trans: (192.168.8.10, 224.64.7.7) midb update: ADD, IDB = GigabitEthernet0/0/0, next hop = 0.0.0.0
Step 5. The multicast forwarding information base (MFIB) for IPv4 is now updated with the appropriate source address (S,G) learned from PIM dense-mode. This can be viewed using the debug ip mfib ps (Cisco IOS) command:
MFIBv4(0x0): (*,224.64.7.7) MRIB update[1]: C K (Modified: )
MFIBv4(0x0): (*,224.64.7.7) GigabitEthernet0/0/0 MRIB update: RF F NS
(Modified: RF NS)
MFIBv4(0x0): (192.168.8.10,224.64.7.7) MRIB update[1]: K DDE
(Modified: )
MFIBv4(0x0): (192.168.8.10,224.64.7.7) GigabitEthernet0/0/0 MRIB
update: RF F NS (Modified: RF NS)
Step 6. Finally, the router performs an RPF check to validate where the sender (Sender-1) is located. In this example, the interface is GigabitEthernet0/0/1. To view the following output, use the debug ip mrib route command on R2.
MRIB: Table = Default, Trans: (192.168.8.10, 224.64.7.7) mroute update:
MOD FLAGS, rpf = GigabitEthernet0/0/1, flag = C0
MRIB: Table = Default, Trans: (192.168.8.10, 224.64.7.7) igmp update
local interest, rpf = GigabitEthernet0/0/1
MRIB: Table = Default, Trans: (*, 224.64.7.7) mroute update: MOD FLAGS,
rpf = Null, flag = 84
MRIB: Table = Default, Trans modify entry: (*,224.64.7.7/32) flags:
set C , success
MRIB: Table = Default, Trans: (*, 224.64.7.7) igmp update local
interest, rpf = Null
Now that the multicast stream is being received by Receiver-1, we can verify the IGMP group membership on R2 using the show ip igmp groups command, as demonstrated in Example 3-9.
Example 3-9 Verifying IGMP Group Membership
ASR1K-2#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group
Accounted
224.64.7.7 GigabitEthernet0/0/0 00:05:47 00:02:44 192.168.7.3
We can also validate the active state for group 224.64.7.7, because the “P” flag has now been removed. This is shown using the show ip mroute command, as demonstrated in Example 3-10.
Example 3-10 Validating Active State for a Multicast Group
ASR1K-2#show ip mroute 224.64.7.7
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,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.64.7.7), 00:05:19/stopped, RP 0.0.0.0, flags: C
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/0/2, Forward/Dense, 00:05:19/stopped
GigabitEthernet0/0/1, Forward/Dense, 00:05:19/stopped
GigabitEthernet0/0/0, Forward/Dense, 00:05:19/stopped
(192.168.8.10, 224.64.7.7), 00:05:19/00:01:34, flags: T
Incoming interface: GigabitEthernet0/0/1, RPF nbr 192.168.32.3
Outgoing interface list:
GigabitEthernet0/0/0, Forward/Dense, 00:05:19/stopped
GigabitEthernet0/0/2, Prune/Dense, 00:00:39/00:02:20, A
It is important to understand the flags used in the state output given by the show ip mroute command. Here is an explanation of these flags as used in IOS:
Common flags:
D: PIM state is being processed as a dense-mode flow.
S: PIM state is being processed as a sparse-mode flow.
B: PIM state is being processed as a bidirectional flow.
SSM: PIM state is being processed as a source-specific mode flow.
T: SPT bit set, meaning the router has moved the flow to an (SPT).
C: Connected, when a group member is connected to the router.
L: Local, when a router itself is considered a member of the group.
P: Pruned, a multicast group state has been pruned by PIM but has not yet aged from the mroute table.
R: RP-bit is set, indicating that the (S,G) flow is currently pointed toward the RP.
F: Register flag appears when the source is being registered to the RP (appears on the FHR).
J: The router has processed a PIM join for the SPT state.
Leaving an IGMP Group
When using IGMPv1, there is no such thing as a leave process. When a host is no longer interested in receiving a multicast stream, it just stops processing the multicast information, but that doesn’t stop traffic from being sent! The only way a router can determine if there are valid hosts interested in the multicast stream is by sending query messages. Query messages are generally sent every 60 seconds and typically require a timeout interval of three query messages. This means that multicast traffic is being sent for an additional three minutes to an uninterested host. Yes, that is a terrible waste of bandwidth!
Example 3-11 shows a packet capture of a membership query message sent from the router to the devices on the subnet.
Example 3-11 IGMP Membership Query Message Packet Capture
Internet Protocol Version 4, Src: 192.168.7.1, Dst: 224.0.0.1
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00:
Not-ECT (Not ECN-Capable Transport))
Total Length: 28
Identification: 0x2116 (8470)
Flags: 0x00
Fragment offset: 0
Time to live: 1
Protocol: IGMP (2)
Header checksum: 0xf05f [validation disabled]
Source: 192.168.7.1
Destination: 224.0.0.1
Internet Group Management Protocol
[IGMP Version: 1]
Type: Membership Query (0x11)
Header checksum: 0xeeff [correct]
Multicast Address: 0.0.0.0 (0.0.0.0)
IGMPv2 and v3 are significantly more efficient at leaving a group. An IGMPv2 or v3 host can send a leave message to all routers on the subnet, indicating that it no longer wants to receive a multicast stream. Upon receipt of the leave message, the router stops forwarding the multicast traffic. Example 3-12 shows a packet capture of a host leave message.
Example 3-12 IGMP Host Leave Message Packet Capture
Internet Protocol Version 4, Src: 192.168.7.3 Dst: 224.0.0.2
Version: 4
Header length: 24 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT
(Not ECN-Capable Transport))
Total Length: 32
Identification: 0x6d72 (28018)
Flags: 0x00
Fragment offset: 0
Time to live: 1
Protocol: IGMP (2)
Header checksum: 0x0fb8 [validation disabled]
Source: 192.168.7.3
Destination: 224.0.0.2
Options: (4 bytes), Router Alert
Internet Group Management Protocol
[IGMP Version: 2]
Type: Leave Group (0x17)
Max Response Time: 0.0 sec (0x00)
Header checksum: 0x01b8 [correct]
Multicast Address: 224.64.7.7
The Rendezvous Point and Shared Tree Dynamics
Let’s take a much closer look at sparse-mode operations and the significance of the rendezvous point. In sparse mode, the RP of a network is always a router. The RP router is not a packet source but simply a location from which to root and calculate a loop-free topology. The RP can also offload the processing of network joins and leaves during the initial setup of a multicast stream, saving network resources by concentrating them in a single location. In the example network shown in Figure 3-14, the clients notify last-hop routers (LHR) (R6 and R7) via IGMP of the intention to join a group. The LHR routers forward PIM join messages toward the RP, establishing the (*,G) state and the LHR as leaves in the shared tree.
Each router in the path between the RP and the LHR (which hosts receivers) follows the same procedure, recording the incoming interface of the join message. The router RPF checks each join against the location of the RP and adds the joined interface to the OIL. The incoming interface, of course, will be the multicast-enabled interface with the shortest path to the RP. The join messages stop at the RP for the shared tree, or if the receiving router already has an (S,G) entry for the group in the (*,G) join message. Using the show ip mroute command, you can view the conditions of both the (S,G) and (*,G) entries, as demonstrated in Example 3-13.
Example 3-13 Displaying the (S,G) and (*,G) Entry Condition
R4#show ip mroute 239.2.2.2
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
(*, 239.2.2.2), 00:00:16/stopped, RP 172.16.1.1, flags: SPF
Incoming interface: Ethernet1/0, RPF nbr 10.1.3.1
Outgoing interface list: Null
(10.11.11.11, 239.2.2.2), 00:00:16/00:02:43, flags: FT
Incoming interface: Loopback0, RPF nbr 0.0.0.0, Registering
Outgoing interface list:
Ethernet1/0, Forward/Sparse, 00:00:16/00:03:13
At this point in the process, a shared tree has been constructed from the RP to the gateway routers (LHRs) in the path. For the example network in Figure 3-14, the shared tree flows from the root at the RP to R7. R3 would already have an (S,G) and would therefore share the SPT with R6, and after it receives packets from a multicast source destined to the group, it begins replicating and forwarding packets to R6. Remember, the shared tree is represented by the (*,G) entries of the routers in the path and at the RP.
When a source begins sending packets to the multicast flow, the DR interface on the FHR (R3, or the router closest to the source) needs to notify the RP that a stream needs forwarding and a source tree needs to be built. It does this by sending a PIM source register message to the RP. The RP needs this information in order to join the source tree at the source. The RP is now joined to the SPT, and packets can be forwarded to the RP, the root of the shared tree for further replication and forwarding. Figure 3-15 depicts this process.
There is a small gap in this explanation: How then are packets forwarded from the source to the shared tree before the RP has joined the SPT? If the multicast source (server) still sends the first multicast packets toward its gateway router (in this case R3, the FHR) and R3 forwards the packets toward the RP, a serious problem could occur. For example, if the packet is forwarded through R1, but R1 did not get a PIM message yet and will therefore not have a (*,G) or (S,G) entry in its mroute table, it would drop the packet! Sending the multicast packet toward the RP through normal multicast forwarding will not work until the RP is joined to the SPT.
To resolve this problem, the router closest to the source must encapsulate the multicast packet inside of a unicast packet with the IP address of the rendezvous point as the IP destination. In other words, the multicast stream must be tunneled from the router at the source to the RP.
When configuring multicast on a router, you may have noticed the following message:
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
This appears when the router learns about the RP and creates the tunnel interface. Upon further inspection using the show interfaces tunnel 0 command, you see the destination of the tunnel is the RP 192.168.0.2 and sourced from a local interface, as demonstrated in Example 3-14.
Example 3-14 show interfaces tunnel 0 Command Output
R3#show interfaces tunnel 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Description: Pim Register Tunnel (Encap) for RP 192.168.0.2
Interface is unnumbered. Using address of Ethernet0/2 (192.168.31.3)
MTU 17912 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 192.168.31.3 (Ethernet0/2), destination 192.168.0.2
Tunnel Subblocks:
src-track:
Tunnel0 source tracking subblock associated with Ethernet0/2
Set of tunnels with source Ethernet0/2, 1 member (includes iterators),
on interface <OK>
Tunnel protocol/transport PIM/IPv4
Tunnel TOS/Traffic Class 0xC0, Tunnel TTL 255
Tunnel transport MTU 1472 bytes
Tunnel is transmit only
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Last input never, output 00:17:06, output hang never
Last clearing of "show interface" counters 00:21:34
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
4 packets output, 1216 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
Another item of interest is the number of output packets. This indicates multicast packets that were tunneled to the RP.
The tunnel is known as the Encap Tunnel. To make the encapsulation process more efficient, the outer unicast header that is added to the multicast is actually the PIMv2 register message that is sent to the router. In this way, the multicast and the PIM register arrive at the RP at the same time. The RP strips the PIM register encapsulation from the multicast packets and forwards the packets to any receivers using the shared tree state(s). Figure 3-16 depicts the tunneling, replication, and subsequent forwarding of the multicast stream with packet capture output from the links between R1, the RP, and R5.
This process of encapsulating packets in the tunnel is only temporary. When there is a source tree (S,G) established between the FHR and the RP, the RP actually begins to receive two copies of each multicast packet, one from the now native source tree, and one inside the unicast encapsulation. This is obviously not the ideal state for the traffic to be in. When this condition occurs, the RP sends a register stop message via PIM to the FHR encapsulating the flow. This tells the FHR, in this case R3, to use only the native source tree to the RP to forward packets. The register stop message conditions are as follows:
When the RP has receivers in its multicast entry table (*,G) for the new multicast group, the RP sends an (S,G) join message towards the FHR and then sends a register stop message directly to the FHR.
When the RP has no receivers, it discards the multicast group register message and sends a register stop message towards the FHR. Each FHR maintains a register suppression timer that is initiated by the register stop message. Upon expiration of this timer, the FHR again sends a register packet to the RP to verify whether there are any active receivers for that group, provided the multicast source is also still active.
The register stop message with packet capture is shown in Figure 3-17. This tells the FHR, in this case R3, to use the native source tree to the RP to forward packets.
It may also be of value to examine the encapsulation and register stop process described in Figures 3-16 and 3-17 through a sniffer trace of the packets traveling to and from the RP. Table 3-2 shows a packet capture on the link between R1 and R2, whereas Table 3-3 shows the multicast packets being passed down the shared tree on the link between R2 and R5. In this capture, the IP address of the source is 192.168.8.8, the RP is address 192.168.0.2, and the tunnel source interface on R3 is 192.168.31.3, as shown in Figure 3-16.
The packet trace in these tables shows the flow, explained here by packet sequence number:
1. R3 packages the first packet (Seq. 1 on both traces) in the flow into the PIM register message and forwards it to the RP through the tunnel. The RP unpacks the inner multicast packet and forwards it down the shared tree to R5.
2. After the first packet is received, the RP sends a PIM join toward the FHR (R3). Because this packet is a PIM join, it is sent by the PIM interface closest to R1 with IP address 192.168.21.2 to the all-routers local multicast group 224.0.0.13.
3. The encapsulation process continues until the RP receives a native multicast packet from the source to that group, and the RP continues to forward the multicast packets toward R5.
4. The RP receives the native multicast packet via the newly formed source tree from the FHR to the RP. This packet is also forwarded down the shared tree. Any future copies received in the Encap Tunnel are squelched.
5. The RP sends a register-stop message to the FHR, indicating that the (S,G) to the RP is functional. The FHR no longer uses the encap tunnel for this multicast group.
From a Shared Tree to a Source Tree
When is a shared tree used and when is a source tree used? As shown in the previous section, multicast flows in a PIM sparse-mode network actually use both types of trees. The initial flow follows the source tree toward the RP and a shared tree from the RP to the receiver. Even though this forwarding arrangement completes the flow, that’s not the end of the process. Sending all traffic through the RP is probably not optimal, especially if the RP is not in the preferred data path from the source to the receivers, as is the case in the example network shown in Figure 3-16.
Don’t forget the larger purpose of multicast: to gain more efficiency in the way packets are forwarded from the source to receivers. The shared-tree forwarding process is designed to create an efficient loop-free forwarding tree that conserves router memory and other control-plane resources across the network. To achieve the larger purpose of multicast, however, the network needs to further optimize the path(s) used for forwarding. To do this, routers only send packets through the shared tree until the network can properly calculate a source tree from the FHR to all receivers, eventually bypassing the RP altogether. The ideal state for all multicast flows in a sparse-mode network is an SPT that takes the most direct path(s) between sources and receivers.
Note
If a shared tree was always used as the distribution point for all traffic, this could create a significant amount of traffic through the RP and will likely introduce suboptimal traffic flows, depending on the placement of the RP in the network. It is the default behavior of Cisco routers to honor the forwarding paradigm of moving packets from the shared tree to the source tree as described above. When this occurs, the SPT bit is marked in PIM messages for this group, and the T flag appears in the router’s state entry, as shown earlier in the flag explanation for Example 3-9. However, there may be instances where this is less desirable and is therefore a configurable parameter. This parameter is known as the spt-threshold, and it is calculated in terms of bandwidth consumed (kbps) by the flow. The default setting on all Cisco routers is a threshold of 0 kbps, meaning that the router will always transition traffic to an SPT. If there is a reason that warrants delaying or preventing a stream from switching to an SPT, such as, for example, conserving memory resources on routers in the SPT path, then the ip pim spt-threshold {kbps | infinity} [group-list access-list] command in IOS can be used. The infinity command option can be used to permanently prevent STP switchover from occurring. When this command option is used, forwarding is completed only through the shared tree (*,G). In modern networks, memory for SPT calculations is rarely an issue, but it does exist for those circumstances that warrant it.
Let’s look closer at the tree transition using our network from the diagram in Figure 3-18, which includes IP addressing. In the following list we detail the flow of communication, as described earlier, step-by-step, including router debug output. In this example, a multicast source (multicast server) for group 239.1.1.1 connected to R3 is using the IP address of 192.168.8.8. A receiver for 239.1.1.1 is connected to R7 and is using the IP address of 192.168.10.10.
1. Source sends to FHR with no receivers: When the source begins to send multicast information, R3 registers the entry and informs the RP of the stream. This is seen on the RP (R2) using the debug ip pim command:
Note
R3 is using the IP address of 192.168.31.3.
PIM(0): Received v2 Register on Ethernet0/2 from 192.168.31.3 for 192.168.8.8,
group 239.1.1.1
PIM(0): Check RP 192.168.0.2 into the (*, 239.1.1.1) entry
PIM(0): Adding register decap tunnel (Tunnel1) as accepting interface of
(*, 239.1.1.1).
PIM(0): Adding register decap tunnel (Tunnel1) as accepting interface of
(192.168.8.8, 239.1.1.1).
Another item of interest is that the RP responds back to R3 from two interfaces because there is an equal cost path.
At this stage in building the tree, the only routers that have any awareness of the stream are R3, the router directly upstream from the source, and the RP.
The source is sending a multicast stream, but it does not have any receivers, as verified in the output from the show ip mroute 239.1.1.1 command demonstrated here:
R3#show ip mroute 239.1.1.1
… partial output shown for brevity …
(*, 239.1.1.1), 00:00:14/stopped, RP 192.168.0.2, flags: SPF
Incoming interface: Ethernet0/2, RPF nbr 192.168.31.1
Outgoing interface list: Null
(192.168.8.8, 239.1.1.1), 00:00:14/00:02:45, flags: PFT
Incoming interface: Ethernet0/3, RPF nbr 0.0.0.0
Outgoing interface list: Null
The OIL is Null, which means that nothing is being sent.
Note
Recall the register stop conditions: If there are no established receivers for a group state, the RP will eventually start sending register stop messages to the FHR. This is the state shown in the show ip mroute 239.1.1.1 output, and this is why the OIL is Null. Sending the register stop prevents unnecessary forwarding of any packets when there is no shared tree established for the flow until such time as there are both known receivers and an active source. The RP discontinues the register stop messages and allows the registration process to begin anew after it receives a (*,G) PIM join messages for that group.
From the show ip mroute 239.1.1.1 output, you see the shared tree (*, 239.1.1.1) and the source tree (192.168.8.8, 239.1.1.1).
R7 currently does not have any knowledge of 239.1.1.1, as seen using the show ip mroute 239.1.1.1 command demonstrated here:
R7#show ip mroute 239.1.1.1
Group 239.1.1.1 not found
When the host connected to R7 desires to join the multicast stream sourced of 239.1.1.1, a series of events takes place, as follows (note that the multicast source is already active and the FHR starts the registry process):
2. Receivers join at the LHR: R7 receives the IGMP join message (membership report) from the attached client and adds it to the IGMP group table, as seen from the show ip igmp groups command:
R7#show ip igmp groups 239.1.1.1
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
Group Accounted
239.1.1.1 Ethernet0/1 00:00:02 00:02:57 192.168.10.10
3. LHR establishes the shared tree toward the RP: R7 establishes the (*,G) and sends a join message to the upstream neighbor (R5), as seen from the following debug messages using the command debug ip pim:
PIM(0): Check RP 192.168.0.2 into the (*, 239.1.1.1) entry
PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for
239.1.1.1
PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for
239.1.1.1
PIM(0): Upstream mode for (*, 239.1.1.1) changed from 0 to 1
PIM(0): Insert (*,239.1.1.1) join in nbr 192.168.75.5's queue
PIM(0): Building Join/Prune packet for nbr 192.168.75.5
PIM(0): Adding v2 (192.168.0.2/32, 239.1.1.1), WC-bit, RPT-bit, S-bit Join
PIM(0): Send v2 join/prune to 192.168.75.5 (Ethernet0/0)
PIM(0): Insert (192.168.8.8,239.1.1.1) join in nbr 192.168.75.5's queue
PIM(0): Building Join/Prune packet for nbr 192.168.75.5
PIM(0): Adding v2 (192.168.8.8/32, 239.1.1.1), S-bit Join
PIM(0): Send v2 join/prune to 192.168.75.5 (Ethernet0/0)
PIM(0): Received RP-Reachable on Ethernet0/0 from 192.168.0.2
PIM(0): Received RP-Reachable on Ethernet0/0 from 192.168.0.2 for group
239.1.1.1
PIM(0): Update RP expiration timer (270 sec) for 239.1.1.1
PIM(0): Insert (192.168.8.8,239.1.1.1) join in nbr 192.168.75.5's queue
PIM(0): Building Join/Prune packet for nbr 192.168.75.5
PIM(0): Adding v2 (192.168.8.8/32, 239.1.1.1), S-bit Join
PIM(0): Send v2 join/prune to 192.168.75.5 (Ethernet0/0)
PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for
239.1.1.1
PIM(0): Insert (*,239.1.1.1) join in nbr 192.168.75.5's queue
PIM(0): Building Join/Prune packet for nbr 192.168.75.5
PIM(0): Adding v2 (192.168.0.2/32, 239.1.1.1), WC-bit, RPT-bit, S-bit Join
PIM(0): Send v2 join/prune to 192.168.75.5 (Ethernet0/0)
4. RP builds the (*,G) state and receiver entry: Upon receiving the join message generated from R7, the RP (R2) builds the (*, G) state, as shown in the following debug ip pim message:
PIM(0): Received v2 Join/Prune on Ethernet0/0 from 192.168.52.5, to us
PIM(0): Join-list: (*, 239.1.1.1), RPT-bit set, WC-bit set, S-bit set
PIM(0): Add Ethernet0/0/192.168.52.5 to (*, 239.1.1.1), Forward state, by PIM
*G Join
PIM(0): Add Ethernet0/0/192.168.52.5 to (192.168.8.8, 239.1.1.1), Forward
state, by PIM *G Join
5. FHR registers the active source: The RP already received a register packet from the FHR because it has the (*,G) state with receiver information. The RP sends a (S,G) join message to 224.0.0.13 towards the FHR and then sends a register stop message directly to the FHR. The output from the RP is shown using the following debug ip pim message:
*May 11 21:36:48.311: PIM(0): Received v2 Register on Ethernet0/2 from
192.168.43.3
*May 11 21:36:48.311: for 192.168.8.8, group 239.1.1.1
*May 11 21:36:48.311: PIM(0): Adding register decap tunnel (Tunnel1) as
accepting interface of (192.168.8.8, 239.1.1.1).
*May 11 21:36:48.311: PIM(0): Insert (192.168.8.8,239.1.1.1) join in nbr
192.168.42.4's queue
*May 11 21:36:48.311: PIM(0): Building Join/Prune packet for nbr 192.168.42.4
*May 11 21:36:48.311: PIM(0): Adding v2 (192.168.8.8/32, 239.1.1.1), S-bit
Join
*May 11 21:36:48.311: PIM(0): Send v2 join/prune to 192.168.42.4 (Ethernet0/1)
*May 11 21:36:48.310: PIM(0): Check RP 192.168.0.2 into the (*, 239.1.1.1)
entry
*May 11 21:36:48.310: PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit)
Prune message for 239.1.1.1
*May 11 21:36:48.310: PIM(0): Adding register encap tunnel (Tunnel0) as for-
warding interface of (192.168.8.8, 239.1.1.1).
*May 11 21:36:48.313: PIM(0): Received v2 Join/Prune on Ethernet0/1 from
192.168.43.4, to us
*May 11 21:36:48.313: PIM(0): Join-list: (192.168.8.8/32, 239.1.1.1), S-bit
set
*May 11 21:36:48.313: PIM(0): Add Ethernet0/1/192.168.43.4 to (192.168.8.8,
239.1.1.1), Forward state, by PIM SG Join
At the FHR, the output of the debug ip pim message at this step is as follows:
*May 11 21:45:11.152: PIM(0): Check RP 192.168.0.2 into the (*, 239.1.1.1)
entry
*May 11 21:45:11.152: PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit)
Prune message for 239.1.1.1
*May 11 21:45:11.152: PIM(0): Adding register encap tunnel (Tunnel0) as
forwarding interface of (192.168.8.8, 239.1.1.1).
*May 11 21:45:11.155: PIM(0): Received v2 Join/Prune on Ethernet0/1 from
192.168.43.4, to us
*May 11 21:45:11.155: PIM(0): Join-list: (192.168.8.8/32, 239.1.1.1), S-bit
set
*May 11 21:45:11.155: PIM(0): Add Ethernet0/1/192.168.43.4 to (192.168.8.8,
239.1.1.1), Forward state, by PIM SG Join
R3#
*May 11 21:45:15.133: PIM(0): Received v2 Register-Stop on Ethernet0/1 from
192.168.0.2
*May 11 21:45:15.133: PIM(0): for source 192.168.8.8, group 239.1.1.1
*May 11 21:45:15.133: PIM(0): Removing register encap tunnel (Tunnel0) as
forwarding interface of (192.168.8.8, 239.1.1.1).
*May 11 21:45:15.133: PIM(0): Clear Registering flag to 192.168.0.2 for
(192.168.8.8/32, 239.1.1.1)
R3 receives the register stop and the (S,G) join from the RP. Now the FHR (R3) sends the multicast traffic towards the RP in a unicast tunnel. The flow of the multicast stream now progresses from the RP down to R7 and ultimately towards the receiver. This is the initial tree build up in PIM sparse-mode. For details on the SPT switch, refer to the earlier section, “The Rendezvous Point and Shared Tree Dynamics.”
6. The multicast flow moves from the shared tree to a source tree: R3 received the prune message from the RP and added the interface Ethernet0/1 to the OIL, as shown from the following debug ip pim message, creating a source tree from the FHR to the LHR:
PIM(0): Received v2 Join/Prune on Ethernet0/1 from 192.168.43.4, to us
PIM(0): Join-list: (192.168.8.8/32, 239.1.1.1), S-bit set
PIM(0): Add Ethernet0/1/192.168.43.4 to (192.168.8.8, 239.1.1.1), Forward
state, by PIM SG Join
R5 sees the source tree formed from the FHR (R3) and uses the RPF in the unicast routing table to find a better metric. When this occurs, R5 sends a PIM prune toward the RP to remove itself from the shared tree, as shown from the debug ip pim output from R5 below.
PIM(0): Received v2 Join/Prune on Ethernet0/0 from 192.168.75.7, to us
PIM(0): Join-list: (*, 239.1.1.1), RPT-bit set, WC-bit set, S-bit set
PIM(0): Add Ethernet0/0/192.168.75.7 to (*, 239.1.1.1), Forward state, by PIM
*G Join
PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for
239.1.1.1
PIM(0): Upstream mode for (*, 239.1.1.1) changed from 0 to 1
PIM(0): Insert (*,239.1.1.1) join in nbr 192.168.52.2's queue
PIM(0): Insert (192.168.8.8,239.1.1.1) sgr prune in nbr 192.168.52.2's queue
PIM(0): Update Ethernet0/0/192.168.75.7 to (192.168.8.8, 239.1.1.1), Forward
state, by PIM *G Join
PIM(0): Building Join/Prune packet for nbr 192.168.52.2
PIM(0): Adding v2 (192.168.0.2/32, 239.1.1.1), WC-bit, RPT-bit, S-bit Join
PIM(0): Adding v2 (192.168.8.8/32, 239.1.1.1), RPT-bit, S-bit Prune
PIM(0): Send v2 join/prune to 192.168.52.2 (Ethernet0/2)
Figure 3-19 shows the traffic flow for the new source tree.
7. The new source tree is fully activated: The source tree is now active, as seen using the show ip mroute 239.1.1.1 command on R3:
R3#show ip mroute 239.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
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 00:00:22/stopped, RP 192.168.0.2, flags: SPF
Incoming interface: Ethernet0/1, RPF nbr 192.168.43.4
Outgoing interface list: Null
(192.168.8.8, 239.1.1.1), 00:00:22/00:03:07, flags: FT
Incoming interface: Ethernet0/3, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse, 00:00:22/00:03:07
The shared tree has not been removed. When another receiver connected to a different router is interested in the multicast stream, the shared tree and the same process of moving from a shared tree to a source tree will occur again, like déjà vu all over again.
Note
While there is much going on under the hood in this section, the process of switching between the shared tree and the source tree is relatively quick (less than a second in a robust network). This is exactly what we want! If a sparse-mode network has trees stuck in the shared tree state, eating up RP router resources, this indicates that a group has no source(s), or that something has likely gone wrong in the PIM process. In fact, this is a common symptom that occurs in a network in which PIM communication has broken down. For information on how to find and fix such failures, please see Chapter 7, which covers PIM troubleshooting.
Building the Multicast Routing Information Base
The unicast routing information base (RIB) has been populated by unicast routing protocols. It is not necessary to build another multicast routing table with identical or additional route information that consumes additional memory. As discussed earlier with RPF checks, rather than forward packets to the source, multicast routers forward packets away from the source.
When a router receives a multicast packet, it performs the following actions.
1. Upon receipt of a multicast packet, the router checks the receiving interface to determine whether it is in the path to the source (sending IP address) by performing a lookup in the RIB. This is known as the RPF check.
2. If the interface is in the path to the source, the packet is forwarded.
3. If the receiving interface is not in the path to the source, the RPF fails and the packet is dropped.
Multicast takes a unique perspective when it comes to forwarding traffic in the network. Rather than looking for the destination address of where to send the information as with traditional routing, multicast routing does just the opposite. Because multicast routing is the opposite of unicast or traditional routing, you can take advantage of the RIB.
The RIB is a collection of all routing information contained on a router and is a culmination of connected routes, static routes, and routes learned from dynamic routing protocols. It also holds adjacency information for neighboring routers. The RIB is used to populate the forwarding information base (FIB) with the best path to a particular destination. The FIB table is used to forward packets to the appropriate destination.
Multicast Routing Information Base and Multicast Forwarding Information Base
In the earlier section “Two Types of Trees,” we addressed a couple of items that need some further clarification. These are the multicast routing information base (MRIB) and multicast forwarding information base (MFIB) and the way they interact with the other functions of the router.
The MRIB table is a collection of multicast entries, including source, group, group mask, and flags, and may also contain a list of associated interfaces. The entries in the MRIB are created/updated by the control plane when traffic is received from a connected source, a switchover occurs, or there is some other data-driven event. The MRIB table (for non-local multicast groups) can be viewed on older IOS platforms simply by using the show ip mroute command as it has been discussed. Newer versions of IOS, including IOS XE, can display the MRIB table using the show ip mrib route command, as demonstrated in Example 3-15.
Example 3-15 Displaying the MRIB Table
ASR1K-2#show ip mrib route
IP Multicast Routing Information Base
Entry flags: L - Domain-Local Source, E - External Source to the Domain,
C - Directly-Connected Check, S - Signal, IA - Inherit Accept, D - Drop
ET - Data Rate Exceeds Threshold,K - Keepalive,DDE - Data Driven Event
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,
LD - Local Disinterest, MD - mCAC Denied
(*,224.64.7.7) RPF nbr: 0.0.0.0 Flags: C
GigabitEthernet0/0/2 Flags: F NS
GigabitEthernet0/0/1 Flags: F NS
GigabitEthernet0/0/0 Flags: F NS
(192.168.8.10,224.64.7.7) RPF nbr: 192.168.32.3 Flags:
GigabitEthernet0/0/1 Flags: A
GigabitEthernet0/0/0 Flags: F NS
The MFIB is the multicast forwarding information derived from the MRIB and is presented as a unique table, which displays how the router intends to forward multicast messages. Information such as source, group, mask, counts, and rates of received, dropped, and forwarded packets are contained in this table. Example 3-16 shows an abbreviated output from the show ip mfib command.
ASR1K-2#show ip mfib
Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag,
ET - Data Rate Exceeds Threshold, K - Keepalive
DDE - Data Driven Event, HW - Hardware Installed
I/O Item Flags: IC - Internal Copy, NP - Not platform switched,
NS - Negate Signaling, SP - Signal Present,
A - Accept, F - Forward, RA - MRIB Accept, RF - MRIB Forward,
MA - MFIB Accept
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts: Total/RPF failed/Other drops
I/O Item Counts: FS Pkt Count/PS Pkt Count
Default
(*,224.64.7.7) Flags: C HW
SW Forwarding: 0/0/0/0, Other: 0/0/0
HW Forwarding: 0/0/0/0, Other: 0/0/0
GigabitEthernet0/0/0 Flags: F NS
Pkts: 0/0
GigabitEthernet0/0/1 Flags: F NS
Pkts: 0/0
GigabitEthernet0/0/2 Flags: F NS
Pkts: 0/0
(192.168.8.10,224.64.7.7) Flags: HW
SW Forwarding: 0/0/0/0, Other: 15/2/13
HW Forwarding: 685830/156/1369/1673, Other: 1111/1111/0
GigabitEthernet0/0/1 Flags: A
GigabitEthernet0/0/0 Flags: F NS
Pkts: 0/0
Figure 3-20 depicts the interaction between the various components involved in the derivation of multicast forwarding information.
PIM-BiDir
RFC 5015 defines PIM-BiDir, which is a variant of protocol independent multicast (PIM). The traffic in PIM-BiDir is rooted at the rendezvous point (RP) for the group and the IP address of the RP acts as the key to having all routers establish a loop-free tree topology. Explicit join messages signal membership to the bidirectional group. Traffic from sources is unconditionally sent up the shared tree toward the RP and passed down the tree toward the receivers on each branch of the tree. This unconditional forwarding of multicast traffic towards the RP using a prebuilt tree is one of the major differences between PIM-BiDir and sparse-mode. The state is based on the prebuilt tree towards the RP in the PIM domain. Therefore, the PIM-BiDir mode only supports a (*,G) group state. (S,G) state is not seen in the mroute tables when using PIM-BiDir. Eliminating (S,G) state allows the PIM domain to scale to an extensive number of sources. The pre-built tree used in PIM-BiDir enables it to be used for many-to-many applications within individual PIM domains. Multicast groups in bidirectional mode can scale to an arbitrary number of sources without incurring overhead due to the number of sources.
PIM-BiDir is derived from the mechanisms of PIM sparse-mode (PIM-SM) and shares many shortest path tree (SPT) operations. BiDir also uses unconditional forwarding of source traffic toward the RP upstream on the shared tree, through the prebuilt state information; however, there is no registration process for sources as in PIM-SM. This means the RP is used as a root point for the tree, but not used as a tree transitioning platform, taking the tree management load off the RP altogether. Figure 3-21 shows the simple forwarding of multicast traffic using a PIM-BiDir tree.
As you’ll notice in Figure 3-21, the multicast stream forwarding to the downstream receiver is similar to PIM sparse-mode. The only difference between PIM-BiDir and PIM sparse-mode is the upstream communication and multicast stream flow to the RP. The reason the upstream flow is different is because PIM sparse-mode requires an RPF check to pass through to avoid looping of multicast data stream. The packet forwarding rules have been enhanced in PIM-BiDir over PIM-SM, allowing the traffic to be forwarded directly to the RP. The multicast looping protection in PIM-BiDir is provided by a designated forwarder (DF), which establishes a loop-free SPT rooted at the RP. With PIM-BiDir, the RP address does not need to belong to the physical box; instead, it can be simply a routable address. This is covered in more detail in Chapter 4. The concept of the RPF interface is important to understand with non-receiver segments, because the RPF interface is used in the (*,G) to point towards the RP.
In a PIM-BiDir network, every segment (including point-to-point) elects a designated forwarder (DF). The DF is elected based on the RP for a group. In a scenario of multiple RPs for different groups, you will have multiple DFs. The DF router is responsible for creating a preexisting state that is used in forwarding multicast packets towards the RP.
On every network segment and point-to-point link, all PIM routers participate in a procedure called DF election. The procedure selects one router as the DF for every RP in bidirectional multicast groups. This router is responsible for forwarding multicast packets received on that network “upstream” to the RP. The DF election process is based on unicast metrics and uses highest IP address in the case of a tie with the unicast metric. The DF forwards only one copy of the multicast flow upstream. It should be noted that for every RP assigned to a separate multicast group, a new DF is elected. A DF in PIM-BiDir takes the role of DR in PIM sparse-mode for first-hop router.
The conditions under which an update to the election process that creates state changes are:
Unicast routing table changes to reach the RP
Local interface changes the RPF
A new PIM router is seen in the topology
Neighbor failure that prompts a reelection
Figure 3-22 and the list that follows review the two-step process of building state for PIM-BiDir.
Step 1. Receiver joins the R4, which can be seen using the commands debug ip pim and show ip mroute.
7: IGMP(0): MRT Add/Update Loopback0 for (*,239.1.1.1) by 4
*Nov 21 23:29:50.457: IGMP(0): MRT Add/Update Loopback0 for
(*,239.1.1.1) by 4
*Nov 21 23:29:50.457: IGMP(0): Send v2 Report for 239.1.1.1 on
Loopback0
*Nov 21 23:29:50.457: IGMP(0): Received v2 Report on Loopback0 from
10.11.11.11 for 239.1.1.1
*Nov 21 23:29:50.457: IGMP(0): Received Group record for group
239.1.1.1, mode 2 from 10.11.11.11 for 0 sources
*Nov 21 23:29:50.457: IGMP(0): Updating EXCLUDE group timer for
239.1.1.1
*Nov 21 23:29:50.457: IGMP(0): MRT Add/Update Loopback0 for
(*,239.1.1.1) by 0
*Nov 21 23:29:50.457: IGMP(0): MRT Add/Update Loopback0 for
(*,224.0.1.40) by 4
*Nov 21 23:29:50.457: IGMP(0): Send v2 Report for 224.0.1.40 on
Loopback0
*Nov 21 23:29:50.457: IGMP(0): Received v2 Report on Loopback0 from
10.11.11.11 for 224.0.1.40
*Nov 21 23:29:50.457: IGMP(0): Received Group record for group
224.0.1.40, mode 2 from 10.11.11.11 for 0 sources
R4#show ip mroute 239.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
(*, 239.1.1.1), 00:06:11/00:02:19, RP 10.99.99.99, flags: BCL
Bidir-Upstream: Ethernet1/0, RPF nbr 10.1.3.1
Outgoing interface list:
Loopback0, Forward/Sparse, 00:06:11/00:02:19
Ethernet1/0, Bidir-Upstream/Sparse, 00:06:11/stopped
The status at R2 is shown using the show ip mroute command.
R2#show ip mroute 239.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
(*, 239.1.1.1), 00:10:38/00:03:23, RP 10.99.99.99, flags: B
Bidir-Upstream: Ethernet1/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:10:38/00:03:23
Ethernet1/0, Bidir-Upstream/Sparse, 00:10:38/stopped
As you can see from this output, the state is built using the DF. The receiver sends the notification upstream without registry (due to the prebuilt DF information) towards the RP. All the downstream routers—in this topology, R2 and R4—have the state information for 239.1.1.1 learned via PIM-BiDir. Also notice that the upstream interface Ethernet1/0 uses PIM-BiDir in the state table. The downstream interface is Ethernet0/0 and uses PIM sparse-mode forwarding, as shown using the show ip pim interface df command. The RP configuration needs to be done on each router. In Chapter 4, you learn about various RP configurations for each PIM mode.
R2# show ip pim interface df
* implies this system is the DF
Interface RP DF Winner Metric
Uptime
Ethernet0/0 10.99.99.99 *10.1.3.1 11
00:17:13
Ethernet1/0 10.99.99.99 0.0.0.0 11
00:00:00
Step 2. The source joins at R3 and the state at R3 is shown using the show ip mroute command:
R3#show ip mroute
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.0.0.0/4), 00:19:20/-, RP 10.99.99.99, flags: B
Bidir-Upstream: Ethernet1/0, RPF nbr: 10.1.1.1
Incoming interface list:
Ethernet0/0, Accepting/Sparse
Loopback0, Accepting/Sparse
Ethernet1/0, Accepting/Sparse
(*, 224.0.1.40), 00:20:15/00:02:53, RP 10.99.99.99, flags: BCL
Bidir-Upstream: Ethernet1/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:19:19/00:02:53
Loopback0, Forward/Sparse, 00:19:19/00:02:53
Ethernet1/0, Bidir-Upstream/Sparse, 00:19:20/stopped
R3 will unconditionally forward multicast traffic toward the RP upstream using the shared tree. There is no registering process for sources as in PIM-SM, the traffic is forwarded based on (*,G) attributes between the source and receiver(s).
PIM-SSM
Source-specific multicast (SSM) is another flavor of PIM sparse-mode defined in RFC 3569. The multicast stream is transmitted using an IP source and multicast address of a group. These two attributes are the primary components necessary for the transportation of the multicast messages. This protocol provides a host application with complete identification of a channel. Because this includes a combination of the source IP address and the address of the group, there can be only one multicast stream (without duplicate IP addresses in the network). Using SSM, you can have one source and many multicast applications. The receiver must subscribe to the channel using IGMPv3. IGMPv3 provides the designated router with the source IP address and the multicast group address. This set of addresses in IGMPv3 identifies the channel. The designated router connected to the receiver segment already has the IP address of the source, and thereby the streams can directly be received from the source. This mode of PIM does not require the use of an RP because the receiver is able to receive the group from a specified source. In SSM and IGMPv3, there are no shared trees; consequently, the router does not need to maintain (*,G) state. The multicast state only builds using SPTs (shortest path trees) towards our sources.
Source-specific multicast (SSM) provides the capability to identify a set of multicast hosts not only by group address but also by source. An SSM group, called a channel, is identified as an (S,G) where S is the source address and G is the group address. An example for a channel is as follows:
Channel A (S,G) = (10.0.0.1, 232.1.1.1)
Channel B (S,G) = (10.0.0.2, 232.1.1.1)
Even though Channel A and B are represented using the same multicast group, 232.1.1.1, the receiver can access a separate flow for Channel A because the identification of multicast stream is based on the channel (the unicast address of the source and the multicast group address).
Chapter 1 covered the SSM addressing scheme. For this IANA has reserved the IPv4 address range of 232.0.0.0/8, and it is recommended to allocate SSM multicast groups using that range. PIM-SSM requires that the successful establishment of an (S,G) forwarding path from the source S to any receiver(s) depends on hop-by-hop forwarding of the explicit join request from the receiver toward the source. The receivers send an explicit join to the source because they have the source IP address in their join message with the multicast address of the group. PIM-SSM leverages the unicast routing topology to maintain the loop-free behavior. Traffic for one (S, G) channel consists of datagrams with an IP unicast source address S and the multicast group address G as the IP destination address. Systems receive this traffic by becoming members of the (S, G) channel. The receivers can receive traffic only from designated (S, G) channels to which they are subscribed, which is in contrast to ASM, where receivers need not know the IP addresses of sources from which they receive their traffic.
IGMPv3 is a requirement for both the host and the next-hop device (router). If this support is not available, then the option for host-to-network device communication at Layer 2 can be IGMP v3lite and URL Rendezvous Directory (URD). These are two Cisco-developed transition solutions that were designed to enable the immediate deployment of SSM services without the need to wait for the availability of full IGMPv3 support on host operating systems. (Today, most host operating systems include support for IGMPv3.) URD is a solution for content providers and content aggregators that allows them to deploy receiver applications that are not yet SSM enabled (through support for IGMPv3). IGMPv3, IGMPv3lite, and URD interoperate with each other, and can be used as transitional solutions toward full IGMPv3 support for hosts.
IGMP and INCLUDE mode membership reports are used for channel subscription signaling with IGMPv3. The INCLUDE can be statically created with IGMPv3lite or URD. The INCLUDE and EXCLUDE mode of membership adds additional security not available in other PIM modes.
Note
The INCLUDE and EXCLUDE mode are additional filters that add extra security parameters to the PIM control plane. In the INCLUDE mode, reception of packets is allowed for only those multicast addresses specified in the source-list parameter. In the EXCLUDE mode, reception of packets is allowed for all multicast addresses except those specified in the source-list parameter. The source list is a list of IP source addresses from which multicast reception is allowed and is configured in the form of an access control list (ACL).
The following examples explain the SSM process, beginning with Figure 3-23:
Step 1. The receiver joins R4 using an IGMPv3 join message. The source IP is located off of R3. Unicast routing is used to build state. Using the debug ip igmp and show ip mroute commands, you can see the state information can on R1:
*Nov 21 23:01:24.899: IGMP(0): Updating expiration time on
(10.1.12.12,232.1.1.1) to 180 secs
*Nov 21 23:01:24.899: IGMP(0): Send v3 init Query on Loopback0
*Nov 21 23:01:24.899: IGMP(0): Set report delay to 0.7 seconds to
respond to General Query on Loopback0
*Nov 21 23:01:24.899: IGMP(0): Set report delay to 0.2 seconds to
respond to General Query on Loopback0
*Nov 21 23:01:25.132: IGMP(0): Building v3 Report on Loopback0
*Nov 21 23:01:25.132: IGMP(0): Add Group Record for 232.1.1.1, type 1
*Nov 21 23:01:25.132: IGMP(0): Add Source Record 10.1.12.12
*Nov 21 23:01:25.132: IGMP(0): Send v3 Report with 1 group records on
Loopback0
*Nov 21 23:01:25.132: IGMP(0): Received v3 Report for 1 group on
Loopback0 from 10.11.11.11
*Nov 21 23:01:25.132: IGMP(0): Received Group record for group
232.1.1.1, mode 1 from 10.11.11.11 for 1 sources
*Nov 21 23:01:25.132: IGMP(0): MRT Add/Update Loopback0 for
(10.1.12.12,232.1.1.1) by 0
*Nov 21 23:01:25.132: IGMP(0): Updating expiration time on
(10.1.12.12,232.1.1.1) to 180 secs
R4#show ip mroute
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
(*, 239.1.1.4), 00:30:49/00:02:17, RP 0.0.0.0, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/0, Forward/Sparse, 00:30:49/00:02:17
(10.1.12.12, 232.1.1.1), 00:30:50/00:02:29, flags: sLTI
Incoming interface: Ethernet1/0, RPF nbr 10.1.3.1
Outgoing interface list:
Loopback0, Forward/Sparse, 00:01:33/00:02:29
(*, 224.0.1.40), 00:30:50/00:02:12, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/0, Forward/Sparse, 00:27:43/00:02:12
R1#sh ip mroute
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
(10.1.12.12, 232.1.1.1), 00:05:41/00:02:43, flags: sT
Incoming interface: Ethernet0/0, RPF nbr 10.1.1.2
Outgoing interface list:
Ethernet1/0, Forward/Sparse, 00:05:41/00:02:43
(*, 224.0.1.40), 00:06:41/00:02:18, RP 0.0.0.0, flags: DPL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
On R4, the IGMPv3 join is seen and the mroute table is updated. The “s” flag denotes the SSM state. R1 shows the incoming interface as Ethernet0/0 and the outgoing interface as Ethernet1/0 for 232.1.1.1. The incoming interface is based on unicast table for 10.1.12.12, and the outgoing is based on receiver reachability via the unicast routing table. When an additional subscription for the group is processed by the network from a separate source (10.2.12.12) connected to R3, the SSM network adjusts, adding the second channel. Figure 3-24 illustrates this dual-channel instantiation.
Step 2. The show ip mroute command shows the dual channel for 232.1.1.1 with different source IP addresses.
R2#show ip mroute
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
…
(10.1.12.12, 232.1.1.1), 00:16:31/00:02:42, flags: sT
Incoming interface: Ethernet1/0, RPF nbr 10.1.10.1
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:16:31/00:02:42
(10.2.12.12, 232.1.1.1), 00:17:30/00:02:39, flags: sLTI
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse, 00:00:20/00:02:39
….
R1 has no state without the source IP address available in the routing table for 10.2.12.12, 232.1.1.1). This is shown using the show ip mroute command:
R1# show ip mroute
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
(10.1.12.12, 232.1.1.1), 00:19:04/00:03:09, flags: sT
Incoming interface: Ethernet0/0, RPF nbr 10.1.1.2
Outgoing interface list:
Ethernet1/0, Forward/Sparse, 00:19:04/00:03:09
(*, 224.0.1.40), 00:20:04/00:02:01, RP 0.0.0.0, flags: DPL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
Step 3. The source is active and available as seen in the unicast RIB. The state table on R1 changes with the state of (10.2.12.12, 232.1.1.1) seen in the routing table. These are viewed using the debug ip pim and show ip mroute commands:
*Nov 21 22:55:59.582: PIM(0): Insert (10.2.12.12,232.1.1.1) join in nbr
10.1.1.2's queue
*Nov 21 22:55:59.582: PIM(0): Building Join/Prune packet for nbr
10.1.1.2
*Nov 21 22:55:59.582: PIM(0): Adding v2 (10.2.12.12/32, 232.1.1.1),
S-bit Join
*Nov 21 22:55:59.582: PIM(0): Send v2 join/prune to 10.1.1.2
(Ethernet0/0)
R1#show ip mroute
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
(10.2.12.12, 232.1.1.1), 00:03:38/00:02:33, flags: sT
Incoming interface: Ethernet0/0, RPF nbr 10.1.1.2
Outgoing interface list:
Ethernet1/0, Forward/Sparse, 00:03:38/00:02:33
(10.1.12.12, 232.1.1.1), 00:25:29/00:02:38, flags: sT
Incoming interface: Ethernet0/0, RPF nbr 10.1.1.2
Outgoing interface list:
Ethernet1/0, Forward/Sparse, 00:25:29/00:02:38
(*, 224.0.1.40), 00:26:28/00:02:31, RP 0.0.0.0, flags: DPL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
For the same multicast group, two channels are shown in the output.
Step 4. The unicast routing table changes on R2, a new link is added, and the connection between R1 and R3 is brought down. Prior to the change, the mroute state on R2 is shown using the show ip mroute command:
R2#show ip mroute
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
..
(10.1.12.12, 232.1.1.1), 00:37:33/00:03:19, flags: sT
Incoming interface: Ethernet1/0, RPF nbr 10.1.10.1
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:09:15/00:03:19
..
The mroute state snapshot for (10.1.12.12, 232.1.1.1) shows the incoming interface of Ehternet1/0, which connects R1 to R3. Figure 3-25 shows the topology change.
At R2, the topology change can be seen using the show ip mroute 232.1.1.1 command:
R2#show ip mroute 232.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
(10.1.12.12, 232.1.1.1), 00:42:23/00:03:28, flags: sT
Incoming interface: Ethernet3/0, RPF nbr 10.1.9.2
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:00:01/00:03:28
(10.2.12.12, 232.1.1.1), 00:43:23/00:02:55, flags: sLTI
Incoming interface: Ethernet3/0, RPF nbr 10.1.9.2
Outgoing interface list:
Loopback0, Forward/Sparse, 00:26:12/00:02:55
The incoming interface is Ethernet3/0.
IGMPv3 subscribes the receiver to the specific source IP address in the join message. This greatly simplifies the tree build-up process, using an explicit source tree from the source to the receiver in SSM, and it leverages existing unicast routing information for multicast forwarding. This completely eliminates the need for an RP in the network while ensuring a loop-free forwarding topology.
Summary
Multicast networks consist of senders, receivers, and the network infrastructure. The communication of multicast messages uses the concept of a tree. The sender is the root of the tree and the receiver is a leaf, with the network being the branches or infrastructure. The responsibility of the infrastructure is to eliminate any duplication of messages, consequently removing any loops. This process is known as building the tree. Trees are built using one of two methods: a shared-tree shown as an (*,G) or a source-tree shown as an (S,G). A shared-tree is rooted at the rendezvous point (RP), and a source-tree is rooted at the source (S,G) or sender.
Layer 3 networking devices discover other directly attached networking devices and establish a “neighbor” relationship. Neighbor information is exchanged, which aids in understanding the capability of each device and in minimizing multicast joins from the same segment.
Protocol independent multicast (PIM) uses the underlying unicast routing protocol to forward multicast messages. Because multicast routing is the opposite of unicast routing, in that it sends messages away from the source, a new routing table for multicast specific routes is not required. Multicast routing uses the concept of reverse path forwarding (RPF).
Forwarding of multicast messages can operate in the following modes: dense, sparse, and sparse-dense. Dense mode uses a push model, in which multicast messages are sent to every PIM-enabled device in the network. By contrast, sparse mode uses a pull model, in which receivers request multicast messages. Finally, sparse-dense mode uses dense-mode flooding to propagate RP information and sparse-mode for sending messages. Be aware that a failure of the RP in a sparse-dense mode environment can cause dense-mode flooding.
Internet Group Management Protocol (IGMP) is the most common mechanism to control multicast messages at Layer 2. There are currently three versions of IGMP. IGMPv3 is the latest, and it does not require the use of an RP because it has awareness of the multicast source.
Any-source multicast (ASM) uses both a shared-tree and a source-tree. Typically, multicast messages start from a shared-tree using a RP but switch to a source-tree to provide better network efficiency. Bidirectional PIM (BiDir) is generally used to many-to-many communication and it supports only shared-trees. Source-specific multicast (SSM) requires receivers to be IGMPv3-aware, because this method uses only source-trees.