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!!!!