Chapter 12

Implementing Multicast

This chapter covers the following topics:

Multicast Overview: This section provides an overview of multicast traffic and how it is transported through both wired and wireless networks.

Implementing mDNS: This section explains the mDNS mechanism that is used by Apple Bonjour and Google Chromecast to locate services dynamically. It also describes how to configure a Cisco WLC to act as an mDNS Bonjour gateway that can assist service discovery across network segments.

Implementing Multicast Direct: This section describes the Multicast Direct feature and how it can be used to deliver multicast video streams more reliably and effectively in a wireless environment.

This chapter covers the following ELWSI exam topics:

3.1 Implement multicast components
3.2 Describe how multicast can affect wireless networks
3.3 Implement multicast on a WLAN
3.4 Implement mDNS
3.5 Implement Multicast Direct

Multicast traffic is typically sent by one source and received by a group of recipients that might be spread throughout a network. In addition, the recipients within the group might change over time. Examples of multicast traffic include video streams for instruction or entertainment, certain audio conference calls, and one-to-many PC file imaging applications.

Because not everyone on a network wants to receive the traffic from a multicast source, the network infrastructure must have some means of forwarding traffic to exactly the destinations that want to receive it. This chapter covers multicast from a wireless network perspective.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 12-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix D, “Answers to the ‘Do I Know This Already?’ Quizzes and Review Questions.”

Table 12-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section	Questions
Multicast Overview	1–7
Implementing mDNS	8–9
Implementing Multicast Direct	10

1. When a multicast frame must be sent by an AP toward wireless clients, which of the following statements are true? (Choose all that apply.)
1. The client recipient must return an ACK frame.
2. The frame must be transmitted on a 20MHz channel.
3. The frame must be transmitted at the data rate already in use for the client.
4. The frame must be transmitted at the highest mandatory data rate.
2. To receive a multicast stream, a recipient host must first do which one of the following?
1. Send an ICMP Request packet to the multicast source address.
2. Send an IGMP Membership Report packet to the multicast source address.
3. Send an IGMP Membership Report to the upstream router.
4. Do nothing. Multicast traffic always reaches every host.
3. Which one of the following will maximize the efficiency of multicast traffic transport over a wireless network, where the recipients are at various locations?
1. Use the default WLC multicast-unicast mode.
2. Use the WLC multicast-multicast mode.
3. Enable PIM on every WLC.
4. Multicast traffic is not supported over a wireless network.
4. Suppose a WLC has been configured for multicast-multicast mode. Which one of the following actions must each AP take to participate in multicast traffic delivery?
1. Merely join the WLC with a CAPWAP tunnel.
2. Send CAPWAP packets with the WLC’s multicast group address as the destination.
3. Learn the WLC’s CAPWAP multicast group address and then send an IGMP membership report to join that group.
4. Enable a virtual interface that uses the CAPWAP multicast group address.
5. Which one of the following allows a WLC to determine if an AP has any active multicast recipients for a specific group address?
1. Entries in its ARP table
2. IGMP snooping
3. A valid CAPWAP group address
4. IGMP membership reports sent from the router
6. What is the correct function of an MGID?
1. It identifies an AP participating in multicast delivery.
2. It is an identifier assigned to each multicast source.
3. It is an identifier assigned to each multicast interface on a WLC.
4. It identifies each multicast group address and registered recipients.
7. Which one of the following is a true statement regarding multicast messaging on a WLC?
1. A controller can send mobility messages to other controllers via a multicast group address.
2. The mobility multicast group address must be the same as the CAPWAP multicast group address.
3. To multicast mobility messages between controllers, each controller must have a unique multicast group address.
4. All controllers in the same mobility group must have the same mobility multicast group address.
8. In order to assist Apple devices to discover online resources with the Bonjour protocol, which one of the following features should be configured?
1. IGMP snooping
2. Bonjour Direct
3. mDNS snooping
4. Multicast Direct
9. Which one of the following is uniquely used by LSS in replies to Bonjour requests for a specific resource?
1. The complete list of all Bonjour advertisements that have been received from all network segments
2. A list of only the resources learned on the list of neighboring APs
3. A list of only the Bonjour advertisements for the same resource requested
4. The address of the nearest mDNS router
10. Which one of the following is a unique characteristic of Multicast Direct?
1. A WLC will direct all multicast streams toward its next-hop router.
2. Specific multicast streams will be redirected toward wireless clients as unicast streams.
3. Multicast streams from wireless clients will be directed toward an anchor controller.
4. WLCs will provide an easy-to-use web-based interface to assist clients in receiving multicast traffic.

