Settings that can improve Multicast on a Wireless Network

This is a two-part blog; this blog will go over settings that will improve multicast on your network. The next blog “Multicast on a Cisco Wireless Network” will go over more troubleshooting on a Cisco Network.

I work for a wireless communications vendor that uses multicast as an integral part of the product. There are certain settings on the wireless/wired network that when implemented will improve multicast.

The issues and settings we will discuss in the blog are; enabling multicast on the router and VLANs, Which VLANs do you enable PIM on, the purpose of DTIM and Beacon settings, basic and mandatory data rates, issues using TKIP and AES on the same SSID, Issues with Rendezvous Points (RP), IGMP snooping on switches, roaming issues with multicast and lastly issues with multicast buffers.

 

Enabling Multicast on the Router and VLANs

To enable multicast routing on your routers and VLANs you will need two commands. The first command you need to issue on your router (or layer 3 switches) is ip multicast-routing. The second command is the pim command (Protocol Independent Multicast), which enables multicast routing on your VLANs. You can set this command as dense-mode, sparse-mode or sparse-dense-mode. Dense mode is good to use if you have a small network, but the PIM sparse-dense-mode will allow the router to use both sparse-mode and dense-mode. The differences between sparse-mode and dense-mode center around Rendezvous Points and how multicast traffic and multicast routes are updated in the network. Most networks I work with use sparse-dense-mode. The command pim sparse-dense mode needs to be issued on all the VLANs where you want multicast traffic to flow.

 

Which VLANs do you enable PIM on?

This is the million-dollar question that can cause a lot of confusion. The VLANs you need to enable multicast on using the pim sparse-dense mode are the management VLAN, AP management VLAN (if different from the management VLAN), AP VLAN (if different from the management VLAN) and all the VLANs of the sending and receiving devices. The management VLANs are very important since the controller sends multicast packets to the APs using either the management VLAN or the AP Management VLAN.

If the multicast packets are flowing over the core, make sure the VLAN of the EtherChannel/Port Channel have PIM enabled on them if they are different from the management VLAN. I have seen issues where one EtherChannel had PIM enabled the other EtherChannel did not. This caused one multicast session to work and the next multicast session to fail.

 

 

 

The purpose of DTIM and Beacon settings

If you are using multicast to deliver voice packets you must set the DTIM to 1 and the beacons to 100ms. These settings tell the AP how often to set either a Traffic Indication Map (TIM) information element or a Delivery Traffic Indication Map (DTIM) information element inside the beacon. There are no TIM or DTIM beacons per se. There are only Information Elements inside the beacon (but for ease of use I will use terms TIM beacons and DTIM beacons). The TIM beacon will tell the client if the AP has unicast packets buffered for that client. The DTIM beacons will tell the clients they have multicast packets about to be delivered (as well as unicast packets buffered). If you set the DTIM to a higher value to either 2 or 3 then the AP will only deliver the multicast packets to the clients every 200ms or 300ms. Most VOIP clients will have between a 90ms and 150ms buffer. If the client gets multicast packets every 200 or 300ms then, the user will hear choppy audio.

 

Some device manufacturers want you to set the DTIM to the higher value, giving the devices more time to sleep. If the devices know the DTIM will only come every 200, 300 msec or more then the client device can sleep that much longer. This saves battery life and is somewhat of a valid concern but when Voice is being delivered over multicast packets the DTIM needs to be set to 1 or the user will hear choppy audio. I said this is somewhat of a valid concern but the fact of the matter it is not mandatory that the client wakes up every DTIM. Before adjusting your DTIM check with your device manufacturer to see if the device wakes up for every DTIM, you might be presently surprised to find the devices don’t wake up every beacon. Some devices will stay asleep longer than the DTIM. You can test this by pinging the device. While the device is idle ping it. You may find the device only responds every 500msec or so (or maybe longer). You can then ping the device while on an active call and see how often it responds and then compare the two values.

 

 

Basic and Mandatory Data rates

