This guide last modified:
2024-11-06 06:02.
.
This section explains the recommended network settings for multicast.
Vocera has a fixed address range configured for multicast groups. The Class D multicast address range for Vocera is 230.230.0.1 to 230.230.15.254 (230.230.0.0/20) (4096 addresses).
You can configure the multicast address range by adding the following properties to the \vocera\server\Properties.txt file on Vocera Voice Server and \opt\vocera\server\Properties.txt file on Vocera Platform.
Add or modify the following properties (case sensitive):
IPBaseMulticastAddr = 230.230.0.0
IPMulticastRange = 4096
IPBaseMulticastAddr—Specifies the start of the range. The default start of the range is 230.230.0.0.
IPMulticastRange—Specifies the number of addresses in the range. The default address in the range is 4096.
This pool of addresses should be unique on the network. Do not confuse this address space with the CISCO multicast address found in the CISCO WLAN Controller, which is used for the Controller to send multicast packets to the APs and it must be unique as well.
If the network uses multicast to deliver voice packets, it must set the DTIM to 1 and the beacons to 100ms. These settings informs the AP how often to set either a Traffic Indication Map (TIM) information element or a DTIM information element inside the beacon. There are no TIM or DTIM beacons themselves. There are only Information Elements inside the beacon. However, for ease of understanding, the terms TIM beacons and DTIM beacons are used. The TIM beacon informs the client if the AP has unicast packets buffered for that client. The DTIM beacons inform the clients that they have multicast and unicast (buffered) packets about to be delivered. If DTIM is set to a higher value to either 2 or 3, then the AP delivers only the multicast packets to the clients every 200ms or 300ms. Most VOIP clients have a buffer between 90ms and 150ms. If the client gets multicast packets every 200 or 300ms, then the user experiences choppy audio.
Multicast traffic must be sent out when the DTIM value has expired as the APs cannot buffer multicast messages longer than the DTIM value. When the DTIM value has expired, the packets are sent out regardless of whether the clients are on the network or not. Multicast packets are not acknowledged, even on the wireless side, so they cannot be resent.
Some device manufacturers prefer the devices DTIM to be set to a higher value, giving the devices more time to sleep. If the devices know the DTIM will only be active every 200 - 300 ms or more, then the client device can sleep that much longer. This saves battery life but not as much as many users expect.
When a Vocera device sleeps, it wakes up every 500 ms or so (when the device is not in an active call). This means it could miss up to five multicast packets. But since this happens during call set up, the delay is never heard. The initial packets the server sends to the clients are unicast packets notifying the badges to join the multicast session. When the badge wakes up, the AP sends the unicast packet to the device and the device joins the multicast session.
PIM needs to be enabled or set on all VLANs where Vocera multicast traffic traverses. The following are the VLANs that need PIM enabled:
Management VLAN
AP management VLAN (if different from the management VLAN)
AP VLAN
VLAN of the sending device
VLAN of the receiving device
If Telephony broadcasting is needed, PIM must be set up on the server VLAN as well.
The management VLAN is very important and is often overlooked since the controller sends the multicast packets to the APs using it and not the client VLAN. The Management VLAN can be referred to differently depending on the WLAN vendor, such as management VLAN, AP management VLAN, or the AP VLAN, and can even be split into separate management VLANs for Inter-Controller and Controller-to-AP traffic.
If the multicast packets flow over the core, ensure that the VLAN of the trunks have PIM enabled on them (if they are different from the management VLAN). Vocera has encountered problem where one trunk VLAN had PIM enabled and the other trunk VLAN did not. This causes one multicast session to work and the next multicast session to fail.
You need to identify all the interfaces and VLANs where traffic traverses for enabling PIM. Vocera always recommends opening a case with CISCO (or the wireless vendor) to help find all of the VLANs and interfaces where the multicast traffic may traverse.
IGMP and PIM work hand in hand. IGMP "Join Messages" are sent out from the client and source devices. These messages are sent as broadcasts which only go as far as the local router. The local router/layer 3 switch and all router/layer 3 switch in the path use PIM messages and entries *,G and S,G to keep track of who has joined the multicast session and who is the source of the multicast session.
CISCO recommends using two basic data rates 12 mbps and 24 mbps. When you have two basic data rates set, management traffic goes out at the lower data rate, but CISCO sends multicast traffic at the higher data rate. This can cause issues for clients that have rate shifted down to 12 mbps 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 becomes very difficult to troubleshoot since some devices get the multicast packets and others do not receive them. Trying to replicate the issue would be difficult. Vocera always recommends setting only one Basic Data rate at 12 mbps and leaving all other supported.
The main purpose of a Rendezvous Points (RP) is to build trees from the source to the RP and down to the clients, so the network knows where to send multicast traffic.
There are two ways you can use RP. You can assign a router as an RP, or you can use Auto RP. When assigning an RP manually, all routers need to be updated manually with the IP address of the new RP. When enabling Auto RP, an RP is elected among the network routers. This new RP uses PIM messages to update all routers that it is the new RP. When a client sends an IGMP "Join Message" to its local router (LHR), the router creates a (*,G) entry on the interface, so the router knows what interface has clients that have subscribed to this multicast address. The local router (LHR) sends PIM messages to the RP. When the RP gets these PIM messages, it builds a path back to each client/network segment.
Issues with Multiple RPs
If you have multiple RPs on your network, you may encounter an issue where one client receives the multicast traffic while the other does not. This can happen if two devices are on different VLANs, and they send the "Join Message" to a different RP, leading to one device or network segment receiving the multicast traffic and the other not receiving it. Although having multiple RPs may be intentional, if the network has multiple RPs, they should share information of all related VLANs.
The multicast buffer is shared across all BSSIDs on the AP. If there are high number of SSIDs on the network, it may experience issues where the buffers fill up and the AP starts dumping multicasts packets. This may cause choppy audio on the multicast sessions. If the SSIDs have a higher DTIM value, the APs/Controllers need to store packets for a longer period. When experiencing issues with multicast traffic being dropped, increasing the multicast buffer size, and then limiting the WLANs that can use this buffer may fix this issue. Multicast traffic is often crucial to the voice clients and other clients/WLANs may never use multicast packets. If a limit is placed on specific WLANs that can use the multicast buffer, it leaves 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 informs the clients and immediately sends 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 sets the client's AID in the Partial Virtual Bitmap. The AP buffers these frames until the client wakes up and requests these frames.
When the clients roam from AP to AP, the controller requests the device to send a new "Join Message", so that the controller, AP, router, and the network knows the client has moved APs. If the clients fail to send a new "Join Message", the controller does not update its MGID table. The new AP that the client has roamed to may drop multicast traffic since the AP does not have an entry in its MGID table. This can be an issue in an Autonomous network or even a cloud-based where the client does not send a join message on a roam and there is no controller to request a new join message.
Vocera has encountered problem with multicast where Temporal Key Integrity Protocol (TKIP) and Advanced Encryption Standard (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 use AES, they face issues in decrypting the multicast packets. Everyone should be using AES instead of TKIP (especially since TKIP has been deprecated). But if you need TKIP, then it would be better to stand up another SSID and have only one encryption per SSID.
This guide last modified:
2024-11-06 06:02.
.