CCNP Switch: IP Multicast
Multicast Overview
In a network, three basic types of IP traffic traverse the routers and switches:
- Unicast—Packets that are sent from one source host address to a single destination host address. A router or Layer 3 switch forwards them by finding the destination IP address in its routing table. A Layer 2 switch relies on the destination’s MAC address only.
- Broadcast—Packets that are sent from one source host address to a broadcast destination address. The destination can be all hosts (255.255.255.255), a directed broadcast to a subnet (that is, 192.168.10.255), or some portion of a subnet. A router or Layer 3 switch will not forward these by default unless some method of relaying has been configured. A Layer 2 switch floods the packet out all ports on the destination VLAN.
- Multicast—Packets that are sent from one source host address to a special group-based destination address. The destination represents only the hosts that are interested in receiving the packets, and no others. A router or Layer 3 switch does not forward these packets by default unless some form of multicast routing is enabled. A Layer 2 switch cannot learn the location of the destination multicast address, so the packets are flooded to all ports on the destination VLAN by default.
Two extremes are covered here:- A unicast, which travels from host to host
- A broadcast, which travels from one host to everyone on a segment
Multicast falls somewhere in the middle. The intention is to send packets from one host to only the users who want to receive them—namely, those known to belong in the designated multicast group. Ideally, the recipients of multicast packets could be located anywhere, not just on the local segment.
Multicast traffic is generally unidirectional. Because many hosts are receiving the same data, it makes little sense to allow one of the hosts to send packets back toward the source over the multicast mechanism. Instead, a receiving host can send return traffic to the source as a unicast.
Multicast traffic also is sent in a best-effort connectionless format. UDP (connectionless) commonly is used, whereas TCP (connection-oriented) is not.
Hosts that want to receive data from a multicast source can join or leave a multicast group dynamically. In addition, a host can decide to become a member of more than one multicast group at any time. The principal network task is then to figure out how to deliver multicast traffic to the group members without disturbing other uninterested hosts.
Multicast Addressing
Routers and switches must have a way to distinguish multicast traffic from unicasts or broadcasts. This is done through IP addressing by reserving the Class D IP address range, 224.0.0.0 through 239.255.255.255, strictly for multicasting. Network devices quickly can pick out multicast IP addresses by looking at the four most significant bits, which are always 1110. For example, the first octet of 224.0.0.0 is 224, which also can be written as 1110 0000. The upper end of the address range begins with 239, or 1110 1111.
How does a router or switch relate a multicast IP address with a MAC address? There is no Address Resolution Protocol (ARP) equivalent for multicast address mapping. Instead, a reserved organizationally unique identifier (OUI) value is set aside so that multicast MAC addresses always begin with 0100.5e (plus the next lower bit, which is 0). The lower 28 bits of the multicast IP address also must be mapped into the lower 23 bits of the MAC address by a simple algorithm. Figure 15-1 shows the address mapping concept. Only the lower 23 bits of the address are copied from IP to MAC (or vice versa). The high-order prefixes of both IP and MAC addresses are fixed, predictable values.
Figure 15-1 Multicast IP-to-MAC Address Translation
Notice, however, that 5 bits of the IP address are not transferred into the MAC address at all. This gives the possibility that the multicast MAC addresses are not entirely unique. There are 32 (5 bits’ worth) different multicast IP addresses that all could correspond to a single multicast MAC address.
Because of this ambiguity, a multicast host has a small problem when it receives an Ethernet frame destined for a multicast MAC address. That one MAC address actually could correspond to 32 different multicast IP addresses. Therefore, the host must receive and examine every frame that has the MAC address it is interested in—regardless of which of the 32 IP addresses the frame was originally destined for. The host then must examine the IP header inside each frame to verify that the more specific IP multicast address is a desired multicast group. If not, the frame is discarded. Some of the IP multicast address space has been reserved for a particular use:
- Complete multicast space: 224.0.0.0 through 239.255.255.255—This entire range of IP addresses can be used for multicast purposes.
- Link-local addresses (224.0.0.0 through 224.0.0.255)—This space can be used by network protocols only on the local network segment. Routers do not forward these packets.
This space includes the all-hosts address 224.0.0.1, all-routers 224.0.0.2, OSPFrouters 224.0.0.5, and so on. These are also known as fixed-group addresses because they are well-known and predefined. - Administratively scoped addresses (239.0.0.0 through 239.255.255.255)—This space can be used in private multicast domains, much like the private IP address ranges from RFC 1918. These addresses are not routed between domains, so they can be reused.
- Globally scoped addresses (224.0.1.0 through 238.255.255.255)—This space can be used by any entity; these addresses can be routed across an organization or the Internet, so they must be unique and globally significant. (Think of this range as neither local nor private; it is the rest of the multicast range.)
Routing Multicast Traffic
IP multicast traffic must be routed, just like any other Layer 3 packets. The difference is in knowing where to forward the packets. Unicast IP packets have only one destination interface (even if multiple paths exist), whereas multicast IP packets can have many destination interfaces, depending upon where the recipients are located.
Several multicast routing protocols are available. This text focuses only on Protocol Independent Multicast (PIM), as does the BCMSN course and exam. Multicast routing as a whole is better covered in IP routing courses and textbooks. This section provides an overview of the PIM operation to provide a good understanding of the routing concepts. This is a necessary foundation for understanding multicast switching (Layer 2).
Regardless of the multicast routing protocol used, you first must enable multicast routing on the router or switch with the following global configuration command:
Switch(config)# ip multicast- routing
Multicast Trees
The routers (or multilayer switches) in a network must determine a forwarding path to get multicast packets from the source (sender) to each of the recipients (receivers). Think of the network as a tree structure. At the root of the tree is the source, blindly sending IP packets to a specific multicast address. The source is never aware of list of hosts or recipients that are members of a multicast group. Instead, it depends upon multicast routers and switches to handle the actual multicast packet delivery.
Each router along the way sits at a branch or fork in the tree. If a router knows which branches of the tree have interested the multicast group recipients located on them, it also knows which of its interfaces to replicate the multicast packets onto. Some routers have no downstream recipients, so they do not need to forward the multicast traffic. Other routers have many downstream recipients.
This tree structure is somewhat similar to a spanning-tree topology because it has a root at one end and leaf nodes (the recipients) at the other end. Although a spanning tree must connect the root to all end nodes, the multicast tree does not necessarily have to. The tree is also loop free so that none of the multicast traffic gets fed back into the tree.
Reverse Path Forwarding
Routers usually have one test to perform on every multicast packet they receive. Reverse Path Forwarding (RPF) is a means to make sure packets are not being injected back into the tree at an unexpected location. In other words, all multicast traffic always should flow away from the root of the tree, from the source toward the recipients.
As a packet is received on a router interface, the source IP address is inspected. The idea is to look backward and verify that the packet arrived on the same interface where the source can be found. If this is true, the packet actually is proceeding out the branches of the tree, away from the source. If it is not true, someone else has injected the packet on an unexpected interface, headed back down the branches of the tree toward the source.
To perform the RPF test, the PIM router looks up the source address in its unicast routing table.
Notice that this is the reverse of normal packet forwarding, which uses the destination address. If the next-hop interface used to reach the source address also matches the interface where the packet was received, the packet can be forwarded or replicated toward the multicast recipients. If not, the packet quietly is discarded.
IGMP
How does a router know of the recipients in a multicast group, much less their locations? To receive multicast traffic from a source, every recipient first must join a common multicast group. This group also is known by its multicast IP address. The source doesn’t necessarily have to join
the group, though; it only needs to know the multicast address used by the recipients so it can send traffic to them. A host can join a multicast group by sending a request to its local router. This is done through the Internet Group Management Protocol (IGMP). IGMPv1 is defined in RFC 1112 and its successor, IGMPv2, in RFC 2236. When several hosts join a group by contacting their local routers, the multicast routing protocol (such as PIM) “connects the dots” and forms the multicast tree between routers.
IGMPv1
To join a multicast group, a host can dynamically send a Membership Report IGMP message to its local router. This message tells the router what multicast address (group) the host is joining. The multicast address is used as the destination IP address and the group address listed in the message. Therefore, the multicast router must intercept all packets that are destined to multicast addresses to receive the membership reports and add hosts to the appropriate groups.
Every 60 seconds, one router on each network segment queries all hosts to see if they are interested in receiving multicast traffic. This router is known as the IGMPv1 querier and functions simply to invite hosts to join a group. Queries are sent to the 224.0.0.1 all-hosts multicast address for quick distribution. If a host is interested in joining a group, or if it wants to continue receiving a group that it already has joined, it must respond with a membership report.
TIP Notice that the querier sends its invitations to a multicast group address, 224.0.0.1. Does this mean that every host on a network first must join the 224.0.0.1 group? Actually, every host is inherently a member of this group, without a formal IGMP exchange. The IP protocol stack that runs on a host already knows to accept and examine any message that is sent to 224.0.0.1. The same is true of other protocols, such as OSPF, which use other multicast link-local addresses. In the OSPF case, every participating router automatically knows to listen to the 224.0.0.5 “all-OSPF-routers” address.
Hosts can join multicast groups at any time. However, IGMPv1 does not have a mechanism to allow a host to leave a group if it is no longer interested in the group’s content. Instead, routers age a multicast group out of an interface (network segment) if no membership reports are received for three consecutive query intervals. This means that, by default, multicast traffic still is sent onto a segment for up to 3 minutes after all the group members have stopped listening.
Notice that a router does not need to keep a complete host membership list for each multicast group that is active. Instead, it needs to only record which multicast groups are active on which interfaces. Whether 1 host or 100 hosts on a network segment are members of a group, the router still needs to send only one copy of a multicast packet onto that segment.
IGMPv2
IGMP version 2 introduced several differences from the first version. Queries can be sent as general queries to the all-hosts address (as in IGMPv1) or group-specific queries, which are sent only to members of a specific group.
In addition, hosts are allowed to leave a group dynamically. When a host decides to leave a group it has joined, it sends a Leave Group message to the all-routers address (224.0.0.2). All routers on the local segment take note, and the querier router decides to investigate further. It responds with a group-specific query message, asking if anyone is still interested in receiving traffic for that group. Any other interested hosts must reply with a membership report. Otherwise, the querier safely assumes that there is no need to continue forwarding the group traffic on that segment.
NOTE If any IGMPv1 routers are on a segment, all routers on the segment must run IGMPv1. Otherwise, the IGMPv1 routers cannot understand the IGMPv2 messages.
On interfaces where PIM is configured, IGMPv2 is enabled by default. PIM is covered in the next section. To change the IGMP version, you can use the following interface-configuration command:
Switch(config-if)# ip igmp version {1 | 2 | 3}
IGMPv3
The third version of IGMP is documented in RFC 3376. Basically, IGMPv3 offers the functionality of IGMPv2 and adds support for multicast source filtering. With source filtering, a recipient host can request membership in a multicast group and also supply a list of IP addresses representing multicast sources to include or exclude. In other words, a recipient can specify which sources it is or isn’t interested in receiving multicast content from.
A router running IGMPv3 can coexist with other hosts running an older version. To do this, the router must keep itself compatible with the lowest IGMP version learned in each multicast group.
TIP IGMPv3 primarily is used for source-specific multicast (SSM). SSM is based on PIM sparse mode, with a separate source-distribution tree for each source that is used within each group. IGMPv3 is discussed briefly in comparison to the previous versions, although SSM is beyond the scope of the BCMSN course and exam.
PIM
Protocol Independent Multicast (PIM) is a routing protocol that can be used for forwarding multicast traffic between IP subnets or network segments. PIM operates independently of any particular IP routing protocol. Therefore, PIM makes use of the IP unicast routing table and does not keep a separate multicast routing table. (The unicast routing table is itself routing protocol– independent because one or more routing protocols can be used to populate a single table.)
PIM can operate in two modes, depending on the density of the recipients in a multicast group. Cisco has developed a third hybrid mode as well. The PIM modes are as follows:
- PIM dense mode
- PIM sparse mode
- PIM sparse-dense mode
In addition, two versions of the PIM protocol can be used in a network: PIM version 1 and PIM version 2. By default, PIM version 2 is used on a router interface. To change the version, you can use the following interface-configuration command:
Switch(config-if)# ip pim version {1 | 2}
PIM Dense Mode
PIM routers can be configured for dense mode (also called PIM-DM) if it is safe to assume that a multicast group’s recipients are located on every subnet. In other words, the multicast group is densely populated across the network.
The multicast traffic’s source becomes the root of the tree, and the multicast tree is formed from the source to each of the recipients. This is also termed (S,G) multicast traffic, where the path between the source and group members is unique and well defined.
The multicast tree is built by first allowing a flood of traffic from the source to every dense-mode router in the network. The tree is grown from the root toward the leaves. For a brief time, unnecessary traffic is allowed, much as a broadcast would do. However, as each router receives traffic for the group, it must decide whether it already has active recipients wanting to receive the data. If so, the router can remain quiet and let the flow continue.
If no hosts have registered for the multicast group with the router (via IGMP), the router sends a Prune message to its neighbor, toward the source. That branch of the tree then is pruned off so that the unnecessary traffic does not continue. The resulting tree is called a source tree or a source distribution tree because it is unique from the source to the receivers.
Figure 15-2 shows dense mode’s flood-then-prune operation. The tree is built by a wave of join requests moving through all dense-mode multilayer switches. Then the switches that have no interested hosts request to be pruned from the tree. The resulting tree and multicast flow are shown in Figure 15-4 in the section on PIM sparse mode.
Figure 15-2 PIM Dense Mode Constructs a Multicast Tree
PIM-DM routers become aware of their neighbors by exchanging hello messages. This neighbor information is used first to build the tree to all neighbors and then to prune branches. If a multicast flow has begun and the tree has been built and then pruned, the tree exists only where active group members are located. After that, if a new host registers for the group, the branch of the network where it is located can be added or grafted back onto the tree. To configure PIM dense mode on an interface, use the following interface-configuration command:
Switch(config-if)# ip pim dense- mode
PIM Sparse Mode
PIM sparse mode (also called PIM-SM) takes a different approach: The multicast tree isn’t extended to a router unless a host there already has joined the group. The multicast tree is built by beginning with the group members at the end leaf nodes and extending back toward a central root point. The tree is grown in reverse, from the leaves toward the root.
Sparse mode also works on the idea of a shared tree structure, where the root is not necessarily the multicast source. Instead, the root is a PIM-SM router that is centrally located in the network. This root router is called the rendezvous point (RP).
The tree from the RP to the group members is actually a subset of the tree that could be drawn from the source to the group members. Subsequently, if a multicast source anywhere in the network can register for group membership with the RP, the tree can be completed. Because of this, the sparse-mode tree is called a shared tree. Sparse mode multicast flows are described as (*,G) because the tree allows any source to send to a group.
As a recipient joins a multicast group via IGMP, the local router forwards the membership report toward the RP at the root of the tree. Each router along the way adds that branch to the shared tree.
Pruning is performed only when a group member is removed from the group. This process is shown in Figure 15-3. Notice that it consists of only one step: Only routers with active group members join the tree. The routers that did not join the group are not pruned because they never became a part of the tree in the first place.
Figure 15-3 PIM Sparse Mode Constructs a Multicast Tree
Figure 15-4 illustrates the resulting tree structures for both PIM dense mode and PIM sparse mode, along with the multicast data flow. Notice that both PIM modes have constructed identical tree structures, yielding the same multicast traffic flow patterns.
Figure 15-4 Identical Results from PIM Dense and Sparse Modes
To configure PIM sparse mode on an interface, use the following interface-configuration command:
Switch(config-if)# ip pim sparse- mode
PIM Sparse-Dense Mode
PIM has the potential to support both dense and sparse modes because they can exist on different multicast groups in a network and even on the same router interface. Cisco offers the hybrid sparse-dense mode, allowing a PIM router to use sparse or dense mode on a per-group basis. If a group has an RP defined, sparse mode is used; otherwise, dense mode is used. To configure PIM sparse-dense mode on an interface, use the following interface-configuration command:
Switch(config-if)# ip pim sparse- dense- mode
PIM Version 1
For routers using the first version of PIM, RPs can be configured manually or by the more dynamic auto-RP process. To manually identify an RP, use the following global configuration command:
Switch(config)# ip pim rp- address ip-address [ access-list] [ override]
You can limit the range of multicast groups supported by the RP by using an access list. The override keyword causes this RP to be preferred over any that is automatically determined.
Because the RP doesn’t advertise itself, its address and function must be defined on every router in the PIM domain, including the RP itself. This makes future changes in the RP location difficult to carry out because every router must be reconfigured with the new RP address.
Cisco also provides a proprietary means of automatically informing PIM-SM routers of the appropriate RP for a group. This is known as Auto-RP. This is done by identifying a centrally located and well-connected router to function as the mapping agent. The mapping agent learns of all candidate RPs that are announced over the Cisco-RP-Announce multicast address 224.0.1.39. (By definition, all PIM-SM routers automatically must join 224.0.1.39.)
To define a router as a mapping agent, use the following global configuration command:
Switch(config)# ip pim send- rp- discovery scope ttl
The mapping agent sends RP-to-group mapping information to all PIM routers over the Cisco-RPDiscovery multicast address 224.0.1.40. The Time To Live (TTL) value is sent in these messages to limit the scope of the mapping. This limits how many router hops away the information will reach and still be valid.
You then explicitly must define each candidate RP router. When a router knows it can be an RP, it begins sending announcements to the mapping agent. Configure a router as a candidate RP with the following global configuration command:
Switch(config)# ip pim send- rp- announce type mod/num scope ttl [ group- list accesslist] [ interval seconds]
The interface must be given because it corresponds to the advertised RP address and identifies where the mapping agent can be found. The announcement’s scope is limited by the number of router hops (TTL). The router also can advertise itself as a candidate RP for the multicast groups permitted in the group-list access list. By adding the interval keyword, the announcements will be sent at an interval of seconds.
PIM Version 2
The second version of PIM also includes a dynamic RP-to-group mapping advertisement mechanism. This is known as the bootstrap router method and is standards based.
PIMv2 is similar to the Cisco auto-RP method. First, a bootstrap router (BSR) is identified; this router learns about RP candidates for a group and advertises them to PIM routers. You need to configure only the BSR and candidate RPs; all other PIM routers learn of the appropriate RP from the BSR. Define a BSR using the following global configuration command:
Switch(config)# ip pim bsr- candidate type mod/num hash-mask-length [ priority]
The interface specified determines the BSR address. RP selection for a group is based on a hashing function. The length of the hash mask controls the number of consecutive multicast groups that hash to the same RP.
Next, you must identify each of the candidate RP routers. Configure each RP with the following global configuration command:
Switch(config)# ip pim rp- candidate type mod/num ttl [ group- list access-list]
Finally, by default, the bootstrap messages permeate the entire PIM domain. You can limit the scope of the advertisements by defining PIMv2 border routers, which will not forward the bootstrap messages any further. Use the following global configuration command:
Switch(config)# ip pim border Switching Multicast Traffic
Routers or multilayer switches can build multicast trees and set up forwarding in an efficient, intelligent manner. At Layer 2, however, a switch can examine only the Ethernet frame header to find the source and destination MAC addresses. These switches cannot enjoy the luxury of ondemand multicast forwarding; the best information they have is the destination multicast address, and that signifies only that the frame needs to be flooded out all ports on the VLAN.
Two methods have been developed to help switches make intelligent forwarding decisions for multicast traffic: IGMP snooping and CGMP. One method requires more sophisticated switching hardware, whereas the other method leans on a nearby router for assistance.
IGMP Snooping
In normal operation, a host that desires multicast group membership must contact a local router so that it is added into the multicast tree. IGMP snooping allows a switch to eavesdrop on these IGMP membership reports so that it can find out who is requesting which group.
Recall that to join a group, a host must send its IGMP membership report to the multicast address of the group itself. To eavesdrop, a Layer 2–only switch must listen to every multicast frame to find the IGMP information. Clearly, this becomes a burden to the switch CPU.
A multilayer or Layer 3 switch has a clear advantage: It inherently can pick out Layer 3 information within frames. This type of switch must listen only to every IGMP packet. When a membership report is overheard, the switch adds the multicast group’s MAC address to its Content Addressable Memory (CAM) table (if it doesn’t already exist), along with the source switch port where the IGMP packet was received. This links the group address with the host that requested membership.
As other hosts request membership to the group, the respective switch ports are added to the CAM table list for the group address. Now, when a frame destined for the multicast group arrives, it can be replicated out exactly the right ports to reach the recipients.
With IGMP snooping, there are two special cases of group membership in the CAM table:
- All multicast routers known by the switch (dynamically learned) also are recorded for a group in the CAM table. Multicast frames also must be replicated toward any routers so that they can be routed elsewhere, if needed.
- The switch CPU itself is also a member of every multicast group so that it can watch IGMP messages come and go. Only IGMP traffic is processed; the CPU does not inspect other multicast frames.
IGMP snooping is not supported on all Cisco switch platforms. It is supported on the Catalyst 2950, 3560, 3750, 4500, and 6500 families because each has additional hardware to support Layer 3 functionality. On those platforms, IGMP snooping is enabled on all switch ports and VLAN interfaces, by default. To enable or disable IGMP snooping, use the following global configuration command:
Switch(config)# [ no] ip igmp snooping
CGMP
When a Layer 2 switch cannot perform IGMP snooping itself, a nearby multicast router can assist. Cisco developed the proprietary Cisco Group Membership Protocol (CGMP) for this purpose. A router or multilayer switch configured for multicast routing also can be configured for CGMP.
As hosts send IGMP membership reports to join or leave multicast groups, the CGMP router relays this message to all interested switches. The CGMP messages are multicast over the wellknown address 0100.0cdd.dddd; by definition, this multicast group is flooded everywhere as a special case so that CGMP messages can be transported across non-CGMP switches.
The CGMP messages include the requesting host’s MAC address, along with the MAC address of the multicast group it wants to join or leave. When a Layer 2 switch receives this CGMP information, it becomes a simple task to add the multicast group and associated hosts to its CAM
NOTE As a rule, IGMP snooping and CGMP are mutually exclusive; they cannot be used simultaneously on a switch. For switches that have IGMP snooping capability, IGMP snooping is enabled by default. For switches that cannot do IGMP snooping, CGMP is enabled by default. If you are configuring IP multicast support in your network, be sure to identify any legacy Layer 2 switches that are capable only of flooding multicast traffic. Enable CGMP on these switches, and then enable CGMP on an upstream multicast router or multilayer switch. This way, your entire network will be capable of intelligently constraining the flooding of multicast traffic.
Verifying Multicast Routing and Switching
To verify the operation of the features discussed in this chapter, you can use the commands listed in the sections that follow.
Multicast Routing with PIM
Remember that PIM is based on the unicast routing table; no separate multicast routing table is kept. Table 15-2 lists those commands that you need to verify that the multicast routing with PIM operations is working as intended.
Table 15-2 Commands for Verifying Multicast Routing with PIM
Multicast Switching
Table 15-3 lists those commands that you need to verify that IGMP snooping is configured and working as intended.
Table 15-3 Commands for Verifying IGMP Operation
You also can perform some multicast testing with multilayer switches. Choose a multicast group address that several switches can join. Configure a specific interface to join the group with the following interface-configuration command:
Switch(config-if)# ip igmp j oin- group multicast-address
Then you can use show commands to see information about the group and the IGMP membership. After several switches have joined the group, you can issue a ping to the multicast group IP address. Every switch that has joined the group should answer with a reply.
What Would Happen Without a Multicast Router?
Suppose that a network is so small that a multicast router is not available. Instead, only one or more Layer 2 or Layer 3 switches are used. Can a multicast group be supported for users who want to view a streaming video from a server?
Multicast always can be supported, with or without a router. When a host sends an IGMP membership report to join a group, it does so blindly. After all, a host does not know about multicast routers at all—it just sends out a request to join and hopes that it will start receiving traffic destined for the multicast group address. Even if a multicast router is present, it doesn’t send a reply to a host that has joined a group. A router only periodically sends out membership queries asking if hosts still want to remain a member of the group.
In this small network, Layer 2 switches simply flood the server’s multicast traffic out all ports on the VLAN. No CGMP router is available to lend its intelligence. Layer 3 switches can use IGMP snooping, however, to constrain the multicast flooding. Although a router isn’t present, the switch can still listen to the membership reports being sent to the nonexistent router.