Cisco recommends using 2 basic data rates 12Mbps and 24Mbps. When you have two basic data rates set, management traffic will go out at the lower data rate, but Cisco will send multicast traffic at the higher data rate. This can cause issues for clients that have rate shifted down to 12Mps or lower. If the AP is sending multicast traffic out at 24 Mbps and the client is only able to receive at 12 Mbps your client may miss multicast packets. This will be very difficult to troubleshoot since some devices will get the multicast packets and others will not receive them. Trying to replicate the issue would prove difficult. I would always recommend setting only one Basic Data rate to help offset this issue.

 

 

Issues with using TKIP and AES on the same SSID

I have seen issues with multicast where TKIP and AES are enabled on the same SSID. When you have both enabled on the same SSID the AP must send multicast packets out using TKIP. If your clients are using AES they will have issues decrypting the multicast packets. Hopefully, everyone is using AES instead of TKIP (especially since TKIP has been deprecated) but if you need TKIP then it is better to have only one encryption per SSID. Of course, I strongly recommend only using AES.

 

 

Issues with Rendezvous point (RP)

There are two ways you can use Rendezvous points. You can assign a router as a Rendezvous point or you can let the network assign one for you. You can program multiple RPs on your network, but this may cause issues. When a client sends a join message routers in the path will create a (*,G) entry on the interface so the router knows what interface has clients that have subscribed to this multicast address. These join messages will eventually make it to the RP. When the RP gets this join message, it will build a path back to each client/network segment.

If you have multiple RPs you may find an issue where one client may get the multicast traffic and one client will not. This happens if two devices are on different VLANs and each device sends the join message to a different RP. In this case, one device or network segment will get the multicast traffic and one will not. Having multiple RPs might be by design but if you have multiple RPs you should ensure that the RPs share information of all related VLANs.

 

 

IGMP snooping on switches

When IGMP snooping is enabled on a switch, the switch can send the multicast packets out the right interfaces. When a switch sees a normal packet, it will look up the MAC address in its CAM table, if the switch has the MAC address of the client it can forward these packets the right interface. If the MAC address is not in the CAM table, it will flood the packet out all interfaces. The same is true of the multicast packets if the switch has IGMP snooping enabled. The switch will keep track of all the join messages sent by clients/APs. The switch then records what interfaces need the multicast packets. When a multicast packet is sent to the switch it looks in its table and sends the traffic only to those interfaces that need the packets. This cuts down on multicast packets flooding the network. If the switch does not have information on a multicast address, then the switch will send the packets out on all ports.

 

Roaming issues with Multicast

When the clients roam from AP to AP the controller will request the device to send a new join message, so the controller, AP, router, and the network knows the client has moved APs. If your clients fail to send a new join message, the controller will not update its MGID table and the new AP that your client is connected to may drop multicast traffic because the AP will not know there are any clients who have subscribed to these multicast groups.

This can be a real issue in an Autonomous network or even cloud based where the client doesn’t send a join message on a roam and there is no controller to request a new join message. If your client doesn’t send a new join message you will lose Multicast session as you roam. The fix this I would contact the device manufacture to see if there is a firmware update that will fix this issue.

 

 

Issues with Multicast Buffer

The multicast buffer is shared across all BSSIDs on the AP. If there are a high number of SSIDs on your network, you may experience issues where the buffers fill up and the AP starts dumping multicasts packets. This may cause choppy audio on your multicast sessions. If your SSIDs have a higher DTIM value, the APs/Controllers will need to store packets for a longer period.  When you are experiencing issues with multicast traffic you may need to increase your multicast buffer size and then limit which WLANs can use this buffer. Multicast traffic is often crucial to voice clients and other clients/WLANs may never use multicast packets. If you limit which WLANs can use the multicast buffer there will be available space for applications that have a critical need for multicast.

 

It is important to note that the AP can only buffer multicast packets for the length of the DTIM value. When this value has expired the AP will inform the clients and immediately send the multicast packets whether the client is listening or not. This, of course, is different from the way unicast frames are delivered. If the AP has unicast frames for the client, the AP will set the clients AID in the Partial Virtual Bitmap. The AP will buffer these frames until the client wakes up and requests these frames.

 

 

