Multicast on LWAP AP

[sam_manay]

any one experiencing on Multicast problem. In my network, Multicast is perfectly working on wired to wired network, but once using wireless to Wired (multicast server on wired).

Currently I am using WLC (LWAP AP, any advice to solve my problem?

Many thanks in advance,

KindlyRegards,

sam

[mpatalberta1]

The multicast packet is sent by the infrastructure on all ap. it does not know who is going to receive them. For example dhcp does this. Thus you cannot rely on who will ack the multicast.

I am using the multicast for voice with wpa2 personal. In general except during a roam we get no loss. However we do have 1 redundant data packet in the multicast packet.

The roam with an open infrastructure we do not loose any noticable packets.

The roam on wpa2/psk as result of a soft handoff we have no loss. We only have data loss during a distressed roam.

Turn off the aironet ie.

[mpatalberta1]

I should mention you could use the cisco igmp method. This option is suppose to improve the multicast performance.

[j-mccarthy]

I am using Cisco IGMP. There is no roaming involved. One client, one access point, one WLC & one multicast server.

Voice (MOH I assume)is probably ok because the bandwidth of the stream is so low (64kbps).

With a 1mbps video stream the packet loss is really noticeable. Looks like delivering video over wireless multicast is a non runner.

[Matthew Fowler]

Probably the biggest issue is, as mentioned, the fact that 802.11 multicast is not ACKed while 802.11 unicast is. The test would be to get a wireless sniff of the unicast video and see if the retransmit percentage is about the same as the multicast drop percentage.

What power saving is the client doing? Have you tried setting it to being constantly awake?

[j-mccarthy]

hi mat, i haven't mucked around with power settings on the client to be honest. thats interesting idea because i am seeing different levels of packet loss with different clients. ibm t60 with an intel 3945 seems a lot worse than a dell d600 for example.

[Matthew Fowler]

I ran a test after I posted. I have a 4965, set the Power Management bar to lowest performance and a 1Mbps iperf test resulted in 2-9% loss. I then set it to highest performance and I only got 0.18% loss.

So, definitely worth checking/trying.

[JASON BOYERS]

It looks like the 4965 is using Power Save Polling mode, with the default being to conserve as much power as possible. However, that means that the client is not listening all the time for traffic. And, thus when the AP sends the multicast traffic, the client doesn't hear it. From what I'm seeing, PSP really doesn't give you much more battery life with current devices. I'd change the Power Management to highest performance, like the last post indicated.

[dziminski]

I am just starting to test multicast video myself and I am running into the same issue. Even a well designed wireless LAN with QOS is still going to have collisions. With unicast video, the packets can be resent at the 802.11 layer. With multicast, you are going to get some packet loss since there are no ACKs and therefore no retries. Aruba has a feature that converts multicast to unicast from the AP to the client to get around this. I don't think the cisco controllers have this (at least I haven't seen it).

[lomonaco]

Hi,

What about your data rates. Take a look this information (Mobility Design 4.1)

It might seen logical to choose the default configuration of APs and clients, thereby allowing all data rates.

However, there are three key reasons for limiting the data rate to the highest rate at which full coverage is obtained:

Broadcast and multicast (if enabled) are sent at the lowest associated data rate (to ensure that all clients can receive the packets). this reduces the throughput of the WLAN because traffic must wait until frames are processed at the slower rate. Clients that are farther away, and therefore acessing the network at a lower data rate, decrease the overall throughput by causing delays while the lower bit rates are being serviced. It might me better to force the clients to roam to a closer AP so as not to impact the performance of the rest of the network.

Rate Modes

If more than one data rate is set to mandatory, multicast and broadcast frames are sent at the highest common mandatory transmission rate of all associated clients (the lower mandatory receive rate of all of the clients) This allows all clients to receive broadcast packets. The lowest mandatory rate is normally set at 1 Mbs/s

My Best Regards

Andre Lomonaco

[dziminski]

Good point about the data rates. That could have a huge impact as well if your multicast traffic is sent at 1 MBPS.

Aruba has a feature that will bump up the data rate for broadcast and multicast to the highest supported rate that all associated clients on an AP support. Hopefully Cisco will develop a similar feature.

Edit: I did some testing with data rates. I set the 18 mbps rate as the only mandatory rate and I was able to get the multicast to transmit at that rate. However, I didn't see a big improvement on performance. Still losing about 3-5% of video packets. The video is very jumpy. I am testing with the 1142 AP and a Lenovo T400 with an Intel 5300 WLAN card.

[sbhadrav@cisco.com]

Before Cisco Unified Wireless Network Software Release 3.2, when IP multicast was enabled, the controller delivered multicast packets to wireless LAN (WLAN) clients by making copies of the multicast packets, then forwarded the packets through a unicast Lightweight Access Point Protocol (LWAPP) tunnel to each access point (AP) connected to the controller. Each multicast frame received by the controller from a VLAN on the first hop router was copied and sent over the LWAPP tunnel to each of the APs connected to it.

The controller might need to generate up to 300 copies of each multicast packet, which depends on the number of APs. This mechanism is inefficient, and places a large processing burden on the controller. This floods the network with a large number of duplicate unicast packets.

In Cisco Unified Wireless Network Software Releases 3.2 and later, the multicast performance of the Cisco Unified Wireless Network has been optimized. These releases introduce a more efficient way to deliver multicast traffic from the controller to the APs. Instead of using unicast to deliver each multicast packet over the LWAPP tunnel to each AP, an LWAPP multicast group is used to deliver the multicast packet to each AP. This allows the routers in the network to use standard multicast techniques to replicate and deliver multicast packets to the APs. For the LWAPP multicast group, the controller becomes the multicast source and the APs become the multicast receivers. For the multicast performance feature, the APs accept Internet Group Management Protocol (IGMP) queries only from the router and multicast packets with a source IP address of the controller with which they are currently associated.

If your network supports packet multicasting, you can configure the multicast method that the controller uses. 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 an LWAPP 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.

You can enable multicast mode using the controller GUI or CLI.

Could you please let me know if this question was related to a specific deal, could you also provide us with the Deal ID?