Foundation Topics

Multicast Overview

In a typical network, three basic types of IP traffic traverse the wired and wireless topologies:

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 group address, so the packets are flooded to all ports on the destination VLAN by default.

Two extremes are covered here, as illustrated in Figure 12-1:

Images — **Figure 12-1** *Comparison of Unicast, Broadcast, and Multicast Delivery*

A unicast, which travels from one host to another host
A broadcast, which travels from one host to every host 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. In Figure 12-1, only User-A and User-D are interested in receiving the multicast traffic. Ideally, the recipients of multicast packets could be located anywhere, not just on the local segment.

By default, a Layer 2 switch must flood broadcast and multicast packets to all of its interfaces that are mapped to the VLAN, in a best effort to reach every potential recipient. The same is true in a wireless network. Figure 12-2 compares broadcast or multicast delivery with an autonomous AP and a lightweight AP joined to a wireless LAN controller (WLC). Broadcast and multicast frames are transmitted into the AP’s cell on the relevant WLAN, and it is up to the individual clients to receive and interpret them. When a WLC is involved, the broadcast or multicast packet is received by the WLC and then sent to the AP over a CAPWAP tunnel. Nevertheless, the two AP scenarios deliver the frame into the cell for all clients to receive.

Tip

You should be aware of a few important aspects that the 802.11 standard defines about broadcast and multicast frames:

They are transmitted at the highest mandatory data rate. You should make sure that mandatory rate is usable at the edge of the AP cells.
They do not require an ACK.
They must be sent on the primary 20MHz channel so that all associated stations can receive them, regardless of what channel width is in use

Multicast traffic is generally unidirectional. Because many hosts will receive 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 is sent in a best-effort connectionless format, usually with UDP, but not with connection-oriented TCP.

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.

IP multicast traffic is routed, just like any other Layer 3 packets. The difference is in knowing where to forward the packets. Multicast IP packets can have many destination interfaces, depending on where the recipients are located. Routers use multicast routing protocols, such as Protocol Independent Multicast (PIM), to transport multicast packets from one router hop to another.

How does a router know of the recipients in a multicast group, much less of their locations? To receive multicast traffic from a source, every recipient must first join a common multicast group address. 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). To join a group, a host sends an IGMP Membership Report message to its local router. From then on, the router knows that the multicast group is active on the interface where the host connects. Hosts can also leave multicast groups at any time or age out if they do not answer periodic IGMP Queries.

Multicast Delivery in a Wireless Network

From Figure 12-2, you can see how multicast traffic is sent between the WLC and an AP, which are at each end of the split-MAC architecture. What goes into the controller comes out at the AP, even broadcast and multicast traffic. Most wireless networks are made up of multiple APs, so the scale of multicast delivery can grow too.

By default, a WLC operates in unicast mode (also called broadcast-unicast or multicast-unicast mode) to deliver multicast traffic to the APs that are joined to it. That means the controller must replicate the incoming multicast traffic and send it as a separate unicast connection to each AP over the CAPWAP tunnel that is already in place. Figure 12-3 shows a network with one WLC and three APs. For this example, the single multicast packet coming into the WLC must be copied three times and sent to AP-1, AP-2, and AP-3. This places the burden of replicating traffic on the WLC and its resources, rather than taking advantage of multicast’s one-to-many inherent efficiency. Imagine a large network that has a WLC controlling 3,000 APs. The unicast replication could become very taxing on the controller!

