This document provides a configuration example on how to configure Wireless LAN Controllers (WLCs) and Lightweight Access Points (LAPs) for multicasting and communication with a multicast enabled wired network.
Ensure that you meet these requirements before you attempt this configuration:
Basic knowledge of the configuration of APs and Cisco WLCs.
Knowledge of how to configure basic routing and multicasting in a wired network.
The information in this document is based on these software and hardware versions:
Cisco 3504 WLC that runs Firmware Release 8.5
Cisco 3702 Series LAPs
Microsoft Windows 10 Wireless Client with Intel(R) Dual Band Wireless-AC 8265 adapter
Cisco 6500 switch that runs Cisco IOS® Software Release 12.2(18)
Two Cisco 3650 Series Switches that run Cisco IOS Software Release 16.3.7
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Multicast in Wireless LAN Controllers (WLCs)
If your network supports packet multicasting, you can configure the multicast method that the controller uses in order to transport the multicast packets over CAPWAP to all or several access points at the same time. The controller performs multicasting in two modes:
Unicast mode - In this mode, the controller unicasts every multicast packet to every AP 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.
When you use different VLAN/Subnet for AP and WLC then Multicast routing is mandatory on the wired side to support forwarding the downlink CAPWAP Multicast packet from WLC to AP.
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.
Broadcast Behavior in Different WLC
By default, the WLC will not forward any broadcast packets (such as Upnp traffic) unless broadcast forwarding is enabled. Issue this command from the WLC CLI in order to enable broadcast:
config network broadcast enable
Or enable it with the GUI:
Broadcast uses the multicast mode that is configured on the WLC, even if multicast is not turned on. This is because you cannot set the IP address or the mode unless you enable multicast in the GUI. Therefore, if multicast mode is unicast and broadcast is turned on, this is the mode broadcast uses (broadcast traffic is replicated at the WLC and unicast to each AP). If multicast mode is set to multicast with a multicast address, then broadcast uses this mode (each broadcast packet is sent via the multicast group to the APs).
Note:Until Release 7.5, the port number used for CAPWAP multicast was 12224. From Release 7.6 onwards, the port number used for CAPWAP is changed to 5247.
Multicast with AAA override is supported from Wireless LAN Controller release 4.2 and later. You have to enable IGMP snooping on the controller to make multicast work with AAA override.
IGMP Snooping on WLC
IGMP snooping is supported on WLC to better direct multicast packets. When this feature is enabled, the controller gathers IGMP reports from the clients, processes the reports, creates unique multicast group IDs (MGIDs) from the IGMP reports after checking 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 AP with the client MAC address. When the controller receives multicast traffic for a particular multicast group, it forwards it to all the APs. However, only those APs 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.
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. In order 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.
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 is 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.
Notes: - The MGIDs are controller specific. The same multicast group packets that come from the same VLAN in two different controllers can be mapped to two different MGIDs. - If Layer 2 multicast is enabled, a single MGID is assigned to all the multicast addresses that come from an interface. - The maximum number of multicast groups supported per VLAN for a controller is 100.
Wireless Multicast Roaming
A major challenge for a multicast client in a wireless environment is to maintain its multicast group membership when moved about the WLAN. Drops in the wireless connection that move from AP-to-AP can cause a disruption in the multicast application of a client. Internet Group Management Protocol (IGMP) plays an important role in the maintenance of dynamic group membership information.
A basic comprehension of IGMP is important to understand what happens to the multicast session of a client when it roams about the network. In a Layer 2 roaming case, sessions are maintained simply because the foreign AP, if configured properly, already belongs to the multicast group, and traffic is not tunneled to a different anchor point on the network. Layer 3 roaming environments are a little more complex in this manner, and, dependent upon what tunneling mode you have configured on your controllers, the IGMP messages sent from a wireless client can be affected. The default mobility tunneling mode on a controller is asymmetrical. This means that return traffic to the client is sent to the anchor WLC and then forwarded to the foreign WLC, where the associated client connection resides. Outbound packets are forwarded out the foreign WLC interface. In symmetrical mobility tunneling mode, both inbound and outbound traffic are tunneled to the anchor controller.
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.
Guidelines for Using Multicast Mode
The Cisco Wireless network solution uses some IP address ranges for specific purposes, and you should keep these ranges in mind when you configure a multicast group:
22.214.171.124 through 126.96.36.199 - Reserved link local addresses
188.8.131.52 through 184.108.40.206 - Globally scoped addresses
220.127.116.11 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.
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.
CAPWAP 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 these 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 might want to consider not using these port numbers with the multicast applications on your network. Cisco recommends that you do not use any Multicast UDP ports listed in this WLC protocols table as being UDP ports used by the controller.
Cisco recommends that any multicast applications on your network not use the multicast address configured as the CAPWAP multicast group address on the controller.
For multicast to work on Cisco 2504 WLC, you have to configure the multicast IP address.
Multicast mode is not supported on Cisco Flex 7500 Series WLCs.
IGMP and MLD snooping is not supported on Cisco Flex 7510 WLCs.
For Cisco 8510 WLCs:
You must enable multicast-unicast if IPv6 support is required on FlexConnect APs with central switching clients.
You can change from multicast mode to multicast-unicast mode only if global multicast is disabled, which means IGMP or MLD snooping is not supported.
FlexConnect APs do not associate with a multicast-mulitcast group.
IGMP or MLD snooping is not supported on FlexConnect APs. IGMP and MLD snooping is allowed only for local mode APs in multicast-multicast mode.
Because VideoStream requires IGMP or MLD snooping, the VideoStream feature works only on local mode APs if multicast-multicast mode and snooping are enabled.
Cisco Mobility Express Controller does not support AP multicast mode.
Cisco recommends 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:
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 18.104.22.168, 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
Cisco 5520 , 8510, and 8540 Controllers
No multicast support (config supported)
No mulitcast support (config supported)
Cisco Flex 7510 Controller
Global Multicast cannot be enabled. Only Unicast mode is supported. Also, AP-Multicast mode cannot be changed to Multicast-Multicast.
Cisco 2504 Controller
Only Multicast mode is supported.
Multicast is not supported; only Unicast mode is supported.
Cisco 3504 Controller and Cisco 5508 Controller
All devices and setup are shown in the diagram:
The devices need to be configured for basic IP connectivity and enable multicasting in the network. Therefore, users can send and receive multicast traffic from the wired side to the wireless side and vice versa.
This document uses these IP addresses for the WLC, AP and wireless clients:
WLC Management Interface IP address: 10.63.84.48/23
LAP IP address: 172.16.16.0/23
Wireless Client C1 IP address: 192.168.47.17/24
Wired Client W1 IP address: 192.168.48.11/24 CAPWAP multicast IP address : 22.214.171.124 Stream multicast address : 126.96.36.199
In order to configure the devices for this setup, these need to be performed:
Before you configure multicasting on WLCs, you must configure the WLC for basic operation and register the APs to the WLC. This document assumes that the WLC is configured for basic operation and that the LAPs are registered to the WLC. If you are a new user trying to set up the WLC for basic operation with LAPs, refer to Lightweight AP (LAP) Registration to a Wireless LAN Controller (WLC).
Once the LAPs are registered to the WLC, complete these tasks in order to configure the LAPs and WLC for this setup:
The next step is to configure the WLC for multicasting. Complete these steps:
Choose Controller > Multicast to open the Multicast page.
Select the Enable Global Multicast Mode check box to configure sending multicast packets. The default value is disabled.
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:
Choose Controller > General to and for AP Multicast Mode from the drop-down menu choose "Multicast" and configure the multicast IP address. In this example, we are using 188.8.131.52 :
Configure Multicast Mode via the CLI
Issue these commands in order to enable multicast through the CLI:
From the command line, issue the config network multicast global enable command.
From the command line, issue the config network multicast mode multicast <multicast-group-ip-address> command.
For the example in this document, the commands are:
config network multicast global enableconfig network multicast mode multicast 184.108.40.206
After the administrator enables multicast (multicast mode is disabled by default) and configures CAPWAP multicast group, the new multicast algorithm works in one of these ways:
When the source of the multicast group is on the wired LAN:
One Multicast is enabled and CAPWAP multicast group is configured the AP issues an IGMP request in order to join the controller CAPWAP multicast group. This triggers the normal setup for the multicast state in the multicast-enabled routers, between the controller and APs. The source IP address for the multicast group is the controller management interface IP address.
When the controller receives a multicast packet from any of the client VLANs on the first hop router, it transmits the packet to the CAPWAP multicast group via the management interface at the lowest QoS level. The QoS bits for the CAPWAP multicast packet are hard-coded at the lowest level and cannot be changed by the user.
The multicast-enabled network delivers the CAPWAP multicast packet to each of the APs that have joined the CAPWAP multicast group. The multicast-enabled network uses the normal multicast mechanisms in the routers to replicate the packet along the way, as needed, so that the multicast packet reaches all APs. This relieves the controller from the replication of multicast packets.
APs can receive other multicast packets, but process only the multicast packets that come from the controller to which they are currently joined. Any other copies are discarded. If more than one WLAN SSID is associated to the VLAN from where the original multicast packet was sent, the AP transmits the multicast packet over each WLAN SSID (following to the WLAN bitmap in the CAPWAP header). In addition, if that WLAN SSID is on both radios (802.11g and 802.11a), both radios transmit the multicast packet on the WLAN SSID if there are clients associated with it, even if those clients did not request the multicast traffic.
When the source of the multicast group is a wireless client:
The multicast packet is unicast (CAPWAP-encapsulated) from the AP to the controller, similar to standard wireless client traffic.
The controller makes two copies of the multicast packet. One copy is sent out the VLAN associated with the WLAN SSID on which it arrived. This enables receivers on the wired LAN to receive the multicast stream and the router to learn about the new multicast group. The second copy of the packet is CAPWAP-encapsulated and is sent to the CAPWAP multicast group so that wireless clients can receive the multicast stream.
Configure the Wired Network for Multicasting
In order to configure the wired network for this setup, you need to configure the L3 Core switch for basic routing and enable multicast routing :
Any multicast protocol can be used in the wired network. This document uses PIM-DM as the multicast protocol. Refer to Cisco IOS IP Multicast Configuration Guide for detailed information on the different protocols that can be used for multicasting in a wired network .
Core Switch Configuration
!--- Enables IP Multicasting on the network.
interface Vlan16 description AP Management VLAN ip address 172.16.16.1 255.255.254.0 ip helper-address 10.63.84.5 ip pim dense-mode
!--- Enables PIM-Dense Mode Multicast Protocol on the interface. interface Vlan47 description Wireless Client ip address 192.168.47.1 255.255.255.0 ip helper-address 10.63.84.5 ip pim dense-mode
!--- Enables PIM-Dense Mode Multicast Protocol on the interface.
interface Vlan48 description Wired Client ip address 192.168.48.1 255.255.255.0 ip helper-address 10.63.84.5 ip pim dense-mode
!--- Enables PIM-Dense Mode Multicast Protocol on the interface.
interface Vlan84 description Wireless Management VLAN ip address 10.63.84.1 255.255.254.0 ip pim dense-mode
No configuration is needed on L2 access switch since IGMP snooping is enabled by default on Cisco Switches.
Verify and Troubleshoot
Use this section to confirm that your configuration works properly.
In order to verify the configuration, you need to send multicast traffic from the source W1 and check if multicast traffic flows through the wired network and reaches the wired and wireless group members (C1).
Perform this task in order to test if IP multicast is configured correctly in your network.
Check multicast routing on the Core switch and IGMP memberships wth the commands show ip mroute and show ip igmp membership. The output from the previous example is shown here.
CORE1-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, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel Y - Joined MDT-data group, y - Sending to MDT-data group Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 220.127.116.11), 01:21:13/stopped, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Vlan16, Forward/Dense, 00:33:10/00:00:00
(10.63.84.48, 18.104.22.168), 00:33:46/00:02:51, flags: T Incoming interface: Vlan84, RPF nbr 0.0.0.0, RPF-MFD Outgoing interface list: Vlan16, Forward/Dense, 00:33:10/00:00:00, H
CORE1-R1#show ip igmp membership Flags: A - aggregate, T - tracked L - Local, S - static, V - virtual, R - Reported through v3 I - v3lite, U - Urd, M - SSM (S,G) channel 1,2,3 - The version of IGMP, the group is in
hannel/Group-Flags: / - Filtering entry (Exclude mode (S,G), Include mode (G)) Reporter: <mac-or-ip-address> - last reporter if group is not explicitly tracked <n>/<m> - <n> reporter in include mode, <m> reporter in exclude
You can also use the command show ip mroute count in order to ensure that multicast routing works properly:
CORE1-R1#show ip mroute count IP Multicast Statistics 10 routes using 5448 bytes of memory 6 groups, 0.66 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)