Troubleshooting 792x Voice Quality Issues (Cisco Wireless LAN Controllers) Part 2

Network Busy

When you try to place a call, the phone might display a message indicating that the network is busy. Network Busy messages are generated by two conditions:

■ Physical settings.

■ CAC is enabled, but no bandwidth is available.

By default, the 792x phones use 12 Mb as the PHY rate in the TSPEC. If the 12 Mb data rate is disabled and CAC is enabled on the controller, the phone cannot place a call. A mismatch here between the phone and controller configuration results in an ADDTS refusal or timeout. You can change the PHY rate on the phone, but Cisco does not recommend it. The controller/AP only supports PHY rates of 6, 11,12, and 24 with CAC enabled. Although higher PHY rates are possible, no gain in the number of simultaneous voice calls or voice quality occurs with data rates higher than 24 Mbps.

Note With the 1.3.3 firmware release, the phones are able to rate-shift to the next highest supported PHY rate. For example, if you had 12 Mbps disabled but 24 Mbps was enabled, the phone would still be able to place a call. Another example would be if you had only 802.11b radios; at that point, the phone could use 11 Mbps because that is the next highest supported PHY rate available. This feature is nice because you do not have to reconfigure every 792x phone if the 12MBps data rate is not available.

If the WLAN is not able to allocate enough bandwidth for the phone to complete the call, you receive a Network Busy message. To see the CAC information when a client is having issues, use debug cac all enable from the controller CLI. When you use the "all" parameter, you are enabling both cac events and cac packets.

In Example 11-6, you can see that the phone is not able to place a call because of an invalid TSPEC parameter on the controller. You can also see a PHY rate of 12 Mb.

Example 11-6 debug cac all enable Output

The max stream size on the controller should not be 0. You can correct an issue such as this using the following command from the controller CLI:

The stream size can be between 84000 and 92100, and the max-streams can be 1 to 5.

The cac voice stream-size command dictates the TSPEC size and the number of streams per call. This is a per-call setting that does not limit the number of calls per AP.

You can see the configured CAC for a particular 802.11 network on the controller using show 802.11 from the controller CLI, as shown in Example 11-7.

Example 11-7 show dot11 Command Output

The default Voice Stream-Size is 84000, and the default Max-Streams is set to 2. This means that the controller will accept a TSPEC from a phone that has up to 2 phone calls (RTP streams), and each call will have a mean data rate of 84000 Kbps or less.

Poor Audio When Roaming

If voice quality deteriorates while roaming, verify the following:

■ Check the RSSI on the destination AP to see if the signal strength is adequate. The next AP should have an RSSI value of -67 dBm or greater.

■ Check the site survey to determine if the channel overlap is adequate for the phone and the AP to hand off the call to the next AP before the signal is lost from the previous AP.

■ Check to see if noise or interference in the coverage area is too great.

■ Check that SNR levels are 25 db or higher for acceptable voice quality.

■ Verify that DHCP Required is disabled on the voice WLAN. The DHCP process causes delay and degrades the quality of the call.

■ Symmetric mobility tunneling should be enabled. Asymmetrical tunneling can cause jitter.

■ If performing inter-controller roaming, check that the controllers involved are mobility members of each other.

■ If you are using 802.1x, it is recommended that you use CCKM because 802.1x requires full reauthentication, which can introduce delay.

■ Use debug client, debug mobility handoff, and debug aaa all to see if mobility or authentication is an issue when the client roams.

Multicast Applications Fail

Features like PTT and MOH are multicast applications. The controllers have three multicast modes:

■ Multicast-Disabled: Multicast is off; default setting.

■ Multicast-Unicast: The controller replicates any multicast packets and sends them as unicasts to all registered APs.

■ Multicast-Multicast: The controller sends multicast traffic to a configured AP multicast group IP.

With the controller set to Multicast-Unicast mode, the controller replicates the multicast packet for every AP joined to it. This is extremely inefficient because all clients, whether they are part of the multicast group or not, receive the multicast traffic. Considering the overhead associated with this, Cisco does not recommend using Multicast-Unicast.

When using Multicast-Multicast on a controller-based wireless infrastructure, you must have multicast routing enabled on your wired network and multicast enabled on the controller.

The ip multicast-routing command should be enabled on all routers within your network between the controller(s) and their respective APs.

Router(config)#ip multicast-routing

Protocol Independent Multicast (PIM) must be enabled on the following VLANs on your network:

■ Controller Management VLAN: The VLAN the controller’s management interface resides in

■ AP VLAN: The VLAN the APs have their IP address in

■ Client VLAN: The VLAN the clients have their IP address in

Multicast routing needs to be enabled on the management interface VLAN of the controller because the controller uses that interface to send and receive multicast traffic. The APs are members of the multicast group you configure on the controller, so you need PIM on that VLAN. Again, the AP VLAN is the VLAN the APs have their IP address in. Lastly, the client VLAN needs to have PIM enabled so the clients can join their desired multicast group.

Enabling PIM allows Internet Group Management Protocol (IGMP) routing on the interface. The PIM mode determines how the router populates the multicast routing table. Using sparse-dense-mode is the easiest configuration because it does not require that you designate a rendezvous point (RP).

Make sure no network ACLs are blocking multicast traffic to or from these VLANs.

Also ensure that you have configured multicast on the controller. You configure the multicast mode you want to use and if using Multicast-Multicast, configure the IP address the APs will use for their multicast group.

Figure 11-19 shows a controller with Multicast-Multicast enabled.

Figure 11-19 Enabling Multicast

You should use a multicast address in the IANA administratively reserved private multicast domain range of 239.0.0.0-239.255.255.255. Do not use IPs in the 239.0.0.x and 239.128.0.x address range. Choosing an address outside these ranges prevents overlap with local MAC addresses and prevents multicast floods on the network.