A better solution is to configure the controller for multicast delivery mode (also known as multicast-multicast mode). A CAPWAP multicast group address is assigned to the controller, which will be used as the destination address for all multicast traffic that will be tunneled to each AP. Keep in mind that controllers are usually separated from their APs by layers of switches and routers. Therefore, the multicast delivery must also rely on IP multicast routing within the wired network infrastructure. Each AP must join its controller’s multicast group before it can receive the multicast traffic.

Like any hosts that want to join a multicast group, the APs must learn of the CAPWAP multicast group address when joining the controller and then send IGMP membership report messages to join the group. Figure 12-4 illustrates this scenario, where three APs are requesting to join the CAPWAP group 239.1.1.9. The underlying wired network will use the IGMP requests to learn the location of each AP and will take care of replicating the multicast traffic to be delivered.

The result is shown in Figure 12-5. The controller can now relay incoming multicast traffic to all three of its APs by encapsulating it in CAPWAP with destination address 239.1.1.9. The burden on the controller is light because it just needs to relay traffic to a single multicast group destination.

When a multicast frame is sourced from a client on a WLAN, the AP sends it across the CAPWAP tunnel to WLC, which forwards it onto the wired network. The WLC must also create a copy the frame and send into the normal CAPWAP multicast group for delivery back into WLANs, where other wireless recipients may also be located.

The process is now straightforward, but how does the controller deliver multicasts that are destined for specific WLANs at the APs? After all, a single CAPWAP multicast group address is used to deliver multicast traffic to any WLAN necessary. To keep track, a controller maintains a Layer 2 table of multicast entries by mapping which of its interfaces should have multicast traffic sent to which of its WLANs.

Figure 12-6 provides an example. WLC interface wlan-a is configured to connect to VLAN 100, and any incoming multicast traffic should be forwarded to the WLAN named “WLAN-A.” Each of these table entries is assigned an arbitrary multicast group ID (MGID) as an index. Then as the controller encapsulates a multicast packet into the CAPWAP tunnel, it includes a bitmap that instructs the APs about the destination WLANs. In other words, the same IP multicast group address might exist on more than one WLAN, if hosts have registered to join it there. The AP can transmit the multicast frame onto each of the relevant WLANs, which might exist on both bands supported by the AP’s radios.

IGMP Snooping

You may have noticed that IGMP is designed to inform Layer 3 routers about multicast groups and members. Layer 2 devices do not participate in routing or IGMP, so they cannot enjoy the luxury of on-demand multicast forwarding at all; 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 or transmitted into the AP’s cell.

A feature called IGMP snooping allows a Layer 2 device to eavesdrop on IGMP membership reports that are sent by hosts. This allows a switch or a wireless controller to find out who is requesting which multicast group, without having to participate in IGMP at all.

Figure 12-7 illustrates how IGMP snooping works on a Layer 2 switch. In the left portion of the figure, connected hosts User-A and User-D that want to receive traffic sent to multicast group address 239.9.9.9 each send IGMP membership reports toward an upstream router. The Layer 2 switch cannot do anything with multicast routing, but it can intercept the IGMP messages to learn which interfaces have joined the multicast group. Then when traffic is sent from the multicast source to 239.9.9.9, shown in the right portion of the figure, the switch knows to forward that traffic out its interfaces where User-A and User-D are connected. The multicast traffic does not get forwarded out the other user interfaces.

A wireless LAN controller can also leverage IGMP snooping to identify hosts that join multicast groups. The goal is not to forward multicast frames to those specific hosts, however, because that is not practical in a wireless LAN. Instead, the controller snoops to learn which wireless clients want to join which multicast groups on which APs. The multicast traffic will be forwarded to all APs over their CAPWAP tunnels via the CAPWAP multicast address. However, only the APs hosting clients that are registered for the multicast group will transmit that traffic onto the WLAN. The other APs will not.

Controllers maintain a Layer 3 multicast group table that is based on the IGMP snooping activity. Figure 12-8 shows an example scenario with three APs, all offering the WLAN named “Staff.” Client-A and Client-B are associated with AP-1 and have sent IGMP membership reports to join multicast group 239.2.0.252. Client-C is associated with AP-3 and has joined the same multicast group address.

