Primary (K-12) Education

I was able to get Google Expedtions working on our iPads by adding a new AirGroup service for _googexpeditions._tcp

I am running 6.4.4.9 with campus APs.

Thank you for the solution.  We have been troubleshooting expeditions within our district.  We are using vlan ip pools and seemed to be causing issues when clients had different network IP addresses.  This fixed that issue.  Thank you.

Thanks for posting, Brett!  Would you mind sharing more about the config you got Expeditions working with?  I'm having some trouble getting Expeditions working on our Aruba network.  The behavior I see is the teacher will open Expeditions on an Android or iOS device, enter Guide mode, create a class (e.g. download Mount Everest), click Start, and then on a student's Android or iOS device they go into Explorer mode but they never see the Guide.  I can get this working fine on an old Linksys WRT54G.  I cannot get Expeditions working on our campus Aruba controllers and AP's.

 

Here are some details about our infrastructure and the SSID I've been testing with: We have 7210 controllers, mostly AP-21x access points, and we're running code rev 6.4.3.9.  I created a separate SSID and VLAN isolated to a single controller for testing this without affecting our production SSID's and VLAN's.  I tried the following:

 

Created expeditions AirGroup service with service ID: _googexpeditions._tcp

 

airgroup service expeditions enable    
airgroupservice expeditions
     id _googexpeditions._tcp
     autoassociate apgroup
     description Google Expeditions

Verified that AirGroup was allowed for the VLAN

 

 

airgroup vlan 106 allow

Tried disabling auto associate

 

 

airgroupservice expeditions no autoassociate

Tried enabling IGMP snooping

 

 

interface vlan 106
interface vlan 106 ip igmp snooping

I tried various combinations of the broadcast / multicast options for the SSID.  It seems logical to me that the problem exists somewhere in the broadcast / multicast settings on the controllers.  The knob I was expecting to be blocking the traffic was Drop Broadcast and Unknown Multicast, but still no go.

 

 

wlan virtual-ap "Expeditions-vap_prof"
  no dynamic-mcast-optimization
  no broadcast-filter all
  no broadcast-filter arp

I also found a helpful blog post called "Running Google Expeditions on your Cisco Wireless" (https://www.rsaeks.com/?p=469) that suggested formatting the service string as "_googexpeditions._tcp.local." instead, and when I tried entering it that way the controller said "The format should be " _abc._tcp/udp, _abc-def._tcp/udp or urn:schemas-upnp-org:device:MediaServer:1" so I guess Aruba controllers don't like the _local part.

 

Any ideas or replies are greatly appreciated!  Thanks!

 

I got it working!  I created a fresh VAP and SSID profile.  The settings are basically identical to what I was testing with, so I'm not sure why this one is working.  In any case, I'm still curious to see what other folks' configs look like.  Here's mine...

 

VAP:

 

wlan virtual-ap "Expeditions-vap_prof"
   aaa-profile "Expeditions-aaa_prof"
   ssid-profile "Expeditions-ssid_prof"
   vlan 106
   dynamic-mcast-optimization
   dynamic-mcast-optimization-thresh 80
   broadcast-filter arp

I created airgroup service for google expeditions (I disallow it on VLAN 1):

airgroupservice "expeditions"
  id "_googexpeditions._tcp"
  disallow-vlan "1"
  description "Google Expeditions"
  autoassociate "apgroup"

I made sure airgroup is allowed on vlan 106:

 

 

airgroup vlan 106 allow

Here is my VLAN config:

 

 

interface vlan 106
    ip address 10.6.10.62 255.255.0.0
    no suppress-arp
    operstate up
    bcmc-optimization

Here is my SSID profile:

wlan ssid-profile "Expeditions-ssid_prof"
   essid "Expeditions"
   opmode wpa2-psk-aes
   wpa-passphrase ***************

My aaa and user-role configs:

aaa profile "Expeditions-aaa_prof"
   initial-role "authenticated"
   authentication-dot1x "default"
   enforce-dhcp
!
user-role authenticated
 access-list session global-sacl
 access-list session apprf-authenticated-sacl
 access-list session ra-guard
 access-list session allowall
 access-list session v6-allowall

Happy exploring!

 

On my VAP I had to set no broadcast-filter all to make this stable. It seems to work fine with broadcast-filter arp enabled.

I was helping a school get Google Expeditions working. I found out that in their controller - Configuration - Advanced Services - Airgroups - that AirGroup CPPM Enforce Registration was set to enable. Therefore if users iPads and iPhones were not setup in Clearpass they would not work. We changed this to Disabled and then Google Expeditions started working - so if you are using Clearpass you either need to setup the devices that you want to present in Clearpass or disable this feature on your controller. I attached a screen shot

Thanks for the reply, David.  We don't use ClearPass, so our "AirGroup CPPM enforce registration" knob is set to Disabled.  Also note that I've noticed problems when the "AirGroup location discovery" knob is set to Enabled.  I set "AirGroup location discovery" to Disabled and it works better.  For the service policy (Configuration > Advanced Services > AirGroup > Services > expeditions) I have found that setting "Auto Associate" to "AP-Group" works better than using "AirGroup location discovery".

 

One very unfortunate thing I've found about getting Google Expeditions working on Aruba (without ClearPass) is that I need a separate VAP / SSID specifically just for Expeditions to work.  The reason being that I had to uncheck "Drop Broadcast and Unknown Multicast" in order for it to work.  I don't want to do that on our main network for obvious reasons.  I'd really like to get Google Expeditions working on our main network instead of having this separate VAP / SSID, but it really wants to throw a ton of unknown multicast / broadcast traffic around.

Update: I'm preparing to make a ticket with Aruba TAC about Google Expeditions. Currently, I can only get Expeditions working correctly when "broadcast-filter all" (or, "Drop Broadcast and Unknown Multicast" in the GUI) is disabled on the VAP profile. For the longest time, Expeditions worked fine with "broadcast-filter all" enabled on the VAP, as long as AirGroup was allowed for the VLAN [and the "_googexpeditions._tcp" mDNS string was configured in AirGroup]. This school year, Expeditions clients (i.e. students) are unable to see Expeditions servers (i.e. teachers) in their VLAN. When I disable "broadcast-filter all" on the VAP profile, it works fine. I cannot leave "broadcast-filter all" disabled since there are literally thousands of devices in a school connected to that VAP, and that setting is preventing performance problems, so my temporary solution is I made a separate VAP for Expeditions traffic, and just blocked internet access on that VLAN [so people don't stay connected to it indefinitely].

Hi,

 

what answer did the TAC give you?

 

I have a similar case in my organization.

 

Google Expeditions not working.

 

Regards.

We just had to add the appropriate airgroup service definitions

google expeditions Enabled _googexpeditions._tcp
_googexpeditions._udp

@jkotch

so I have it configured (screenshot).

 

in AirGroups clients I can see the device that makes server (categorized as google expeditions) but the client devices do not detect the server (from the app).

 

I also have the deny inter user traffic and the drop broadcast and multicast activated

Did you try disabling "deny inter user traffic".  If the Google Expeditions device is a user, it might be blocking traffic between that device and your other "users".

We can't enable traffic between devices.

 

We thought that the functionality of AirGroup is to identify type of traffic and allow it.

Airgroup would allow users to discover devices via MDNS, but the subsequent traffic needed to make the application traffic work would be blocked if the google expeditions device is in the user table.

Hello again,

So, how should I have AirGroup and Virtal-AP configured so that Google Expeditions can work?

Can't deny inter user traffic be maintained?