Thursday, October 29, 2015

Cisco Hyperlocation Module - COME GET SOME

Ok - it took a little while but it appears the Cisco WiFi / BTLE location tracking concept has come to full fruition.

Excellent overview of the what can be done with Hyperlocation Modules within the following presentation:

Sunday, August 2, 2015

Mobile Madness - Elephone P6000 - There's a reason it's cheap.

Gday all.

Just a quick word of warning for anyone jumping on the cheap chinese phone bandwagon...

I purchased an Elephone P6000 phone approx. 2 months ago and it has been reasonable (apart from the worst GPS navigation accuracy I've ever seen) up until now with the issue being that the cellular radio in the device basically just seems to be screwed.

I now see the cellular radio indicator going bat shit crazy and just cycle through all available network connections staying locked on to a single network for 30 seconds max with no ability to make or receive calls.

Evidently looking on the Elephone forums for the P6000 there seems to be other people who have had the same issue.

Oh well - at least now I've answered my question of "are these cheap chinese smartphones any good?".

As usual, you get what you pay for...

Wednesday, May 13, 2015

The Wifi's - A Brief Lesson in Wireless Technologies

Much like TV and Movies, there are more APs on the market than ever and more that suck than ever before.

It constantly baffles me WHY some manufacturers even bother making an access point.

Probably just so they can say "yes - we have a product in that segment".

To go back a step, I recently had to spec up SMB grade wireless for a small site that supports roaming.

If I was working with enterprise grade gear, my normal go-to's would be Aruba or Xirrus depending on the environment.

Unfortunately that gear is a tad pricey (once you throw in the costs of an on-prem controller or cloud controller subscription) for SMB users.

My regular go to for these types of environments is Ubiquiti.

Until recently, Ubiquiti has been my go-to for the fact that their 802.11n UniFi Pro APs have very good radio chipsets, antennas, support zero handoff roaming and use a software controller that can be installed on any Windows PC.

Unfortunately, Ubiquiti doesn't have an 802.11ac AP that support ZHR.
It's not like that's their bread and butter right?
Oh hang on....

Anyway, let me take a step back for a second and explain WHY enterprise grade gear is (generally) better than home / SMB.

There are a small number of key features (both physical and logical) that separate Enterprise APs from (most) home / SMB products, specifically (and I'm using this as a tech explanation section as well):

Antenna Gain
Most enterprise APs have internal antenna gain values starting at 4dBi usually going anywhere up to 6dBi.

Yes - good internal antennas cost more, and that's part of what you're paying for.

What is antenna gain I hear you ask?

Well, gain is sort of like play-doh.

Most antenna types are what are known as omni-directional.

That is, the RF patter emitted from the antenna is in the shape of a sphere.

Now, with RF, you can design antennas to compress and stretch that signal into different shapes.

Note that you can't actually increase the total volume of coverage - you can just change the shape of it by stretching it out.

Now antenna gain is two-way in that an increase means both transmit and receive sensitivity is increased.

Transmit Power
Ok - this is the primary area people get themselves into trouble with wireless design.

More TX Power is not always a good thing!

Transmit power is the amount of power pumped out from the radio chipset in your AP to the antenna.

Generally speaking this will be anywhere up to 200mW.

The coverage area you can create with an AP is basically a combination of your antenna gain and the Tx Power of your radio.

Now - here's the most important thing to keep in mind when configuring the Tx power on your AP - you should always configure the Tx power to match that of the weakest device that you will be using on your WLAN.

Think of it this way.

e.g. If an AP is capable of transmitting at 200mW that means a client can receive data from the AP at maybe up to 50 metres away.

If the client however only has a 50mW radio, it won't have enough power to transmit back to the AP until it is a maximum of maybe 25 metres away.

The client will show you an excellent RSSI value however in reality your connection will be horrible as your packets never make it back to the AP.


Wireless Standard Support (802.11n / 802.11ac)

802.11ac - MIMO Antenna Paths

Simultaneous Dual Band


Software Controllers and Managed APs

PoE / PoE+ vs. DC PowerBrick APs

Sunday, April 5, 2015

Software Defined Networking - Part I.


Ok - so you're probably heard of Software Defined Networking or "SDN".

But what does it all mean?

Well - in a nutshell - it means instead of the server guys having to ask the network guys to stretch a new VLAN between datacentres or add / move / change VLANs on a switch port that a server connects to (be it a physical or virtual switch), some middleware (usually referred to as an SDN controller) will work with the hypervisor to change the configuration automatically.

On top of this, a pipe dream of SDN is that event driven (i.e. a threshold is met on CPU usage or NIC bandwidth usage) VM and network route path changes will occur to ensure a high level of performance.

There's really only two use cases in which I see SDN coming to fruition.

1) Managed Service Providers

MSP's are the primary target for SDN.

Providers running the likes of openstack stand to benefit primarily from SDN through automation of configuration.

Furthermore, if setup correctly, you can essentially allow customers to manage their own network provisioning (whether you'd want to or not...).

2) Non-Cloud Enterprise Data Centres (i.e. All On-Prem in Data Centres)

Are you a large enterprise with hundreds of servers and due to poor housekeeping a mess of a network core with a sea of unmappable fibre and copper patching?

If so, SDN probably isn't for you.

SDN isn't a "magic fix" technology that just makes all your existing problems go away.

If your company is in this situation, you obviously have bigger problems including discipline and governance, and that's not likely to change.

In this situation, SDN could actually be a VERY bad thing for you as you'd then have automated insanity and dig yourself into a hole you may never come out of.

In other words, SDN is NOT a solution to a problem that shouldn't exist.

On the other hand, if you're a large enterprise maybe looking at spinning up a new data centre to migrate to, than yes - SDN would definitely be worth looking at.

Done right (with discipline, design and control), you could design and implement an efficient, predictable and autonomous network core and realise all that SDN has to offer.

Having said that, the same thing can be achieved through good network design without SDN.

Now - one thing to bear in mind - the "crazy filter" that you often get from your network engineers in data centre rollout is essentially removed with SDN.

Just because you're running an SDN environment, doesn't mean you can skip vetting of the requirements by the network engineers. 

The way I see SDN is that it's a tool that should still be managed by network engineers and provided to them to make their lives easier.

Handing over this level of access to server engineers is scary.

3) Majority Cloud / Minority On-Prem - Maybe 