Links to Multicast articles, videos, and blogs

 

https://www.youtube.com/watch?v=Gjt2L9jAYNA From Kevin Wallace   Cisco Multicast Routing for CCNA, CCNP, and CCIE candidates

 

https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/7-4/vocera_config_guide/vocera_config_guide/vocera_config_guide_chapter_01011.pdf Cisco guide on how to configure multicast for Vocera

 

https://supportforums.cisco.com/document/56511/multicast-and-wireless-lan-controller-wlc This is from Stephen Rodriquez 7 years ago but still good info in there.

 

 

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus1000/sw/4_0/troubleshooting/configuration/guide/n1000v_troubleshooting/trouble_14mcast.html

 

https://community.cisco.com/t5/wireless-mobility-documents/understanding-multicast-in-unified-wireless-networks/ta-p/3125021  This a power point Understanding Multicast in Unified Wireless Networks by Jeff Keown Cisco Wireless TAC

 

http://www.labminutes.com/wl0025_wlc_multicast_videostream_1   excellent video on setting up your controller for multicast.

 

 

Thank you for reading this blog. I hope reading this blog gives you more insight into multicast and the settings needed on your network. Please leave comments and continue this discussion on Twitter and Slack. If you haven’t followed me on Twitter I am at @wifi_nc. Stay tuned for my next blog in this series called “Multicast on a Cisco Wireless Network”. That blog will go into more details and troubleshooting multicast on Cisco Networks.

 

 

CAC (Call Admission Control)

Is CAC fair to your clients that don’t support it?

I support a voice product that does not support CAC. Is it right for me to ask the Wireless Network Administrator to disable it because my device doesn’t support it? Is CAC fair? Why does it supersede WMM? I will attempt to answer some of these questions in this blog.

Cisco uses CAC (Call Admission Control) that enables access points to maintain controlled quality of service (QoS). CAC is also tasked with the ability to ensure there is a limited number of voice clients per AP.

 

How does CAC maintain control of QoS?

The AP will send a beacon frame out on each SSID, usually every 100ms or so. In these beacon frames, the AP will tell what features it will support for that particular SSID. Inside the beacon frames under the Vendor Tag: Microsoft: WMM parameters the AP tells the clients which WMM Access Category that CAC has been enabled on (see example 1 below). When a device associates to the AP (and the device doesn’t support CAC) the device will choose the highest level of WMM that doesn’t have CAC enabled on (see example 2 below). If CAC is enabled on AC_Voice, but not on AC_Video, AC_Best Effort or AC_Background then the client will choose AC_Video even if the client is expecting to use Voice grade WMM or even when the SSID and VLAN are set up to use Platinum QoS.

 

Why is this an issue?

WIFI is a contention-based shared media. The AP and clients need to know that no one else will be transmitting at the same time they are. If another device does transmit at the same time it will cause collisions and the packets will have to be resent. In order to avoid collisions, the clients and APs uses Physical Carrier Sense and Virtual Carrier Sense. A device or AP will use both Physical and Virtual Carrier Sense while trying to access the wireless medium.

Physical Carrier sense happens when the station listens to the wireless medium to see if there is RF energy on the medium. If there is, the device will then know that the medium is being used. This is called Clear Channel Assessment (CCA). Virtual Carrier sense is where the station reads the Duration/ID field and sets its own NAV (Network Allocation Vector) timer. While the NAV is still active the station will not transmit. When the NAV timer goes to 0 the station waits DIFS (Disturbed Coordination Function Interframe space), which is set per PHY that you are using.  When the DIFS expires the station will choose a random number from the Contention Window (CW) range and multiply it by the slot time of the PHY you are using.  After all the timers have ended the device will do another CCA and then transmit.

