With the dynamic today moving towards private and public cloud offerings, the virtual appliance marketplace will most certainly continue to grow and mature.  There are many reasons why this makes a lot of sense.

Take a look at the time it takes to implement a physical network appliance.  Let’s use an application delivery controller – or load-balancer if you prefer that term.  How long does it take to implement a physical box into an existing environment?  Between ordering the unit(s) which usually come in pairs, shipping, and installing, it takes some time.  The cables need to be run, the box racked and stacked and then physically powered on and provisioned.  We have been doing this for years and this used to be standard operating procedure. Now that works well and good, kinda, in your own data center.  What about a public cloud offering?  Sorry, you don’t own that infrastructure. How about downloading a virtual appliance, spinning up a VM and you are off to the races. Again, this happens after provisioning the unit, but there is a lot less moving parts going that route.  Cloud or not – either way it still makes sense.  There will be less infrastructure requirements: power, rack space, cabling etc.

There are some other tangible benefits as well.  From a refresh perspective it just makes sense to upgrade a virtual appliance with a newer image – or adding memory –rather than a hardware-based forklift upgrade every five years (with potentially more downtime required).  The ability to shrink or grow a virtual appliance is one of the things that set it apart.  We don’t have to repurchase anything – other than license keys and annual service contracts.  Regrettably, those won’t go away.  But coupled all together with the flexibility to move your virtual appliances along with your data from one environment to another is key.  We will see more and more network-centric appliances become virtualized.  There will most assuredly always be some physical boxes that the network folks can get their hands on, but that will be for access purposes only.

The companies/manufacturers/network-engineers who don’t embrace this trend could quickly find themselves behind the eight ball. Analog phones anyone?

When it comes to the perception of speed, latency, which is the time it takes for a packet of data to get from point A to point B, can either be your best friend or your worst enemy and could make or break any number of cloud-based solutions.

In a cloud-based solution of any kind it would make sense that the amount of data you could move in a second would become less important than the speed at which you could move it.

Think about the user experience, or more importantly where the user’s experience takes place. Let’s use a basic example of a virtual desktop in a co-located hosting facility. The file, email, application and database servers commonly accessed by that virtual desktop are local to the host on which that virtual instance resides. The datacenter fabric technology connecting those resources inside that environment provides 10+Gbps connectivity with less than 1ms of latency providing near instantaneous access. The only data traversing your connection to that facility is interaction and display data, consuming on average a low 128Kbps +/- 100Kbps.

The focus quickly shifts from bits per second to milliseconds of latency and illustrates why a low bandwidth, low latency circuit based connection with a dedicated access rate could provide a better user experience than a high bandwidth shared connection in most cases.

“So what’s the difference? I mean a 45Mbps business class Broadband connection could cost $100 – $300 per month and a 45Mbps DS3 could cost $6,000 – $10,000 per month. 45Mbps is 45Mbps right?” No. Latency is the difference. It’s dedicated access vs. shared access.

Being as it’s not uncommon for oversubscription ratios of 100:1 to exist in business class Broadband ISPs and up to 500:1 in residential, it would make sense that in order to be guaranteed a 2:1 or better subscription ratio you better get ready to pay for it.

There’s good news though. Just like pulling down large amounts of data necessitated the availability of high bandwidth shared internet circuits, the trend of remotely accessing hosted solutions will likely necessitate the need for low latency offerings and as usual, competition will bring more options and better pricing.

Until then, it’s a good idea to understand how you can ensure you’re getting the most out of what you have, and understand how to improve performance without just adding bandwidth. Explore WAN optimization, de-duplication and link management solutions. Talk to the experts about ways to stop the exponential growth and consumption of bandwidth while improving the most important thing of all: The User Experience.

In the majority of indoor WLAN implementations though, you have wide-open areas and lots of variables that affect Radio Frequency (RF) behavior.  Take a hospital for instance – or really any standard indoor office environment.  There are now many obstructions between the transmitting AP and receiving clients (laptop).  Walls, elevators, cubes etc.  These all reduce the signal strength of the radio signal as it is sent out.  A MIMO AP sends out multiple signals – each from a transmitting antenna.  Because those transmitting signals can (and always will) reach the intended receiver via slightly different routes (reflecting off different surfaces), the receiver gets these multiple signals not all at once, but over the course of a few nanoseconds. The ability for a MIMO receiver to collect these multiple streams, and process and use all of them is another large benefit with this technology. Again this benefit is predicated on having a MIMO transmitter and a MIMO client.

What is the benefit to all of this?  The majority, if not all, client adapters being shipped out now are 802.11n MIMO capable. There are still a huge number of legacy 802.11a/b/g clients out there and will be for a few years anyway.  The good from all of this is that they can all cohabitate. The new 802.11n APs being deployed must take into account the legacy devices while also provide the enhanced capabilities mentioned above.  Even in an environment that had 100% legacy, clients are still going to see an increase in throughput, range, and data rates. Beyond that, the more clients used in the space the better off you will be.

As a side note – with these more powerful APs out there that are now capable of 450Mbps+ throughputs, you need to ensure you are giving them Gigabit Ethernet wired handoffs.  Kind of senseless if you have your LAN be the bottleneck – for once!

