Let’s say you, like everyone else, are eagerly following the heroic conquests and backstabbing betrayals of Game of Thrones. While waiting through the torturous gap between seasons, you decide to give the books a try to tide you over. From your public library website, you search George R R Martin and with the click of a button you can trace each copy of A Song of Ice and Fire throughout each branch of the library. There’s one unreserved at your neighborhood location, so you head over and pick it up. While you’re there, you use the library’s free wifi to see if Martin has finished the next installment yet (spoiler alert: he hasn’t), and later you’ll use the same system to renew the book on your mobile phone from the comfort of an armchair in your favorite coffee shop.
The library itself might be an ancient and elegant concept, but these days there’s a lot more to it. In order to provide the best possible service to the community, they must be constantly updating their technology both guest-facing and behind the scenes.
I recently helped the Richland Library in Columbia, South Carolina revolutionize the system that they and their community rely on with the the full Meraki MS Stack. For those of you who are unfamiliar, the Cisco Meraki switch is a game changer.
Network switches are what tie all of our wireless devices together, but traditionally the switches themselves have been grounded in cumbersome cable and physical proximity. Builders would have to come in and lay a physical infrastructure behind the scenes of all that wireless connectivity, and that leaves a lot of unknowns. These systems aren’t always installed correctly, and even when they are an expert has to be on the scene in order to run any kind of diagnostics and work to fix a problem.
Not anymore. Cloud switches demystify the process and allow us to do everything remotely. While previously much of this work would have had to be contracted out at great expense, the Meraki switch empowers the library IT technicians to become experts on their own environment. They can learn the system inside and out, familiarize themselves with their network data, figure out what’s making a connection run slowly, and identify any issues — without having to literally drive to the source and work with the physical device. Now, they can solicit details, run tests, and problem solve in a centralized, streamlined way. Ask any IT guy — the idea of running a cable test from 50 miles away is worth getting excited about.
The upshot? Put simply, the Meraki switch means a better library for the community, more efficiency for staff, and even easier access to the latest installment of Game of Thrones. This investment in the library’s technological future means saving big on training and maintenance costs — money that can now be put towards community services. It means a smarter, more intuitive network system. It means enhanced security, faster services, and less connection downtime for citizens. A better user experience and an intelligent use of citizen tax dollars.
For those of you who are interested in the technical details, the installation was an interesting journey. You might well expect this to be an easy task, considering the elegant features of the Meraki dashboard would enable both the client and myself to configure and spot potential routing and switching issues. What my team and I didn’t expect was the proprietary HP VLAN and trucking. All our first attempts failed, not because the original HP switches were bad, nor because the Meraki MS devices weren’t highly capable, but because at some point in time HP’s version of VLAN’s and Cisco (the rest of the world) where changed.
This poses a problem for any IT shop that wants switch providers while attempting to run the switches parallel to the HP’s. I had to make this work by starting on the outside and coming in. Each Library branch office was connected by a single Metro-E connection and had a Cisco 2900 series router in between the remote network. The Cisco 2900 series router was put in place to take care of the inter VLAN routing setup by the Library system.
We realized, however, that we could demystify the network by removing not only the Cisco 2900 series routers, but also the L2 HP switches sitting behind each and every router. Each location had a common VLAN infrastructure. There was a voice VLAN, data VLAN, and public VLAN. DHCP was served by a single DHCP cluster running back at the main library.
After taking a look at the switch configs, we removed the Cisco 2900 switch and set the MS320 L3 switch up with the appropriate VLAN’s. Then, to keep the MS DHCP server from getting confused we set the port on the Aggregation switch at the main library (the new core router) to only allow a specific VLAN which we set up as the backbone VLAN for all of the new Meraki Switches.
The new VLAN did allow DHCP for the devices (static for the routing interfaces) so the Meraki equipment was easily configured. Once the remote site was fully set up, all routing statements were moved to the new MS420. All VLAN’s were moved from the 5400ZL series and placed on the MS420. After that all IDF’s were replaced with MS320’s and the network topology started to form.
In the end, it was well worth the trouble. A little planning and a few early mornings left our client so happy that they’re talking about rolling out more access points, and ultimately the entire community will feel the benefits.