Wireless Access

Hello all,

Over the next couple of months, I've got a customer deployment which will include some multicast testing (unfortunately). My normal recommendation is "don't do it", but this is starting to look less reasonable these days...

In terms of testing, I only have to demostrate that the equipment can support multicast egress to users. And when it does, it should only go to the client sending the multicast join. Further, we're not interest in, let's call it "challenging" multicast such as Apple's Bonjour. We're only interested in sensible standards based stuff. I'm aware that Aruba only support IGMPv2 (interested if anybody knows if this v3 might be supported one day?!?!), so all this testing is focused on that.

I intend to use VLC to prove this. After a lot of effort, I've managed to work out the fundamentals of this and get the base testing to work.

Firstly, I'll cover a few bits I've done. Following various guides (including high density VRDs etc), I've enabled...

1. mcast rate opt in the SSID

2. IGMP snooping in the VLAN interface

3. Fair access

4. Client match

5. (although I'm not a fan), disabled lower data rates.

Unfortunately, as I'm testing with a 620, I can't enable DMO (wondering if this is the cause of my second problem below?).

I've got to a point where I can fundamentally prove it works, but with a couple of anomalies.

Challenges....

Firstly, the client stream gets dropped after approxmiately 4 minutes (as a general rule). When it does (and having enabled "logging level debugging network process pim") the controller generates the following messages...

Oct 25 09:01:21  pim[2313]: <204213> <DBUG> |pim|  Sending Mobile IP message type 2 for client 192.168.0.36
Oct 25 09:01:21  pim[2313]: <204224> <INFO> |pim|  Removed IP multicast member 192.168.0.36 from group (*, 224.1.1.4)
Oct 25 09:01:21  pim[2313]: <204276> <DBUG> |pim|  INTERFACE TIMER DELETE TIME OUT MEMBER 192.168.0.36, GROUP 224.1.1.4
Oct 25 09:01:22  pim[2313]: <204220> <INFO> |pim|  Deleted IP multicast group (*, 224.1.1.4)

Interestingly, a packet capture on the client shows nothing being sent to it shortly before it's dropped, and the client is NOT sending any "leaves". Furthermore, if I increase the ip igmp query timers on the 620 (to 9999), the problem goes away. Note I didn't wait 9999 seconds to prove.

Any thoughts on this?

The second problem is occasional video quality drop. The first thought might be this is due to contention, but the test client is the only one on the AP and SSID, and the channels aren't contended. If I move the client to wired test, the quality is always perfect (which you might naturally expect I suppose).

Suggestions gratefully received!!!!

The article here:  https://arubanetworkskb.secure.force.com/pkb/articles/HowTo/R-1645 pretty much sums it up.  Fair access and Clientmatch are not mentioned, because they have less to do with multicast than anything.  The lower rates being removed can improve performance.  As you remove the lower rates, there is a limit to multicast reliability when you remove the lower rates (24 is probably the highest basic rate you can acheive  before affecting reliability).   

With regards to your questions, do you have a client that is contstantly sending Joins?  What is the client using to receive the stream?

What band is the client operating on? Do you have the SSID profile parameter “mcast-rate-opt,” enabled?  DMO will have a positive effect on the reliability of the stream, so please obtain a platform that will support DMO (3000 series or M3 or 7200), so that you can test conclusively.  If you are doing small-scale testing, ensure that nothing else is going on on the laptop to disrupt the stream and you do not have any local RF interference.  Multicast is normally conducted on the 5ghz band in mixed networks to avoid that interference.

Commands:

show datapath ip-mcast 

Datapath IP Multicast Entries
-----------------------------
    Source            Group     
---------------  ---------------
              *  239.0.0.1      
              *  239.255.255.250

show datapath ip-mcast destination 

Datapath IP Multicast Entries
-----------------------------
Flags: m - Dyn Mcast Optimization Enable
    Source            Group       VLAN   Destination   Flags  
---------------  ---------------  ----  -------------  -----  
              *  239.0.0.1          30      tunnel 10  m <<<
              *  239.255.255.250    30      tunnel 10  m <<<

 Do NOT put broadcast filter ALL on your VAP, otherwise your multicast will be dropped.

Hello CJ,

I only mentioned the client match and fair access in terms of optimising the air. You're right of course in that it's not directly related to the multicast potential in a controlled test.

The client in use is VLC (as is the sender). As per what you'd normally expect, it sends a couple of joins when it starts, and a leave when it leaves (sniffed it). There's only 1 client in the test. You see it populate in the igmp group on the controller when it starts, and it leaves when it leaves properly of course. The issue is the controller messages about the client leaving (and subsequent application disconnect), when it never sent a leave (application left running, no leave packets sent).

Currently it's on 2.4ghz, which is clean in terms of the air. I can try it on 5ghz and compare results of course.

Yes the mcast-opt is enabled.

Actually, I've found the mcast isn't dropped with the broadcast filter enabled (I can prove this). The igmp snooping appears to compensate as the join I'm sending is IGMPv2. I.e. with the broadcast filter on and IGMP enabled, if I sniff from the client, no multicast is seen (on a shared VLAN with the mcast source). If I then from the same client send the IGMPv2 join, I receive the stream until I send a leave. And only the client asking for it (off a common AP) gets the stream. Happy days. It's just the unrequest leave/disconnect which is confusing.

Racking,

Okay.  Got it.

Try turning If you have IGMP proxy on, try turning it off, then running the same test and see if it discontinues after 4 minutes..

I'll give that a go this week when I get back to my lab! Cheers CJ.