Is it a case of too little too late though for on-prem servers?

As the trend is to currently stick your servers up a remote hosting service like AWS or Azure, for the small amount of remaining on-prem servers that honestly aren't going to be moving around or changing that much, is it worth deploying a whole new architecture when simple good VLAN design and deployment would work fine?

Even if you do a network refresh and purchase all new datacentre switching, would you bother using this technology for a small-scale deployment?

For me, there's two big issues here:

1. Trust

This technology is very new and no one is using it yet.

Think about what it's doing - changing your NETWORK infrastructure configuration automatically.

What if there's a bug in the SDN controller software or in the implementation of the command interpreter or API instructions?

How will you EVER find the fault and what do you do in the mean time?

2. Control

How dynamic is your network REALLY?

Do you honestly have changes occurring THAT regularly that good network design shouldn't just provide your server guys with a network environment that doesn't require reconfiguration regularly anyway?

It comes down to "how big is your environment"?

If you're a mid-level cloud provider running an open-stack platform for your customers, than sure, this will be of interest to you.

Technology Overview (What it SHOULD look like).

Hypervisor Manager
SDN Controller
SDN Infrastructure

The Technologies

That's the problem - a standard does exist, but everyone seems to be going in a different direction.

Let's deal with the most established components first.

1. Controller or Custom Vendor Middleware

Most companies generally run one or two brands of switch and route infrastructure in their organisation.

At present, you've most likely got one or a few management platforms used to control the configuration, monitor the health and performance and detect faults across this infrastructure.

This is where there is where the first problem of "the new world" of SDN creeps in.

The original idea with SDN was that there was a common language (with OpenFlow being the leader) that a controller would support.