The controller’s Layer 3 multicast table is also shown. Each entry in the list is assigned an arbitrary MGID and includes the group address and VLAN ID involved. MGID 1234 also contains a list of specific clients that have joined the group, along with the AP names where they are associated. From this table, you can see that only APs AP-1 and AP-3 will need to transmit frames destined for multicast group 239.2.0.252 because they have valid client recipients.

Note

Cisco WLCs can also use Multicast Listener Discovery (MLD) to learn of IPv6 multicast recipients. MLD functions much like IGMP for IPv4, so it is not discussed here.

Implementing Wireless Multicast

Before the wireless network can successfully support multicast, the wired network infrastructure must be configured to support it. Once that occurs, the wired network can route the multicast traffic needed between WLCs and their APs.

The actual WLC multicast configuration process is fairly simple, using the following steps:

Step 1. Enable multicast mode and assign an AP multicast group address.

Figure 12-9 shows the configuration on an AireOS WLC, found by selecting CONTROLLER > General. The AP Multicast Mode is changed from Unicast to Multicast; then the multicast address box appears and is assigned to 239.1.1.9. Figure 12-10 shows the same configuration step on an IOS-XE-based controller in the Configuration > Services > Multicast page.

You can use an address from the range 239.0.0.0 through 239.255.255.255, but avoid 239.0.0.x and 239.120.0.x. If you need to configure multiple controllers with multicast group addresses, make sure each one gets a unique address.

Step 2. Enable global multicast mode and enable IGMP snooping.

Figure 12-11 shows the configuration step on an AireOS-based controller, found by navigating to CONTROLLER > Multicast. By default, global multicast mode and IGMP snooping are not enabled.

Once multicast and IGMP snooping are operational, you can view the multicast group information that a controller gathers from intercepted traffic. Navigate to Monitoring > Multicast to display the current list of Layer 3 and Layer 2 MGIDs, as shown in Figure 12-12. You can also select one of the Layer 3 MGIDs to display a list of specific clients that have joined the multicast group, along with the name of their associated APs.

Multicast traffic has one other useful purpose in the WLC operation—controllers can use it to send messages about client mobility to each other all at once. Without multicast, the controllers configured in the same mobility group must build a full mesh of connections to each other. Each time a client roams, that event must be shared with all other controllers in the mobility group. As the number of controllers grows, so does the number of controller-to-controller connections and the number of replicated client mobility event messages. By using multicast, any controller can send a single message to all other controllers that are members of the same multicast group.

To leverage multicast in a mobility group, you should enable Multicast Messaging on each controller and assign it a multicast group address. The group address should be unique from other multicast group addresses in use on the network, but the same address should be configured on each controller in the mobility group. In Figure 12-13, an AireOS controller has been configured to use 239.1.0.1 to communicate mobility events with the other controllers. You can find these settings by navigating to CONTROLLER > Mobility Management > Multicast Messaging.

Implementing mDNS

To locate services on a network, Apple devices use the Bonjour protocol, which is based on multicast DNS (mDNS). Google Chromecast is also based on mDNS. Devices such as AppleTV, printers, file shares, and AirPlay periodically advertise their services via multicast. Other devices can learn about those resources by receiving the multicast advertisements or by sending multicast queries to look for services.

As long as a device is using the same IP subnet as a service resource, it can discover that resource. Bonjour mDNS advertisements use UDP port 5353 and are sent to multicast IPv4 group address 224.0.0.251 or IPv6 address FF02::FB. Because the 224.0.0.251 address is within the range of link local addresses, the multicast packets will stay within the same IP subnet and will not be routed across subnets.

This means a device will not be able to discover resources that reside on another subnet without some sort of intervention. In Figure 12-14, the wireless client is located on VLAN 100 and is trying to find the AppleTV that is located in the same room. Unfortunately, the AppleTV resides on VLAN 200 and a different WLAN. Therefore, the client cannot find the resource it needs.