The Access Category gives the client a range called the Contention Window (CW). This range is called the CWmin and CWmax values (see chart below). The device will choose a random number in the CW range and will multiply this with a set number based on the PHY. The client will wait this random amount of time and then will do another Clear Channel Assessment (CCA) to make sure no one else is transmitting at that time. Each client will choose a different value in the Min/Max times. This gives the AC categories with the lower CW values a better chance to transmit, but it is only a probabilistic chance. The lower Categories will get a chance to transmit. When the lower priority clients hear a transmission in the middle of a count/hold sequence they will pause the count/hold, look into the Duration/ID field and sets its NAV timer. When the NAV timer expires and the air is clear the client will resume the hold sequence from where it left off. So eventually it will transmit even while the higher category might be counting down.

 

The CW values per AC Categories are below.

Category                    CWmin           CWmax

AC_Voice                            3                             7

AC_Video                            7                             15

AC_Background               15                           1023

AC_Best Effort                  15                           1023

 

When a client is sending voice packets the client expects to send these packets using the Platinum level of QoS to avoid latency or jitter. If the client does not support CAC and it has to choose the next WMM parameter that doesn’t have CAC support (in this case it was Video) the client will possibly get a much higher CWmin and CWmax time then it should. If the controller set up CAC on Video then the client would choose Background. This would give the client an even worse CWmin and CWmax range to work with. This not only affects upstream, but the packets are labeled as video which would further delay the packets through the wired network.

 

On the return traffic, the network may further strip the QoS level down to Best Effort. In a busy network, this can be problematic for voice clients.

 

Given all of this, is it right for me to ask the wireless guy at the hospital to change the CAC settings because my device does not support CAC? Or should I push back on my own engineering team to fix our client to support CAC? Or should I do both? I can see the wireless guys ponder this as I ask them to remove CAC. Most people in the wireless field are very accommodating especially when you show them the results. Our device is not seen as just another device needing access. This device is usually pushed by C Suite and the nurses on the floor. Wireless guys realize that our product if given the best environment to work in, will help caregivers communicate more effectively and will ultimately help patients. So, if you see me coming, be forewarned I don’t like CAC, DTIMs set to 2 or higher, FRA or RRM (with no limits set). I might ask for things others don’t, but when I do I will back it up with facts and will always be appreciative of your willingness to work with us.

 

 

Example 1 Beacon showing Voice is using ACM (CAC)

 

 

 

 

 

 

 

 

 

Example 2: Data packets showing Client chose QoS of Video

 

 

 

 

 

 

 

 

 

 

 

Example 3: Screenshot from the Wireless Controller Config showing the WLAN has the QoS set to Platinum

 

(Cisco Controller) >show wlan x

WLAN Identifier……………………………. x

Profile Name………………………………. xxxxxxxxx

Network Name (SSID)………………………… xxxxxxxx

Status……………………………………. Disabled

MAC Filtering……………………………… Disabled

Broadcast SSID…………………………….. Disabled

AAA Policy Override………………………… Enabled

************************Data Removed*********************

Quality of Service…………………………. Platinum

 

 

 

Example 4: Screenshot from the Wireless Controller showing CAC and ACM set on the Voice AC

 

 

Call Admission Control (CAC) configuration

Voice AC:

Voice AC – Admission control (ACM)………… Enabled

Voice Stream-Size……………………….. 84000

Voice Max-Streams……………………….. 2

Voice max RF bandwidth…………………… 75

Voice reserved roaming bandwidth………….. 6

Voice CAC Method ……………………….. Load-Based

Voice tspec inactivity timeout……………. Disabled

CAC SIP-Voice configuration

SIP based CAC ………………………….. Disabled

SIP Codec Type …………………………. CODEC_TYPE_G711

SIP call bandwidth ……………………… 64

SIP call bandwith sample-size ……………. 20

Video AC:

Video AC – Admission control (ACM)………… Disabled

Video max RF bandwidth…………………… Infinite

Video reserved roaming bandwidth………….. 0

Video load-based CAC mode………………… Disabled

Video CAC Method ……………………….. Static

CAC SIP-Video Configuration

SIP based CAC ………………………….. Disabled

Best-effort AC – Admission control (ACM)…… Disabled

Background AC – Admission control (ACM)……. Disabled

Maximum Number of Clients per AP Radio……….. 200