The controller sits between the hyper visor and infrastructure and talks a common language between both to change network infrastructure dynamically as driven by the hyper visor.

All manufacturers should support this language and away you go.

But no - of course not.

SOME vendors do but others insist on using their OWN language or even worse, use an API.

In fact, most do the later and take their existing management platforms and just tack on the API functionality on top.

I personally prefer the idea of OpenFlow a lot more as it levels the playing field and makes it very easy for customers to swap notes and establish which vendor has best implemented the protocol.

While vendors are using API driven configuration expect your platform to suffer due to:

  • Slower development
  • Still locked in to one brand of equipment
  • Inevitable bugs or missed elements in API.
  • No guarantee as to release cycles to address bugs etc.

2. Configuration Protocols

The primary language for SDN is OpenFlow.

Think of OpenFlow as SNMP on steroids for data centres.

Using SNMP you can read and write configuration elements across any brand and model of device that supports it using OID values specific to the configuration element you want to change.

It's super light-weight, fast and enables you to perform bulk changes easily and quickly.

OpenFlow is the same thing - a standardised language that it supported (or at least will be) by many vendors and allows a single controller to manage the network infrastructure configuration.

OpenFlow is obviously a different language to SNMP but does a lot of things the same however also has many additions that are data-centre centric such as:

Saturday, February 28, 2015


Here's another one for you to keep in your armoury.

NetDISCO is an oldie (well, there's actually a revamped new version available) but a 

Although the purpose of NetDISCO is somewhat simplistic, it really is a tool you can't afford to be without in todays enterprise networks.

Essentially NetDISCO does exactly that (network discovery).

Once you add devices to it's database, it slurps their MAC and ARP tables and keeps a record of this over time.

Need to find where every device starting with a particular vendor ID component of the MAC address are connected throughout your environment?


Want to quickly see how many switches ACTUALLY have spare ports on them, and of the spare ports, when (if ever) was the last MAC address seen on that port?

You can grab a virtual appliance from over at

As per the download site, once you've spun up the VM, config it as per:

Don't forget - the UI listens on port 5000!

rConfig - Open Source Config Backup, Change Tracking and Compliance

Ok - here's my vote of confidence in an open source product that has been growing for the last couple of years.

Any network engineers who have been in the game for a while know that config management is a critical component of daily operations.

In Cisco land, the go-to's for a long time have been RANCID and SolarWinds Cirrus (now known as Network Configuration Manager).

RANCID is great for backing up and performing config DIFFs but has been missing a pre-developed compliance module.

For those who are familiar with Linux find and grep commands, this isn't a major issue as you can easily enough construct the statements you need to find which devices either do or don't match a particular line(s) of configs.

At the other end of the scale, you have the highly polished and super expensive SolarWinds NCM.

It does exactly the same thing as RANCID and find / grep but all delivered through a polished GUI.

To some degree, NCM is easier, but can also cause you a lot frustration.

Now, finally, there is an open source contender that is a great middle ground.

rConfig provides a web based interface for backing up router and switch configs on any schedule you desire, pushing bulk configuration deployments to individual devices or groups and here's the party-piece: compliance that works.

The build is relatively straight forward.

I recommend CentOS as always.

The only issues I experienced while following the build guide (account needed) is that step 2 repository links didn't work at the time (just tested and all working fine now) and there's a typo in section 3 (a space character was left out) which should read:

yum -y install php-devel php php-domxml php-gd php-mbstring php-mysql php-ncurses php-pear php-cli php-common php-pdo

One thing to note is that the compliance modules use RegEx pattern matching so you may need to bone up on those skills to make sure you're ready to deal with special characters (like a forward slash) that you may want to match in a configuration search.

All in all, rConfig is a great product.

If you're a Cisco route and switch shop and you're not running any network configuration management tools at present, this is the way to go.

If you're using RANCID, this is a sound and worthwhile upgrade.

If you're using NCM you may well want to stick with it but I'd at least recommend giving rConfig a whirl.