Packet Wrangling Podcast – Episode 2

So, remember when I said that I would be doing these once a week?

Yeah, that was before life came along and decided that it had a different plan in mind!!

Apologies for the long silence. I actually started this recording well over a month ago, but tonight is the first night in a very long time that I’ve had time to actually sit down and put the finishing touches on the recording. We won a large services contract for a very large company (Fortune 10) to roll out new network segments at their datacenters across the US. So I’ve been on the road constantly, dealing with 11 PM to 6 AM change windows, change management meetings, status reports, project managers, and all kinds of “fun” stuff on top of actual network engineering… and then on top of that we’re buying a house and moving to a different state. A huge shout out to my wife for being a rockstar during this trying time.

Without further ado and rambling from me, here’s Episode 2 of the Packet Wrangling podcast. This one covers common wireless architectures and the pros and cons of each. Enjoy!

 

cropped-blocklogo

Make OFDM Great Again

So 802.11ax promises to “reinvent” our dear OFDM technology and bring us to a new promised land of OFDMA. Fly your wireless networking expert flag with pride with this t-shirt!

https://www.zazzle.com/make_ofdm_great_again_t_shirt-235065886507498299

Capture

No, that ain’t me wearing the shirt sadly.

Building your own Battery Pack

Snapshot

So, you’ve built your predictive design and now it’s time for the rubber to meet the road – the infamous AP-on-a-Stick survey. To perform this piece of your wireless design you’ll need a lot of “unique” gear… tripods, laptop shelves, tons of wireless adapters, APs, and enough battery power to get you through the day.

When I was building out my survey kit, I noticed one flaw with the “professional” battery packs built for wireless surveys. Beyond being very bulky and expensive, the majority of them only support 802.3af. The newer and larger APs often prefer 802.3at (also called PoE+) these days. In some cases, they can use 802.3af, but they turn off several spatial streams in the 2.4GHz radio to adjust for the lack of power.

That’s less than ideal, isn’t it?

Thanks for the Internet, I was able to cobble together a pretty affordable battery pack that supports both 802.3af and 802.3at and lasts an incredibly long time. Here’s the pieces and parts that have worked for me:

Intocircuit 26000mAh High Capacity Battery Pack

Tycon Systems TP-DCDC-2448GD-HP DC Converter

Power Jack Adapter Plug

The total will run you about ~$140.00 and it lasts for an extremely long time. Just power up the Intocircuit, hook it up to the Tycon converter using the adapter, and connect your AP. I’ve used it for several gigs now and despite looking a little “homemade,” it does the trick.

Taking a look at VMtracer with Arista

I’ve had the privilege of spending some time with the Arista product this week. For those of you who don’t follow HPE obsessively, some backstory – in the past, HPE led with the Comware product line in the datacenter, which was part of their 3COM acquisition. Comware was solid product and many of our clients had a good experience with the platform… even though the CLI was … “unique” compared to some. Really, it just took some getting used to.

However, last year HPE announced that they were opening a shared partner program of sorts with the Arista product. Arista had been making a lot of positive waves in the datacenter networking environment, so I was happy to add another tool to my arsenal. But then several months things became more serious as HPE announced that all new datacenter opportunities should be designed using the Arista lineup… and that the Comware gear wasn’t going to be their main focus moving forward.

Well, guess I better learn Arista then!

Arista uses Fedora Linux at the core, which allows a lot of cool tricks. Tools like grep, cat, zcat, tcpdump, awk and more are ready to go from boot. Administrators can choose to work in the bash shell or work in the Arista CLI, which will be very familiar to Cisco shops. Because of the Linux architecture, common networking protocols like STP, OSPF, BGP all run as individual processes and can be isolated if problems pop up. VXLAN, MLAG and other datacenter goodies are supported as well.

One tool that stood out to me during the boot camp was the VMtracer. VMtracer allows the Arista switch to keep an eye on the virtual environment by collaborating with the vCenter server. A few weeks ago I published a post around NSX and how it marries the physical network infrastructure with the virtual, solving a lot of problems for the large datacenter and the inherent scaling issues present there. Arista fully supports the VXLAN tunnel overlay I described (in fact Arista was one of the co-authors of the VXLAN standard), but the Arista gear presents a new convenient solution and QoL enhancement for smaller datacenters that still utilize a L2 topology with VMtracer.

It’s always better to show than tell, so here’s a quick walkthrough:

So first, within the CLI we configure VMtracer to communicate with vCenter – see below.

1 - Configure and Verify VM Tracer

Once this is up and running the Arista switch and the VMware environment can exchange info. Running show vmtracer sess brings up the session and gives confirmation that we’re all set.

2 - sho vmtracer sess

After a few minutes the VM database will populate. You can check this with show vmtracer vm, which lists out the VMs, their host, and what interface on the Arista switch they are connected to. In this case everything is connecting via the trunk port Ethernet1.

3 - sho vmtracer vm

We can pull more information with the “detail” flag, showing more information on each VM.

4 - sho vmtracer vm det

Someone who is good with Linux will be able to use pipes and grep-esque commands to quickly filter through info, but frankly I am very rusty with Linux. Keep in mind that Arista does support XMMP for multi switch CLI, so you can pull info from multiple sources simultaneously through pre-defined XMMP groups. Here’s my attempt to pull up info on a specific VM – note that you can quickly determine where a VM is connected using this tool.