In order to really get a good perspective on bandwidth utilization we want to take a look at a number of variables.  First and foremost we want some trending data on this environment.  Being able to trend on a WAN interface over the course of time is going to allow us to proactively make informed decisions about upgrades or optimization strategies that could potentially obviate the remediation process before it happens.  This is obviously going to entail some more up front work and some type of monitoring solution.  There are a lot of them out there. 

Not only do we want some trending data – the most important piece to this analysis is not only do we want to understand bandwidth usage patterns; we also want to understand what applications are using what subset of that bandwidth.  Having that application level granularity is going to allow us to make more informed decisions about our infrastructure, the applications running on it and the future direction of all of it.  Multiple vendors support protocols on their WAN routers that can assist us with this; Netflow, J-Flow, S-flow etc.  All require some type of collection device and related head-end application to parse this information and represent it in a nice, graphical manner.  One thing that some don’t consider, and it is common amongst all of these, is the storage implications required to store this data.  Some of these are appliance based while others require some backend database and the storage required to save this raw data.  Depending on how long you want to save it, what the sampling rate is and what the role-ups look like will predicate what you need from a storage capacity perspective.

Lastly, we really should be taking a look at not only bandwidth from a utilization perspective (application-level granularity), but we also need to take a look at some of the other valuable Key Performance Indicators.  Other attributes such as errors and uptime are also extremely valuable in determining immediate and future needs.

The original standards-based PoE was classified under the 802.3af specification.  These devices (mostly switches) provided power for end-devices such as IP-phones, access points, web cams and more.  There are varying levels of devices within this standard based upon the wattage required to run the device.  There are three classes of PoE devices within this spec; classes 1, 2 and 3 – which maxes out at 15.4 Watts.  This has been sufficient for quite some time, but in 2009 a new, enhanced standard was ratified which provides more power – Power over Ethernet Plus or 802.3at can provide up to 30 Watts for what is now known as a class 4 device.

The delta between PoE and non-PoE switches is still significant – especially if you are considering a Power over Ethernet plus capable switch.  If you only require PoE for a few access points or a camera or two it might not be advantageous to spend the extra money for a fully-loaded, PoE capable switch. That being said, if you have VoIP in your near-future plans and are already considering upgrading your access switches, you might want to consider that before you upgrade.  If you are looking at just a few devices though you may be better off getting some PoE injectors, which reside in your data closet and providing Power over Ethernet for the few devices that need it.  They are somewhat kludgy though, and we all have seen messy wiring closets – these add to the chaos.

What about the weather?  Well as we are moving towards a converged infrastructure there are some additional considerations to keep in mind. The PoE switches that are powering your phones and providing data connectivity for your hose devices are becoming more and more critical from a system uptime perspective.  If your voice and data is running over the same infrastructure and you lose power due to – let’s say a hurricane – you had best prepare yourself from an Uninterruptable Power Supply (UPS) perspective.  If your business can’t tolerate having the phones and the network down, then a UPS or a generator is an oft-neglected requirement.  The UPS needs to be sized appropriately based on the Power over Ethernet switches you are using and the end-devices you are powering.  Lastly – all of this is going to incur more of a demand on your electrical system which feeds your wiring closets.  Quite possibly you will have to upgrade the electrical system and have some 30Amp circuits brought in – depending on the switches you have and the UPSes backing them up.

High Availability can occur on many different levels, but for today let’s start with the network core.  This applies to both a three-tier hierarchical design with separate access, distribution and core switches as well as a collapsed-core design in which the core switches provide distribution functionality in the same tier.  We see this method of implementation a fair amount depending on the size of the environment.

The company you have decided on for your switching/routing needs will predicate what option(s) you will have for an HA core.  Broadly speaking, we have two overall strategies in the core to work with.  The first would be a traditional HA pair running some type of highly available redundancy protocol such as VRRP.  This is the traditional approach and is still widely used today.  In a nutshell, one of the two core switches will act as the primary default gateway for host devices.  If that primary core switch fails, the 2^nd core switch becomes active.  Be aware though – with this there will be some minor failover time as this occurs.  We can further minimize this with secondary supervisors (higher cost) in each chassis.  On top of this – if we are running L2 access switches – we also have spanning-tree convergence times that can affect real-time application performance.  As each access switch should be dual-homed to each core switch, we are faced with loop avoidance issues – namely some form of Spanning Tree algorithm.  One of those uplinks will be active in this traditional model and the 2^nd will be passively spanned-out.  If the primary link fails we have redundancy – but depending on what mode of Spanning Tree you are running we are going to have failover times associated with the convergence.

The 2^nd means of providing an HA core, which we are seeing more and more of, involves two core switches which logically can be seen as one core switch.  This is called different names by the various vendors out there that have this type of technology, but in the end it solves several problems.  The first and most important problem it solves is allowing us to obviate the Spanning-Tree issues mentioned above.  From a downstream/access switch perspective, we are still going to dual-home these switches, but now the core appears as one logical switch.  We can create LACP connections now which provide dual-active links rather than having a One-Gig (or Ten-Gig) connection sitting there in a downed state.  Fiber cabling is expensive and Ten-Gig Ethernet is as well.  This allows us to maximize our performance and avoids the loop-convergence issue discussed above.

There are other methods of optimizing your environment to reduce or eliminate convergence times while providing HA such as routing at the access layer, but that is a conversation for another day.  If anyone wants to go down that path and discuss those implications please let me know.