Multicast/Broadcast Mode
If your network supports packet multicasting, you can configure the multicast method that the controller uses. The controller can perform multicasting in one of two modes:
-
Unicast mode: In this mode, the controller unicasts every multicast packet to every access point associated to the controller. This mode is inefficient but might be required on networks that do not support multicasting.
-
Multicast mode: In this mode, the controller sends multicast packets to a CAPWAP multicast group. This method reduces overhead on the controller processor and shifts the work of packet replication to your network, which is much more efficient than the unicast method.
Note
We recommend that you use the unicast method only in networks where 50 or fewer APs are joined with the controller.
When you enable multicast mode and the controller receives a multicast packet from the wired LAN, the controller encapsulates the packet using CAPWAP and forwards the packet to the CAPWAP multicast group address. The controller always uses the management interface for sending multicast packets. Access points in the multicast group receive the packet and forward it to all the BSSIDs mapped to the interface on which clients receive multicast traffic. From the access point perspective, the multicast appears to be a broadcast to all SSIDs.
The controller supports Multicast Listener Discovery (MLD) v1 snooping for IPv6 multicast. This feature keeps track of and delivers IPv6 multicast flows to the clients that request them. To support IPv6 multicast, you must enable Global Multicast Mode.
Note |
When you disable the Global Multicast Mode, the controller still forwards the IPv6 ICMP multicast messages, such as router announcements and DHCPv6 solicits, as these are required for IPv6 to work. As a result, enabling the Global Multicast Mode on the controller does not impact the ICMPv6 and the DHCPv6 messages. These messages will always be forwarded irrespective of whether or not the Global Multicast Mode is enabled. |
Internet Group Management Protocol (IGMP) snooping is available to better direct multicast packets. When this feature is enabled, the controller gathers IGMP reports from the clients, processes them, creates unique multicast group IDs (MGIDs) from the IGMP reports after selecting the Layer 3 multicast address and the VLAN number, and sends the IGMP reports to the infrastructure switch. The controller sends these reports with the source address as the interface address on which it received the reports from the clients. The controller then updates the access point MGID table on the access point with the client MAC address. When the controller receives multicast traffic for a particular multicast group, it forwards it to all the access points, but only those access points that have active clients listening or subscribed to that multicast group send multicast traffic on that particular WLAN. IP packets are forwarded with an MGID that is unique for an ingress VLAN and the destination multicast group. Layer 2 multicast packets are forwarded with an MGID that is unique for the ingress interface.
When IGMP snooping is disabled, the following is true:
-
The controller always uses Layer 2 MGID when it sends multicast data to the access point. Every interface created is assigned one Layer 2 MGID. For example, the management interface has an MGID of 0, and the first dynamic interface created is assigned an MGID of 8, which increments as each dynamic interface is created.
-
The IGMP packets from clients are forwarded to the router. As a result, the router IGMP table is updated with the IP address of the clients as the last reporter.
When IGMP snooping is enabled, the following are true:
-
The controller always uses Layer 3 MGID for all Layer 3 multicast traffic sent to the access point. For all Layer 2 multicast traffic, it continues to use Layer 2 MGID.
-
IGMP report packets from wireless clients are consumed or absorbed by the controller, which generates a query for the clients. After the router sends the IGMP query, the controller sends the IGMP reports with its interface IP address as the listener IP address for the multicast group. As a result, the router IGMP table is updated with the controller IP address as the multicast listener.
-
When the client that is listening to the multicast groups roams from one controller to another, the first controller transmits all the multicast group information for the listening client to the second controller. As a result, the second controller can immediately create the multicast group information for the client. The second controller sends the IGMP reports to the network for all multicast groups to which the client was listening. This process aids in the seamless transfer of multicast data to the client.
-
If the listening client roams to a controller in a different subnet, the multicast packets are tunneled to the anchor controller of the client to avoid the reverse path filtering (RPF) check. The anchor then forwards the multicast packets to the infrastructure switch.
Note
The MGIDs are controller specific. The same multicast group packets coming from the same VLAN in two different controllers may be mapped to two different MGIDs.
Note
If Layer 2 multicast is enabled, a single MGID is assigned to all the multicast addresses coming from an interface.
Note
The maximum number of multicast groups supported per VLAN for a controller is 100.
This section contains the following subsections:
Restrictions on Configuring Multicast Mode
-
The Cisco Wireless network solution uses some IP address ranges for specific purposes, and you should keep these ranges in mind when configuring a multicast group:
-
224.0.0.0 through 224.0.0.255—Reserved link local addresses
-
224.0.1.0 through 238.255.255.255—Globally scoped addresses
-
239.0.0.0 through 239.255.x.y /16—Limited scope addresses
-
-
When you enable multicast mode on the controller, you must also configure a CAPWAP multicast group address. APs subscribe to the CAPWAP multicast group using IGMP.
-
Cisco 1100, 1130, 1200, 1230, and 1240 access points use IGMP versions 1, 2, and 3.
-
APs in monitor mode, sniffer mode, or rogue detector mode do not join the CAPWAP multicast group address.
-
The CAPWAP multicast group configured on the controllers should be different for different controllers.
-
Lightweight APs transmit multicast packets at one of the configured mandatory data rates.
Because multicast frames are not retransmitted at the MAC layer, clients at the edge of the cell might fail to receive them successfully. If reliable reception is a goal, multicast frames should be transmitted at a low data rate, by disabling the higher mandatory data rates. If support for high data rate multicast frames is required, it might be useful to shrink the cell size and disable all lower data rates, or to use Media Stream.
Depending on your requirements, you can take the following actions:
-
If you need to transmit multicast data with the greatest reliability and if there is no need for great multicast bandwidth, then configure a single basic rate, that is low enough to reach the edges of the wireless cells.
-
If you need to transmit multicast data at a certain data rate in order to achieve a certain throughput, you can configure that rate as the highest basic rate. You can also set a lower basic rate for coverage of nonmulticast clients.
-
Configure Media Stream.
-
-
Multicast mode does not operate across intersubnet mobility events such as guest tunneling. It does, however, operate across Layer 3 roams.
-
For CAPWAP, the controller drops multicast packets sent to UDP control and data ports 5246 and 5247, respectively. Therefore, you may want to consider not using these port numbers with the multicast applications on your network. We recommend that you do not use any Multicast UDP ports listed in https://www.cisco.com/c/en/us/support/docs/wireless/5500-series-wireless-controllers/113344-cuwn-ppm.html#anc8 as being UDP ports used by the controller.
-
We recommend that any multicast applications on your network not use the multicast address configured as the CAPWAP multicast group address on the controller.
-
We recommend that you do not use Broadcast-Unicast or Multicast-Unicast mode on controller setup where there are more than 50 APs joined.
-
While using Local and FlexConnect AP mode the controller's multicast support differs for different platforms.
The parameters that affect Multicast forwarding are:
-
Controller platform.
-
Global AP multicast mode configuration at controller.
-
Mode of the AP—Local, FlexConnect central switching.
-
For Local switching, it does not send/receive the packet to/from controller, so it does not matter which Multicast mode is configured on the controller.
Note
FlexConnect APs will join the CAPWAP multicast group only if they have centrally switched WLANs. Flex APs with only locally switched WLANs do not join the CAPWAP multicast group.
-
-
Effective with Release 8.2.100.0, it is not possible to download some of the older configurations from the controller because of the Multicast and IP address validations introduced in this release. The platform support for global multicast and multicast mode are listed in the following table.
Table 1. Platform Support for Global Multicast and Multicast Mode Platform
Global Multicast
Multicast Mode
Supported
Cisco 5520 and 8540 Controllers
Enabled
Unicast
No
Enabled
Multicast
Yes
Disabled
Unicast
No multicast support (config supported)
Disabled
Multicast
No multicast support (config supported)
Cisco vWLC
Multicast is not supported; only Unicast mode is supported.
Cisco 3504 Controller
Enabled
Unicast
Yes
Enabled
Multicast
Yes
Disabled
Unicast
Yes
Disabled
Multicast
No
-
For central switching downstream multicast, AP switching traffic is based on the MGID-to-WLAN mapping (bit map).
Enabling Multicast Mode (GUI)
Procedure
Step 1 |
Choose Controller > Multicast to open the Multicast page. |
||
Step 2 |
Select the Enable Global Multicast Mode check box to configure sending multicast packets. The default value is disabled. |
||
Step 3 |
If you want to enable IGMP snooping, select the Enable IGMP Snooping check box. If you want to disable IGMP snooping, leave the check box unselected. The default value is disabled. |
||
Step 4 |
To set the IGMP timeout, enter a value between 30 and 7200 seconds in the IGMP Timeout text box. The controller sends three queries in one timeout value at an interval of timeout/ 3 to see if any clients exist for a particular multicast group. If the controller does not receive a response through an IGMP report from the client, the controller times out the client entry from the MGID table. When no clients are left for a particular multicast group, the controller waits for the IGMP timeout value to expire and then deletes the MGID entry from the controller. The controller always generates a general IGMP query (that is, to destination address 224.0.0.1) and sends it on all WLANs with an MGID value of 1. |
||
Step 5 |
Enter the IGMP Query Interval (seconds). |
||
Step 6 |
Select the Enable MLD Snooping check box to support IPv6 forwarding decisions.
|
||
Step 7 |
In the MLD Timeout text box, enter a value between 30 and 7200 seconds to set the MLD timeout. |
||
Step 8 |
Enter the MLD Query Interval (seconds). The valid range is between 15 and 2400 seconds. |
||
Step 9 |
Click Apply. |
||
Step 10 |
Click Save Configuration. |
Enabling Multicast Mode (CLI)
Procedure
Step 1 |
Enable or disable multicasting on the controller by entering this command: config network multicast global {enable | disable} The default value is disabled.
|
||
Step 2 |
Perform either of the following: |
||
Step 3 |
Enable or disable IGMP snooping by entering this command: config network multicast igmp snooping {enable | disable} The default value is disabled. |
||
Step 4 |
Set the IGMP timeout value by entering this command: config network multicast igmp timeout timeout You can enter a timeout value between 30 and 7200 seconds. The controller sends three queries in one timeout value at an interval of timeout /3 to see if any clients exist for a particular multicast group. If the controller does not receive a response through an IGMP report from the client, the controller times out the client entry from the MGID table. When no clients are left for a particular multicast group, the controller waits for the IGMP timeout value to expire and then deletes the MGID entry from the controller. The controller always generates a general IGMP query (that is, to destination address 224.0.0.1) and sends it on all WLANs with an MGID value of 1. |
||
Step 5 |
Enable or disable Layer 2 Multicast by entering this command: |
||
Step 6 |
Enable or disable MLD snooping by entering this command: config network multicast mld snooping {enable | disable} The default value is disabled.
|
||
Step 7 |
Set the MLD timeout value by entering this command: config network multicast mld timeout timeout Enter the MLD timeout value in seconds. The valid range is between 30 and 7200 seconds. |
||
Step 8 |
Set the MLD query interval by entering this command: config network multicast mld query interval interval Enter the MLD query interval value in seconds. The valid range is between 15 and 2400 seconds. |
||
Step 9 |
Save your changes by entering this command: |
Viewing Multicast Groups (GUI)
Procedure
Step 1 |
Choose Monitor > Multicast. The Multicast Groups page appears. This page shows all the multicast groups and their corresponding MGIDs. |
Step 2 |
Click the link for a specific MGID (such as MGID 550) to see a list of all the clients joined to the multicast group in that particular MGID. |
Viewing Multicast Groups (CLI)
Procedure
Step 1 |
See all the multicast groups and their corresponding MGIDs by entering this command: show network multicast mgid summary Information similar to the following appears:
|
Step 2 |
See all the clients joined to the multicast group in a specific MGID by entering this command: show network multicast mgid detail mgid_value where the mgid_value parameter is a number between 550 and 4095. Information similar to the following appears:
|
Viewing an Access Point’s Multicast Client Table (CLI)
To help troubleshoot roaming events, you can view an access point’s multicast client table from the controller by performing a remote debug of the access point.
Procedure
Step 1 |
Initiate a remote debug of the access point by entering this command: debug ap enable Cisco_AP |
Step 2 |
See all of the MGIDs on the access point and the number of clients per WLAN by entering this command: debug ap command “show capwap mcast mgid all” Cisco_AP |
Step 3 |
See all of the clients per MGID on the access point and the number of clients per WLAN by entering this command: debug ap command “show capwap mcast mgid id mgid_value” Cisco_AP |