5 - sho vmtracer vm name

Now, VMtracer includes a very cool function called “autovlan” that is enabled by default. You can verify its function by pulling up the VMtracer session as shown below. If vmotion moves a VM from one host to another, the physical network infrastructure tied to the new host must support the same VLANs. This can lead to administrators enabling every VLAN for every host to avoid orphaning an unlucky VM that vmotioned to the wrong host. By using VMtracer, the Arista switch can dynamically add VLANs to switches to support VMs as they move around the datacenter.

6 - sho vmtracer sess autovlan

Here I run a sho VLAN command to see what is active on my switch. Notice that VLANs tagged with an asterisk have been added to the switch dynamically with autovlan.

7 - sho vlan dynamic

Cool, huh?

Never fear, you can reign this in as needed. Let’s say I want to ensure that VLAN 1001 does not automatically populate on my switch for some security reason. I can go back into the Lab VMtracer session and remove 1001 from the allowed-vlan pool:

8 - trimming VLANs

To confirm that the change took, run sho vmtracer sess.

9 - sho vmtracer sess with trim

Now I can pull up the list of VLANs again and confirm that VLAN 1001 is no more.

10 - sho vlan with trim

Pretty cool, right?

There’s a bunch of stuff like this that you can do with the Arista lineup. Time to brush up on Linux!

 

 

 

Aruba UAP Boot Process

aruba_question

There’s been many exciting announcements at the Atmosphere 2017 conference and it’s been really great to meet a bunch of the fellow wireless twittersphere. All in all, definitely worth the time to attend.

Many other wireless minds have been covering a lot of the “cool” stuff – new ArubaOS8, new machine learning analytics with RASA and Niara, new monitoring tech with Airwave Glass and Clarity Synthetic, crazy new ways of wireless with 802.11ax, and more.

But one thing that really stood out to me personally is the new Univeral AP code that’s being rolled out to their new APs. Those of you familiar with Aruba know that there used to be two primary “versions” of hardware – Instant and Campus. Campus APs were meant to be used with a controller and they were sold without region locks, assuming that the controller would handle the regulatory compliance. The advantage was that they locked in real quick to a controller with auto discovery. The disadvantage was that there wasn’t a supported way to flash them into an Instant system, so hope you like those controllers you got there. The Instant APs had more intelligence at the edge and had region locks baked in at order, and they could move back and forth between Instant and Controller architectures – but to have them discover a controller required manual intervention, meaning that converting a large scale Instant roll-out into Campus methodology was a pain in the ass. Both were sold at the exact same price point.

The new “Universal” code means that an AP can become either a Campus or Instant AP from birth without any funky conversions. The self discovery process has become much longer though, so to spare you from any hand wringing as the APs slowly toddle towards configuration, here’s the new boot process that was shared at Atmosphere 2017:

  • Static master assignment preconfigured
  • DHCP based discovery using DHCP options assigned by DHCP server
    • NOTE – This uses option 43 to give the controller IP address to the AP
    • NOTE – make sure you don’t have another service utilizing DHCP option 43, I have seen that cause random problems with redirecting the AP to something completely unrelated
    • NOTE – The AP has to have basic DHCP and DNS discovery for any automated discovery to tick. If it doesn’t, it will reboot constantly. Yes, you will need to edit the CLI config to allow APoaS site surveys
  • Aruba Discovery Protocol based discovery
    • NOTE – this only works if either the controller is in the same broadcast domain as the AP or if multicast forwarding is configured (multicast address used is 239.0.82.11)
  • DNS based discovery (this is what Aruba recommends as best practice)
    • NOTE – the AP will look for aruba-master
  • Instant Virtual Controller Discovery
    • NOTE – this means that the AP will reach out in its own broadcast domain with the PAPI protocol to find a local Instant AP that is elected as VC
  • Airwave Discovery
  • Activate Match Airwave
    • NOTE – Activate is Aruba’s cloud based provisioning service. The AP must be able to communicate on the Internet for this step or the following two to work.
  • Activate Match Central
  • Activate Match CAP/RAP
  • Broadcast Instant Provisioning SSID
    • NOTE – And here’s where you are off to the races with the Instant platform!

Quite a journey, isn’t it? Nice that we’ll be able to purchase as single SKU now though.

 

 

 

Atmosphere 2017

atmosphere2017

No podcast/blogpost this week, as I’m out living it up in Nashville with some of the best and brightest minds in the wireless networking industry! They’ve revealed a lot of exciting new features in just the first day, ranging from the ambitious machine learning based security on the internal network to the practical new wired tunneling techniques and multi-zoned APs. And yes, the presentations are more than just marketing fluff. I’ve already attended several great sessions, including a technical deep dive on 802.11ax, with many more scheduled for the next several days. More to come.

Also, the ongoing Amazon S3 outage just proves that the cloud really is just someone else’s computer.

 

 

PacketWrangling Podcast – Spectrum Analysis

cropped-blocklogo

Welcome to the first Packet Wrangling podcast! In this episode, we take a quick look at spectrum analysis technology and discuss why it’s important both for new deployments and to troubleshoot existing installations.