Converting Aruba IAPs to Campus APs for non-UAP access points

Welcome to a quick How To post for converting a shiny new Aruba Instant Access Point (IAP) into a shiny new Campus Access Point (controller based AP). This applies to access points that are not UAP.  For more info on the UAP process and which APs are UAP, check out this awesome post by @theitrebel.

Just power up your access point and once it’s booted, look for an “Instant” SSID.  Connect to this SSID, open a browser, and you will be redirected to a login page* for the controller.  The default login is admin/admin.

Next, click on the Maintenance link, and then navigate to the Convert tab. From the drop down, select Campus APs managed by a Mobility Controller.

Enter the IP or hostname of your controller and click the Convert Now button. Click the confirmation and the conversion will begin. Your AP will reboot, begin anew as a Campus AP, and join the controller you specified. This, of course, assumes you’ve got your controller configured correctly and licensing all in order.

If you’d like to see a short video demonstrating this process, I found this quick video posted by Sean Rynearson: https://youtu.be/Wfl6gYPuyVs

Bonus: If you have a bunch of IAPs to convert, I recommend reviewing this post on the subject, it’ll save you some time: http://community.arubanetworks.com/t5/Controller-less-WLANs/How-to-convert-a-whole-IAP-cluster-as-Campus-APs/ta-p/215053

 

*if you are not automagically redirected when you join the SSID and open a browser window, try manually going to this URL: https://instant.arubanetworks.com:4343/

Published 10/10/2017

Seeing Tetration in action – NFD16

One of the highlights of Network Field Day 16 was a Cisco Tetration presentation by Tim Garner. Launched by Cisco last June, Tetration is a heavy lifting, data crunching platform that soaks up telemetry on all your network packets, uses machine learning algorithms on that data, and produces security policies templates based on the flow information received. This process gives engineers in-depth analytics, an impressive level of visibility, and supplies automagically crafted baseline security policies.  The latter truly shines when you are working with developers and application owners who have absolutely no clue what server needs to talk to what other server(s), much less what ports are required to do so securely.

With Tetration, you can use hardware sensors in the form of Nexus 9K switches with an -X in the SKU, or you can use software agents that can be installed just about anywhere. Or you can use a combination of both.  These sensors look at every single packet going in and out and generate telemetry packets that get shuffled off to Tetration where the real magic happens.

In addition to software agents and hardware sensors that natively generate Tetration metadata packets, you can also stream data from load balancers, firewalls, and other networking devices.  Some devices such as Citrix and F5 are natively supported, but others might take your doing a little work to get the data into a format that Tetration will accept – JSON being one of the acceptable formats.

Another interesting option for getting metadata into Tetration is the use of virtual machines set up as ERSPAN destinations.  Each VM can take in up to 40 gig of traffic, generate telemetry data for this traffic, and stream the data to the Tetration cluster.  Tetration can also take in NetFlow data using this VM method as a NetFlow receiver. NetFlow data is sampled though, so Tetration would not be seeing metadata on every packet as with the other options listed.

Once the data gets to the Tetration cluster, the snazzy machine learning algorithms built into the box start telling you cool things like what hosts are talking to what hosts and what “normal” network behavior looks like, and thereby, what abnormal network behavior would look like.

If your development servers should never be talking to your production servers, Tetration can tell you not only if that what’s happening now, but also if that behavior changes in the future.  Using a Kafka broker* you can have Tetration feed notifications to applications such as Splunk or Phantom, which can in turn communicate with hardware and software devices that perform actions such as host isolation when anomalous traffic is detected.

The automatic whitelists built by Tetration will require some care and feeding by an engineer. Importing policies from ACI is also an option as well. Tetration generated whitelists can be reviewed and tweaked, and an audit of what will be blocked when implementing or making policy changes is an excellent job preserving idea. Checking policies against the four to six months of network traffic data stored by the cluster gives you a good sense of what to expect when enforcement is actually turned on. That being said, you can also run your policies in audit mode for a few months to see what traffic hits the crafted policies.

If you want to see Tetration in action, I highly recommend this video below. The demo starts at about 16 minutes, but Tim Garner is such an excellent presenter, you’ll be glad you watched the whole thing.

 

*Kafka broker service was new to me, basically it’s a notification message bus, I used a few of these links below to get the idea:

https://sookocheff.com/post/kafka/kafka-in-a-nutshell/

https://kafka.apache.org/quickstart

https://www.cloudkarafka.com/blog/2016-11-30-part1-kafka-for-beginners-what-is-apache-kafka.html

 

Disclaimer: While Networking Field Day, which is sponsored by the companies that present, was very generous to invite me to this fantastic event and I am very grateful for it, my opinions are totally my own, as all redheads are far too stubborn to have it any other way.

 

Published 10/6/2017