Multicast-Multicast mode is true multicast. With Multicast-Multicast mode enabled, the controller encapsulates the received multicast packet using LWAPP/CAPWAP and forwards the packet to the multicast group address you configured. The controller always uses the management interface for sending multicast packets. Access points in the configured multicast group receive the packet and check to see if it has any clients that are a member of that multicast group. If so, the AP broadcasts the multicast traffic on the client basic service set identifier (BSSID). From the AP perspective, the multicast appears to be a broadcast to all clients within the same Basic Service Set (BSS).

Controller Multicast Delivery Evolution

Before the 3.2 release code, the controllers were capable only of Multicast-Unicast delivery. With the 3.2 release, Cisco introduced the Multicast-Multicast delivery method. This feature made multicast delivery to wireless clients much more efficient because packet replication only had to occur at a point in the network where it was necessary. Figure 11-20 illustrates the Multicast-Multicast traffic flow.

Figure 11-20 Multicast Traffic Flow

From Figure 11-20, you can see several steps in how the client IGMP join and multicast delivery takes place:

Step 1. Client 1 is associated to AP1 on WLAN1 and sends an IGMP join request that goes through the AP to the controller in the LWAPP/CAPWAP tunnel.

Step 2. The controller forwards the client join on the client VLAN through the upstream switch to the PIM-enabled router. The PIM router adds the IP address of Client 1 to the appropriate IGMP group address.

Step 3. The PIM-enabled router forwards the multicast packets destined for the IGMP group of Client 1 to the controller.

Step 4. The controller then forwards the packets to the AP multicast group address. Every AP receives the multicast traffic.

Step 5. If the AP is servicing WLAN1 and has any clients on that WLAN, it broadcasts the traffic on the appropriate BSSID regardless of whether any of those clients are actually members of the multicast group. Client 2 and Client 3 still receive the traffic but ignore it because they are not members of the IGMP group of Client 1.

When a wireless client wants to leave an IGMP group in pre-4.2 code, it sends an IGMP Leave. The controller bridges it through the upstream switch to the PIM-enabled router, and the router removes Client 1 from the IGMP group.

In code releases before 4.0.206.0, if multicast was enabled in any way, broadcast forwarding was also enabled. If IGMP snooping was enabled on the wired network, this could disrupt wireless multicast delivery. In 4.0.206.0 and higher, broadcast forwarding is no longer enabled by default.

Note The multicast traffic is sent at the highest basic data rate enabled on the AP, so ensure that only the lowest enabled rate is configured as the only basic rate.

Starting in code release 4.2 or later, Cisco introduced IGMP snooping on the controller to better direct multicast packets. With IGMP enabled (Figure 11-21), the controller gathers IGMP reports from the clients, processes them, and creates unique multicast group IDs (MGIDs) from the IGMP reports.

Figure 11-21 Enabling IGMP Snooping

Figure 11-22 illustrates the post 4.2 code release multicast delivery with IGMP snooping enabled on the controller.

Figure 11-22 Multicast Delivery with IGMP Snooping Enabled

Step 1. Client 1 sends an IGMP join request through the AP to the controller.

Step 2. The controller creates a unique MGID for the client.

Step 3. After checking the Layer 3 multicast address and the VLAN number, the controller 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 AP MGID table on the AP with the client MAC address.

Step 4. The PIM-enabled router forwards multicast packets destined for the IGMP group of Client 1 to the controller.

Step 5. When the controller receives multicast traffic for a particular multicast group, it forwards it to all the APs.

Step 6. If the AP has active clients listening or subscribed to that multicast group, it broadcasts the multicast traffic on that particular WLAN. If no clients are subscribed or listening on that particular WLAN like with AP2, the AP drops the multicast traffic. 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.

Unlike previous releases, in 4.2 and higher code, when a client sends an IGMP Leave, the controller does not bridge it to the network. It simply intercepts it and removes the client from the MGID table. The network PIM-enabled router eventually times out the client and removes it from the IGMP group.

When troubleshooting multicast issues, you need to keep in mind the limitations of using multicast with a controller-based wireless infrastructure:

■ 2100 series controllers do not support Multicast-Unicast.

■ 2100 series controller with directly connected APs do not support Multicast-Multicast.

■ An LWAPP controller drops multicast packets using UDP ports 12222, 12223, and 12224. Make sure your multicast applications do not use these ports.

■ A CAPWAP controller drops multicast packets using UDP ports 5246 and 5247. Make sure your multicast applications do not use these ports.

■ APs in monitor mode, sniffer mode, or rogue detector mode do not join the AP multicast group address.

■ Multicast is not supported with AP groups until code Release 5.0. If you are using AP groups with 4.2 and higher code, make sure IGMP snooping is enabled on the controller to prevent clients from missing multicast traffic when roaming between APs in different AP groups.

■ IGMP snooping is not supported on 2100 or Network Module series controllers.

■ Multicast traffic is transmitted at 6 Mbps in an 802.11a network. Therefore, if several clients attempt to transmit at 1.5 Mbps, packet loss can occur and break the multicast session.

■ Do not use the 239.0.0.X address range or the 239.128.0.X address range. Addresses in these ranges overlap with the link local MAC addresses and flood out all switch ports, even with IGMP snooping turned on.

■ Controllers do not support multicast across intersubnet mobility events, such as guest tunneling, site-specific VLANs, or an interface override that uses RADIUS. The multicast mode does work in these subnet mobility events when you disable the Layer 2 IGMP snooping/Cisco Group Management Protocol (CGMP) features on the wired LAN.

■ Controllers running code Release 4.2 or later do support multicast mode with interface overrides that use RADIUS (but only when IGMP snooping is enabled) and with site-specific VLANs (AP group VLANs).