Wireless Access


Multicast clients behind RAP in split-tunnel mode



We're trying to set up a solution where we try the following design:


RAP in split-tunnel

Controller is default gw for clients connected to the RAP


IP-TV is connected to the Wired-AP port, but we're unable to get the multicast to run.

We also tried connecting a laptop to a wireless SSID on the same RAP with DMO enabled. Still a no-go for multicast.


We've enabled IGMP snooping on the client vlan.


According to this screenshot for a pdf I found by Aruba (Multicast video decision flow chart) this should be doable..


Anyone have experience with this and can direct us in the right direction?




John Solberg

-ACMX #316 :: ACCP-
Intelecom - Norway
Remember to Kudo if a post helped you! || Problem Solved? Click "Accept as Solution" in a post!

Re: Multicast clients behind RAP in split-tunnel mode

One week and tons of hours of work later - we got a working solution.

Multicast locally bridge out of RAP in split-tunnel is a no go. Its not supported in this AOS.
Bridge-mode works - of course, but not exactly ideal.

We reverted back to Tunnel mode for the IP-TV multicast solution. Then how to implement this.. In lab environment the testing we did wasn´t close enough to the customer solution to copy directly.

So we saw that a set-top box multicast client got it´s stream directly no problem. If we placed a RAP between the stream stopped. So we configured IGMP Proxy on the client VLAN towards the uplink interface. No go.

Requirement to use IGMP Snooping or Proxy is:
* The VLAN has to be forwarded to the upstream router
* The router needs to do all the multicast routing
* The client VLAN can not be NAT by Controller so "no ip routing" on the client interface.

Using IGMP Snooping means that the Controller handles the IGMP joins per AP. No stream is sent n AP that doesnt have clients subscribing to the stream.

IGMP Proxy handles the same per user, and is required if you need L3 Mobility.

More information about this in the User Guide, but imho. it´s not easy to understand HOW and WHAT to choose.

At this customer it was defined that the Client/multicast VLAN was not to be routed directly, but had to be NAT´ed. The VLAN was not defined in Core.

So we ended up having to set up a separate Router that handled the multicast routing and NAT´ed the traffic from this client/multicast VLAN.

Of course we also ran into some nasty jitter issue underway, that we didn´t find the root couse of. We eventually changed the controllers IP and narrowed the ACL´s to these from the infrastructure to a bare minimum. That solved it - for some odd reason..

John Solberg

-ACMX #316 :: ACCP-
Intelecom - Norway
Remember to Kudo if a post helped you! || Problem Solved? Click "Accept as Solution" in a post!
Search Airheads
Showing results for 
Search instead for 
Did you mean: