Google Expeditions on School Networks

Google Expeditions on School Networks

For those who don’t know Google Expeditions allows for Teachers to take students on virtual tours to places most field trips could never go. Teachers have the ability to direct the tour and keep kids engaged in this virtual reality world.

Expeditions is a peer-to-peer  (P2P) application that runs on iOS and Android devices.  The P2P aspect of the application presents many problems in most school environments. Schools have enterprise networks with segmentation just like networks in the corporate world. This segmentation presents problems related to discovery and communication for P2P applications like expeditions.  To get around the issues segmentation poses to Expeditions may retailers have put together very expensive kits that schools can buy.  Included in the kits are usually several android devices, cardboard or plastic VR viewers and a consumer grade wireless router.

In this post I'm going to give you some general guidelines and show you how to get around the big expense of these kits and the potential security threat they may cause.

First let's start with why the kits are bad ideas. Introducing any new devices into your environment could be difficult if you don’t have a way to centrally manage them.  You're going to want an MDM solution already in place with the necessary amount of licenses. Next the wireless router poses a potential security risk and could cause unintended network issue. Being that the wireless router is a consumer grade product there is no way of managing it on your enterprise wireless network and if these devices are configured incorrectly and plugged into the network you may find yourself with some DHCP issues that could be difficult to track down.  Weak or no security applied to the wireless interface of the router gives attackers or in this case students unfettered access to any VLAN this device may be plugged into.

If you want to reduce your potential headaches from these kits and save your districts lots of money, we need to figure a way to get Google Expeditions to work across VLANs on our wireless networks.  To do this we need to understand how Expeditions works. There are two main categories in Expeditions, Leaders and followers.  The lead device is always the teacher device and the follower is the student device. Lead devices need an internet connection to download expeditions (not the app but the tour you're going to take). Follower devices technically don’t need an internet connection they just need the ability to discover the lead device and make a P2P connection with it. For discovery Expeditions use Multicast DNS (mDNS) to discover other expeditions devices and setup a P2P connection with them using random ports.

Most students have their own devices iOS or Android and most schools have implemented some form of BYOD so let's take advantage this!

Alright now let's take a simple school wireless network and configure it to work with Expeditions.   In this environment we are going to say that all enterprise devices are on one VLAN (10) and all BYOD devices are on another VLAN (20).

Knowledge needed: DHCP, Access control lists, Multicast DNS and good understanding of your

wireless platform.

1. Choose a district owned enterprise device (or purchase a new one, iPads work great) that is always going to be the Expeditions Lead device. (This device does not only need to be used for expeditions but it always needs to be used when Leading an expedition. You can have several Lead devices)

2. Reserve an address in DHCP using the Expeditions Lead Device(s) MAC address. (Multiple devices require multiple different IPs)

3. Adjust ACLs to allow bidirectional communication between Expeditions Lead device(s) (these are the IPs you just reserved)  and Follower devices (this would be the entire BYOD subnet Vlan 20)

4. Enable multicast DNS (mDNS) across vlans (or SSIDs) that need to be able to participate in the

Expedition. (VLAN 10 and VLAN 20)

5. Add a new mDNS service “GoogleExpeditions” with service string

“_googexpeditions._tcp.local.”

6. Make sure the new GoogleExpeditions service is associated and can be seen by devices

After doing what's outlined we opened up minimal security holes to our network by allowing BYOD devices to only communicate with the IPs of the Lead devices instead of the entire enterprise subnet (VLAN). Schools I work with normaly select 1-5 devices to be a Lead device, this allows up to 5 different classes or Expeditions to run at a time. Having lots of devices as Lead devices could become a management nightmare if you need to create DHCP reservations for all of them.  If you need lots of Lead devices I would suggest placing them in their own VLAN and allowing your BYOD VLAN to communicate with it.

Below is a reference on how to add google expeditions mDNS to a Cisco WLC network.  You'll need to already have mDNS working in your environment and ACLs configured appropriately.

Controller > mDNS > General

 Add a new service

Master Services Database

Select Service: Other

Service Name: GoogleExpeditions

Service String: _googexpeditions._tcp.local.

Query Status: CHECK (enables the service)

LLS Status: CHECK (enables location for service. You must be connected to the same or surrounding APs  to discover)

Make sure to click Apply!

Now the service is created we need to associate it to our mDNS Profiles

Controller > mDNS > Profiles > (Choose your mDNS Profile to edit)

In my case I have two profiles to edit, Enterprise and BYOD

Services List

Service Name: GoogleExpeditions

Click Add

Last you need to Associate the mDNS profile to the WLAN(s) you want to be able to use Google Expeditions

WLANs > (Choose WLAN ID) > Advanced

Scroll to the bottom

If you're like me and have a single SSID for all devices that do 802.1x you can return the following RADIUS attribute to associate the mDNS profile to the end devices.

Cisco-AVPair

=

mDNS-profile-name=enterprise-mdns-profile

Thanks for reading, I hope this helps you in setting up your network for Google Expeditions!

Why you don’t need 80MHz in Schools

Many school districts want 802.11ac networks for their schools.  Some are even willing to rip out there still very useful 802.11n networks for the chance to get the great speed increase that 802.11ac provides.

What no one told these districts is the great speed gains they were promised is all marketing and fluff. Ok so it's not all marketing and fluff but the configurations needed to accomplish these data rates is not practical for a high density school deployment.

School districts in my area have been going crazy lately with standardized online testing and video streaming which has led to the explosion of devices in the classrooms and on wireless networks.  Some schools have even deployed a Chromebook to every student.

Vendors often come into schools looking at 802.11ac and sell them on the big data claims of AC. We have all read about 80MHz and 160MHz channels with "X" number of spatial streams and 256 QAM netting us well over a gig of data. Not to mention MU-MIMO which I kept hearing would be "switch like".  With data claims over one gig districts are thrilled to hear that the wireless clients would have higher throughput then wired and they were willing to pay anything to get it. Once vendors had the districts hooked on AC data rates they then turned around and told them what it would take to get there.  For most it wasn’t just an AP overhaul which sometimes included a new controller or two. With the need to have a multi gigabit backhaul this meant that districts were going to need to run an additional drop or in some cases 2 new drops to every location an AP was going to be deployed. Which than meant switch closets would need additional port density… yup new switches!

So for all this what did the districts get… the network they asked for. I wouldn’t say that these networks performed poorly (some did) but I would say it was overkill. So why is this overkill? If you take a look at the networks as a whole, things start to fall into place. Most districts I work with have moved to cloud based applications and some have even gone as far as to get rid of all the file servers in the district (they moved the servers to our NOC with a 1 gig link back to the district). Between switch closets most have 1 gig links to the core but are slowly migrating to 10 gig. All this makes the internet or WAN link the critical path.  What's the point of increasing the wireless data rate and AP backhaul if you're just going to bottleneck it somewhere else? Most of the districts I work with have nowhere close to 1 gig of internet. Then we need to take a look at the clients they have deployed.  Lots of schools are moving away from expensive laptops and deploying Chromebooks instead. Why? Because they are cheaper and everything they do is in the cloud anyway so why not! All the Chromebooks that I have come across only support a max of 2 spatial streams, MCS 9 and 80MHz which nets you 866mbps in 5GHz. Sounds like we are getting close to needing that 2gig backhaul now.. Add in a client (Chromebook) on 2.4GHz transmitting at the same time with a 40MHz channel (this is a no no) and an MCS of 15 for its 2 spatial streams and you get 300mbps (866+300=1166mbps). Finally we break the 1 gig backhaul and our network is justified! Or is it? Don't forget to take into account that the data rate is not the throughput. Wireless has a lot of overhead that never makes it to the wire so let's assume 70% throughput on the wire (70% of 1166 = 816) and suddenly we are back down below 1 gig.

Now given the nature of wireless let's look at a more likely scenario in our high density deployments.  All APs would need to use 20MHz channels in both 2.4 and 5GHz do to the need for more contention domains. A Chromebook with 802.11ac using 2 spatial streams and an MCS of 9 in 5GHz and another using an MCS of 15 in 2.4GHz transmitting at the same time would give you an over the air combined data rate of 317mbps. At this point I don’t even need to figure the wired side throughput to determine that we don’t need more than a 1 gig backhaul.  On top of all this we didn’t even get into the application throughput requirements which would be well below our over the air data rates.