A Cisco WLC can act as an mDNS gateway and maintain a cache of Bonjour services that it overhears as they are advertised on VLANs that are directly connected to it. Then when wireless clients send an mDNS query to find a resource, the WLC will respond on behalf of the resources in its cache. In Figure 12-15, the WLC is able to respond to the client’s request for an AppleTV based on an entry in its mDNS Bonjour cache. As long as there is a router between the client and AppleTV VLANs, the two can connect.

Suppose there are many AppleTVs located in conference rooms throughout an enterprise. A client requesting AppleTV service might end up receiving responses listing all of those resources, even ones located in other buildings or floors. A WLC can also offer Location Specific Services (LSS) to limit resource replies so that they are relevant to the client’s physical location.

When LSS is enabled, each Bonjour advertisement is recorded along with the AP that relayed it. When a client requests a resource, the WLC will return only the relevant resources that are located near the list of neighboring APs.

A WLC can also learn of mDNS advertisements about resources that are available on wired network VLANs that do not directly connect. The mDNS AP feature allows an AP to snoop for mDNS advertisements it overhears on wired VLANs that connect to it. The AP then acts as a remote sensor and relays the advertisements to the WLC for its Bonjour cache.

To configure an AireOS controller to participate in mDNS, navigate to CONTROLLER > mDNS > General and then check the box next to mDNS Global Snooping to enable it, as shown in Figure 12-16. For an IOS-XE controller, go to Configuration > Services > mDNS Gateway and select Transport. Then choose ipv4, ipv6, or both, and click Apply.

Tip

As you configure mDNS on a controller, you may find several different names for it: mDNS, mDNS gateway, Bonjour Gateway, and mDNS Snooping.

By default, mDNS is prepopulated with a list of service advertisements that it recognizes. The WLC will respond to queries for these services, as shown by the check boxes under Query Status. You can enable LSS for the services too. Under the Origin column, you can tell the controller to respond to queries sourced from wireless, wired, or both (all).

You can also define an mDNS profile that can be applied to specific WLANs by navigating to CONTROLLER > mDNS > Profiles on an AireOS controller. A default profile named default-mdns-profile contains a list of the six services shown at the bottom of Figure 12-16, which will be applied to all WLANs defined on the WLC. You can edit the profile, as shown in Figure 12-17. Notice that the profile will be applied to WLC interfaces, but the list of interfaces shown is blank. You can specify interfaces within the profile or bind the profile to specific interfaces in the next step.

Finally, you must enable mDNS on each WLAN that will use it. Navigate to WLANs > WLANs and edit the desired WLAN; then select the Advanced tab, as shown in Figure 12-18. Scroll down to the mDNS section and check the box next to mDNS Snooping. The mDNS Profile drop-down menu will appear and the default-mdns-profile will be selected.

Implementing Multicast Direct

Recall from earlier in this chapter that APs transmit multicast frames at the lowest mandatory data rate configured. Suppose a wireless client is associated with an AP and is positioned such that the RF conditions allow the AP to transmit unicast frames to the client at a 24Mbps data rate. If the lowest mandatory data rate is 6Mbps, then any multicast traffic will be sent at that lower rate rather than the higher usable rate.

The quality of multicast streams used by real-time applications like video can suffer due to the lower data rate constraint and a lack of QoS marking. Also, recall that 802.11 normally requires transmitted frames to be acknowledged by the receiver to confirm receipt. Such acknowledgements are not possible with multicast traffic, so some streamed frames can be lost undetected. However, the resulting loss in the video quality will not go undetected.

You can leverage the Multicast Direct feature to enable a WLC to intercept certain multicast streams upon ingress and convert them to unicast streams at the AP. By using unicast, the streams can be sent at better data rates (if possible), and the streams will become more reliable with acknowledgements feedback from the receiving clients. Remember that there could be multiple clients registered to receive the multicast stream, so the WLC will need to replicate the stream traffic into an individual unicast stream to each client.

Tip

As you configure Multicast Direct, be aware that it is known by several different names: Multicast Direct, VideoStream, and Media Stream.

Use the following four steps to configure Multicast Direct on a WLC:

Step 1. Enable Multicast Direct globally.

Navigate to WIRELESS > Media Stream > General and check the box next to Multicast Direct feature, as shown in Figure 12-19. The fields under Session Message Config are used to notify and assist the stream recipient in case there are problems with the stream.

Step 2. Identify the multicast streams to intercept and convert.

Navigate to WIRELESS > Media Stream > Streams and click the Add New button to define a new stream template, as shown in Figure 12-20. This will tell the WLC which multicast streams to intercept and how to convert them to unicast. Define a name for the stream, the range of multicast group addresses that will be used, and the expected bandwidth for a typical stream. When traffic destined to any of those addresses is received, the WLC will reserve the resources you define. You can select a predefined resource template from the drop-down list. If the stream traffic exceeds the rate and packet size defined, then those packets will either be dropped or delivered as best effort.

Step 3. Enable Multicast Direct on a specific radio band.

Because Multicast Direct strives to maximize the quality of video streams, it relies on well-defined QoS mechanisms. The WLC can control how much load each type of media traffic (voice, video, and media streams) is allowed to use the wireless bandwidth at any given time. You will need to set the Multicast Direct parameters on each of the desired radio bands. For example, navigate to WIRELESS > 802.11a/n/ac > Media and select the Media tab, as shown in Figure 12-21.

Tip

If the radios in that band are already operational, you may have to disable them first, then make the Multicast Direct media changes, and then re-enable the radios.

Check the box next to Unicast Video Redirect to enable the multicast-to-unicast conversion. Then define the maximum bandwidth that will be allocated to the multicast direct streams, out of the total wireless bandwidth available at the AP. In the figure, the media streams are limited to 70 percent. The minimum client data rate is limited to 6Mbps by default.

In the Media Stream - Multicast Direct Parameters section, check the box next to Multicast Direct Enable to use the Multicast Direct feature. By default, there is no limit on the number of streams that can be sent through an AP radio or to an individual client. You can change these limits through the drop-down menus if needed. The Best Effort QoS Admission check box should remain unchecked unless you want additional streams to be allowed beyond the limit.

Step 4. Enable Multicast Direct on each desired WLAN.

Multicast Direct relies on QoS mechanisms for the best stream delivery, so you must also set the WLAN QoS to Gold (video) and enable Multicast Direct. Navigate to WLANs > WLANs and select a WLAN to edit. Then make the settings shown in Figure 12-22.

Summary

This chapter described the main considerations needed to design and implement the features necessary for multicast delivery over a wireless network. More precisely, you have learned the following:

How multicast traffic is transported over wireless
How IGMP snooping can be used to make multicast delivery more efficient
How wireless controllers can be configured to participate in multicast traffic delivery
How wireless controllers can integrate with multicast DNS to assist devices in finding networked resources
How Multicast Direct can be leveraged to improve the reliability and user experience of multicast video streams over wireless

References

Cisco Unified Wireless Multicast Design: https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-5/Enterprise-Mobility-8-5-Design-Guide/Enterprise_Mobility_8-5_Deployment_Guide/ch6_Mcst.html

“Understanding the ‘Videostream’ Feature” (Blog): https://mrncciew.com/2012/12/24/understanding-videostream-feature/

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a few choices for exam preparation: the exercises here, Chapter 18, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep Software Online.

Review All Key Topics

Review the most important topics in this chapter, noted with the Key Topic icon in the outer margin of the page. Table 12-2 lists these key topics and the page numbers on which each is found.

Table 12-2 Key Topics for Chapter 12

Key Topic Element	Description	Page Number
Figure 12-4	APs join a controller’s CAPWAP multicast group	286
Figure 12-5	Multicast delivery in WLC multicast mode	287
Figure 12-8	WLC data collected by IGMP snooping	289
Figure 12-15	mDNS Bonjour gateway operation	295
Step list	Multicast Direct configuration steps	297

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

IGMP

Internet Group Management Report (IGMP)

IGMP Snooping

Location Specific Services (LSS)

multicast group ID (MGID)

Multicast Listener Discovery (MLD)

PIM

Protocol Independent Multicast (PIM)