Aruba Networks News

Subscribe to Aruba Networks News feed
Technology Blog articles
Updated: 2 hours 3 min ago

WPA3: The Solution to our Problems?

Wed, 06/20/2018 - 08:00

Recently, I wrote an article about WPA2 and how technology is evolving to the point where what was once a strong, stable protocol is now very vulnerable. Shortly thereafter, the Wi-Fi alliance make their announcements for their focuses in 2018 and they are looking to kick things up a notch this year when it comes to security.

First thing to make note of is that they made mention to the fact that they “will continue enhancing WPA2 to ensure it delivers strong security protections to Wi-Fi users as the security landscape evolves” per their press release announcing their focuses. That announcement was preempting the fact that this year new security protections will be announced as part of the “Wi-Fi Certified WPA3” security protocol. The fact that WPA2 development is not stopping should calm users of legacy devices that are no longer being updated as well as users that may not be able to update devices due to budgetary reasons, healthcare regulations, etc. Concerning the new WPA3 updates specifically though, there were two updates that were announced that I was particularly pleased to see addressed in the way that they were.

Securing Even the Weakest Passwords

One of the main topics that is looking to be addressed within WPA3 is securing network access even when passwords that are used are not very complex. Let’s be honest, the majority of networks out there will not have passwords that look like this: “5r!4VDs{H.zwP_]H”. The main focus of this new method of security is that malicious wireless network users will not be able to hammer away at a network any longer, trying to use a dictionary attack to brute force the wireless network key. This is due to the fact that the process of a multi-step handshake will be redesigned and prevent users from connecting after a certain number of failed attempts. Details on exactly how this will still work are pretty limited at this point, but this alone sounds very interesting considering the recent KRACK attack that targeted WPA2’s handshake process. No doubt that the handshake process will be a focus in WPA3.

 

Securing the Coffee-Shop

The other feature that caught my attention will help wireless network users in places such as coffee shops, sports arenas, and stadiums. Some of the new technologies that will be released will focus on individualized encryption streams over the wireless to help secure the traffic of each individual network user while still being an “open” and inherently insecure network. Bringing security such as this could open the door for exploration into other uses for the wireless networks in a business setting such as different types of payment solutions and more. Without ensuring each network user is secure, some of these ideas may have their development stalled.Credit: Flickr/Nadine Heidrich

 

What’s the Timeline Look Like?

Very few details around the release date of WPA3 and the accompanying technologies have been given during this initial release, but I would make sure to follow the Wi-Fi Alliance and wireless network vendors, like Aruba Networks, for the latest updates on the pending release and implementation guides on this exciting, new, and secure wireless network security protocol.

Tap the App to Make Your SD-Branch Rollout Easy

Tue, 06/19/2018 - 05:00

The time to deploy the new cloud-managed networks is here. You’ve spent countless hours presenting the business value of great branch experiences to corporate management. You wrote the RFP, diligently compared vendors, and chose Aruba Central for cloud-managed networking. Now it’s go-time.

 

Times have changed since you deployed your last network. A rollout doesn’t have to be a logistics nightmare where you juggle spreadsheets or the shipping dates to make sure the right equipment arrives on a specific day. It won’t take months of sweat or a small army of  your IT team on planes to get everything up and running.

 

Aruba gives you the flexibility to plan ahead, use non-technical staff, and know exactly what’s happening in each branch as the equipment goes live.

 

The Benefit of Mobile Apps and the Cloud!

The Aruba Installer app makes onboarding new wired, wireless and WAN equipment simple. An intuitive mobile app workflow even lets non-technical teams perform network onboarding tasks to help offload the corporate IT team. This saves the corporate team from days, weeks, and potentially months spent traveling, and gives them time to focus on the next phase of the project.

 

It also means that you only need one staging location, with a subset of the equipment that you’ll be sending to the branches. Instead, as the gear is coming up in the branch, it downloads the centrally provisioned configuration, which saves a lot of time and cuts down on config errors. No more configuring APs, switches, and gateways, at each of the sites.

 

How It Works

Let's look at how it works:

 

Aruba Central Install Manager

Even before the network equipment ships, someone on the IT team can designate who in each location is allowed to bring the equipment onboard. This way, you have a record of who helped.  This limits someone from gaining access privileges to your equipment, and each installer only sees the setup for their assigned branch location or customers.

 

 

Mobile App

The moment local installers are ready to go, the magic happens. They simply plug in the network equipment, open up the Installer app, and scan a bar code to get started.

 

 

In the image below, the moment the Aruba equipment powers up, it checks into the Install Manager in Aruba Central, which automatically verifies the network equipment is connected and if it’s in the assigned site.  This is zero-touch provisioning at its finest for the IT team. Someone else plugs the equipment in and the installer app let's them see the progress of each device that is power up, and if there any issues. All of this without having to leave their home office.

 

The intent is help reduce the time it takes to deploy equipment, improve IT efficiency and enable IT to do more with less. Think the Aruba Installer App can make your life easier?

 

Let us know in the comments below.

 

Learn More

For those of you who have Aruba Central, simply go to the Apple App store or to Google Play to download the app.

 

If you don’t have Aruba Central yet, discover the benefits of cloud-managed networking.

 

Trent Fierro is director of software solutions marketing at Aruba, a Hewlett Packard Enterprise company. 

SD-Branch Takes the Pain Out of Connecting Distributed Enterprises

Tue, 06/19/2018 - 05:00

A retailer is planning to open pop-up stores to generate buzz among influencers and engage consumers in fun new ways. The business plan calls for a dozen pop-ups across the U.S. every two weeks for the next eight months. The business plan hits a big snag when the IT department gets wind of it. The network infrastructure team simply can’t set up so many new locations so fast. The business team is frustrated that IT has, once again, said no. That frustration is what fuels shadow IT.

 

 

Branch Networking is Too Hard

Connecting hundreds – or thousands – of sites takes too much work. It’s weeks of careful planning. Once all the equipment is shipped out, a network technician is required at each location. It may take several days to set up all the wireless access points, controllers, wired switches and firewalls. A working knowledge of SSIDs, VLANs, 802.1X and other network intricacies is essential. Manual and time-consuming configuration leads to inevitable human error. Not to mention that it can take weeks to get a service provider to provision the WAN connections.

 

To complicate matters, the network architecture for branch offices was codified long before cloud and IoT. With cloud and SaaS, hauling everything from the branch to the data center and then to the cloud is inefficient and makes application performance unpredictable.

 

Retailers, hotels and other distributed enterprises have an increasing number and variety of IoT devices like surveillance cameras, mobile payment systems, environmental sensors and digital signage. It’s been proven time and again that IoT device security is weak, so IT needs to step up security to protect the business.

 

What is SD-Branch?

Over the last several years, software defined networking (SDN) has brought much needed innovation with SD-WAN, but doesn’t address the overall branch experience. With Software Defined Branch (SD-Branch), Aruba is taking innovation to the next level. Aruba’s SD-Branch solution simplifies branch networking at enterprise scale. Aruba takes a holistic approach, unifying policies and making it easier to deliver services and enact security controls to branches across wide area networks.

 

SD-Branch means a better user experience and less IT hassle. The network no longer stands in the way of a retailer’s plans to open pop-up stores. Or a healthcare provider that wants to open up new urgent care locations or onboard a newly acquired physician group. Or a hotel brand that wants to give guests a more home-like experience and save energy with environmental controls managed by a third-party vendor.  

 

Simplicity at Enterprise Scale

The Aruba SD-Branch solution vastly simplifies network management and provisioning, making it faster and easier to connect hundreds – or thousands – of sites.

 

A technician from your local consultant – or anyone who can use a mobile app – can get the network set up quickly and easily. They simply unpack the branch gateway, APs, and switches, and plug them all in. Then they open the Aruba Installer app on their phone or tablet and scan the barcode on each of these network devices. With cloud-based zero-touch provisioning, network setup is on autopilot. The SD-WAN, wired and wireless networks are configured.

 

Ahead of time, the central IT team sets up the configuration templates and context-aware policies through Aruba Central cloud-based management. IT can use Aruba Central as a single pane of glass to simplify and automate network deployment, configuration, visibility and onboarding of SD-WAN, WLAN, and LAN in the branch.

 

Optimized Branch Experience

Context-aware policies ensure that users and devices have the best possible experience based on the applications used and business requirements. Policies are configured centrally by IT, and are pushed out to each site to offer a differentiated experience for employees, guests and IoT devices – connected via wireless or wired.

 

To inform that branch experience, the network feeds back granular intelligence about user roles, device types, applications and WAN health metrics. The network proactively makes quality of service and routing decisions based on multiple sources of network context and by monitoring application health in real time.

 

That allows a hotel chain, for example, to give a guest’s iPad streaming Netflix a higher priority over the hotel’s primary broadband connection, but if the broadband quality degrades, the traffic can be automatically moved to a secondary active link. Or it can ensure that all back-of-house traffic goes through the private MPLS connection to assure consistent service levels and the highest protection.

 

We can further optimize the branch experience with our new Cape Networks solution. Cape’s cloud-managed sensors monitor application performance from an end-user’s perspective and feed real-time data into a centralized dashboards, so IT managers know about problems before the helpdesk phones start ringing. IT has visibility into mission-critical applications and issues such as poorly performing WAN links or outages and can reconfigure policies to respond.

 

Integrated Security

Aruba ClearPass, as part of the 360 Secure Fabric, maintains context-aware policies for all user and IoT devices, as well as those used by guests and contractors across distributed enterprises. Branch gateways gain this context and then act as the enforcement point for traffic over the WAN and within the branch itself by segmenting traffic.

 

That means, for example, surveillance cameras at all of a hotel’s properties can be governed by  a consistent policy. If an attacker hijacks a camera, the suspicious behavior will be identified and the attack can be stopped before it spreads to other devices or across the enterprise. Or a quick-serve restaurant can install smart ovens with confidence, reaping the benefits of predictive maintenance alerts while mitigating the risk of the corporate network being breached through a third party vendor.

 

With SD-Branch, enterprises also can take advantage of network segmentation to further enhance security and assure the user experience. With dynamic segmentation, we are taking what we did with APs and controllers and bringing them to Aruba switches to bring them under a single, consistent management and policy domain. It doesn’t matter how a device connects – the appropriate policies are applied.

 

Aruba’s SD-Branch solution integrates with other best-in-class security solutions, including Zscaler, Check Point and Palo Alto Networks for cloud-based firewall, sandboxing and SSL inspection.

 

Ready for the Digital Workplace

For retailers, hotels and other distributed enterprises, Aruba’s SD-Branch solution simplifies IT while delivering a better user experience.

 

Now, when a retailer wants to open dozens of pop-ups in a few weeks, the network can be set up in hours, not days or weeks. And with IT as strong partner of the business, the marketing team can focus on getting loyal customers and influencers to share their brand experiences on Instagram – and drive in-store and online sales.

 

Dave Chen is a product marketing manager at Aruba, a Hewlett Packard Enterprise company.

 

Like this blog? Give it a thumbs up or share it on social media using the buttons below. 

Onion Approach to WiFi Troubleshooting Basics - Jumping To Conclusions

Mon, 06/18/2018 - 07:00

In this onion approach to WiFi troubleshooting basics we will be discussing jumping to conclusions during WiFi troubleshooting. 

 

Nothing is never really cut and dry when you troubleshoot wireless issues. 

 

Let me give you a few examples:

 

In the wired world its rare that you miss a packet during a trace. In the wireless world there is a very high probability you will miss frames during a trace. To an untrained eye some folks start down a rabbit hole! I missed a frame(s) that has to be my issue! 

 

You are called in on a WiFi voice jitter troubleshooting issue. You analyze the fames and you discover the phones aren't marking QoS. Immediately you declare victory only to learn after fixing the QoS markings the issue is still not resolved. 

 

People are complaining about drop wireless connections. They mention they have low wireless bars. What do you do, add more access points. Only for the issue to continue. 

 

Users cant connect to the network and you’re first thought is to reboot the controllers and access points, because of course that has to be the problem. And if that doesn't work then reboot the radius server! 

 

 

Friends it is very important not to get excited when you start to see something strange and declare a premature victory. If you aren't sure what the issue is it is very important to understand the problem. Reproduce it. Then make the needed tweaks to to resolve the problem. It is so easy to jump to conclusions and find yourself down a rabbit hole. It is also best to put boots on the ground to see the issue first hand. Users can sometime exaggerate and make the problem worse then it really is. Boots on the ground gives you first hand real life exposure to the problem.  

 

There are plenty of gotchas in wireless and there are even more rabbit holes to go down. Practice patience when troubleshooting. 

 

The Future of Wi-Fi Things

Wed, 06/13/2018 - 11:55

I can remember a time long ago when wireless networking was about freedom. It was all about setting up a few wireless clients to be able to roam around a building or home far and wide. The first time I ever saw an 802.11 card being tested was one of my co-workers using it to work from a park area in the middle of one of the buildings I worked in. I thought the idea of having no wires was neat but that it wouldn't take off as long as people still needed a desk.

 

Flash forward fifteen years and I couldn't have been more wrong. Today, wires are the exception to the rule. Even at my desk I have most of my devices connected via Wi-Fi instead of Ethernet. The freedom is still there for me, even if the device never leaves my desk. But the use of Wi-Fi in my house has changed as it has in many other businesses.

 

Wireless isn't just about far-ranging freedom now. It's about device density. Instead of me picking up my laptop and walking down the hall to use it in a classroom I'm now more concerned with how many devices I can bring with me. It's more than just one laptop. Now, my laptop, phone, watch, tablet, and even more personal devices need to connect to a wireless network. As a tech person I have a large number of things with me at all time that want to upload data, get control settings, and update me on the latest news and statuses.

The Things To Come

More than the personal devices we use actively every day are the devices that are coming online that we don't interact with regularly but control our very environment. For every wireless laptop, there are a legion of Internet of Things (IoT) devices that you don't realize are using your wireless network. Thermostats, light bulbs, smart outlets, doorbells, and more are being installed daily.

 

But did you know about the wireless networks we don't see? The networks created by cable box digital video recorders (DVRs), smart electrical meters, and other home entertainment systems. Those networks compete for the very same airtime that your other smart devices and computing devices want to use as well. And while you have a measure of control over your own personal devices, that ability tails off as the devices become more simple and easy to use. Smart thermostats have very little programmability from a network perspective. Smart outlets don't even have an interface to use outside of a mobile app.

Designing For Things

The IoT devices in your home and workplace represent the biggest shift in the future of Wi-Fi coming in the next 5 years. It's changing the way that wireless networks are designed. Now, instead of trying to build for coverage over a wide area, we're building smaller networks with higher density. These high density deployments used to be for high traffic areas like arenas and conference centers. Now, every school hallway has enough device traffic to justify a very high density deployment. And as the number of smart infrastructure devices increase, the amount of clients connected to these networks increases as well.

 

Wireless professionals have to be smart about how they handle smart devices. Solutions like air gapped networks like those from cable companies and power companies only work when the airspace is relatively free. But in an enterprise, all channels and frequencies are going to be very heavily utilized. That means all those smart devices will be on your network. And you need to plan for them. You need to be aware of the requirements and the capabilities.

 

It also means that device vendors and other departments of your organization need to be more aware of the load that those devices can put on the network. Gone are the days of thinking that any wireless device will do. Now, the frequency and utilization specs need to be known at a minimum. Well-built networks shouldn't be taken down by devices that are misbehaving. Likewise, a well-planned network shouldn't be compromised because a cheap new fire alarm panel needs 802.11b data rates in 2018.

 

Wireless professionals are going to be challenged by the future of wireless. Whether it come from new protocols or a dearth of devices using existing networks, you need to be flexible and ready to build the network your clients need. Even if those clients are devices that no one uses frequently. Every device will matter in the future.

Onion Approach To WiFi Troubleshooting Basics - Three Areas of Focus When Troubleshooting WiFi Issue

Wed, 06/13/2018 - 06:57

Hello and welcome back to another Onion Approach To WiFi Troubleshooting. I wear multiple hats as a WiFi engineer and you probably do too. WiFi is a black box to many folks and because of this, it’s easy to blame when WiFi users have problems. If you spend any amount of time managing a WiFI network large or small you know what I’m talking about. Troubleshooting WiFi isn't necessarily difficult if you know where to look. As WiFi engineers we aren't afforded the luxury of plugging in a cable and it just working. 

 

When issues arise do you know where to look after you do your initial discovery?

 

You just completed your initial discovery. You spoke to the users and collected your notes. You may or may not be able to reproduce the issue. Where do you go now?

 

There are three main areas you should consider as your next steps to troubleshooting. We need to look at what the device says, what the ap/controller says and last but not least OTAC over the air captures. Many times when you combine the data collected from all three a story starts to develop. 

 

Lets dive in !

 

WiFi DEVICE

 

It is no secret WiFi clients are the bane of our existence. Because there is no teeth in the 802.11 standard specific to WiFI client function and behavior vendors can choose to implement their own secret sauce. When looking at the WiFi device here is a short list of items to looks at:

 

  • Window Event Logs 

 

While the event codes may not be consistent between REVs of NIC (ie Intel 7260, 7265, 8260) you can start to collect the codes for each NIC. The event logs will paint a picture specific to what the OS and WLAN is doing. 

 

Nurse Betty got kicked off the WiFi network around 11:30pm. Check the log and see what it says are that time. You might be surprised what you might find! 

 

Recently we fought an SSO (Single Sign On) issue. The SSO logs showed it didn't have network connectivity to authenticate to the vault, but the windows event logs showed it authenticated and pulled an IP address. Of course the application folks blamed the WiFI network. The event logs allowed us confidence we can send this issue back over the fence to have the SSO application folks to relook at their problem. 

 

  • NETSH commands 

A quick google search of NETSH and you will find a lot of resources including blogs and videos showing how to use NETSH and the commands. You can pull a considerable amount of information from the driver.

 

CWNP’s Tom Carpenter did a great video to help you get started:

https://www.youtube.com/watch?v=vYbtiY3bnTM

 

I had the privilege of speaking at ATM15 Ten Talk on the subject of WiFi drivers and devices. 

https://www.youtube.com/watch?v=CT42g8l56LE&t=25s 

 

Remember what you are seeing from this side is only one view of the overall picture. It is the WiFi clients perspective of the network.

 

AP/CONTROLLER 

 

  • DEBUGS

No big surprise here. When you have wireless issues most folks start right here. Many times you can find clients misbehaving, failing authentication, and doing odd things. Remember what you are seeing from this side is only one view of the overall picture. It is the controllers perspective of the client. 

 

OTAC (OVER THE AIR CAPTURES) 

 

I can tell you from years of experience radios (clients / aps) may say they are behaving per their logs, but sometimes the frame captures tell a different story. Frame layer analysis requires a particular skill set and special software and hardware to collect frames over the air. 

 

If you want to learn more about 802.11 frame analysis check out my ATM15 Packets never lie: An in-depth overview of 802.11 frames

https://www.youtube.com/watch?v=Kn4hVq5vI3E 

 

Remember what you’re seeing from this side is what both sides are saying. Warning — don’t jump to conclusions or have a knee jerk reaction based on what the frames are showing. You want to collect all the information from all side to have a good perspective. 

 

Why an Open System Architecture Matters

Mon, 06/11/2018 - 10:00

This blog is written by Jim Metzler, founder and vice president of Ashton, Metzler Associates.

 

The movement on the part of virtually all companies to become a digital business, to fully empower mobile employees and to leverage the data collected by the IoT are just some examples of the types of ongoing changes that businesses are constantly undergoing. The primary goal of an IT architecture is to link a company’s business and operational objectives with both the IT infrastructure and the applications that the infrastructure supports. By creating this linkage, an IT architecture ensures that an IT organization can respond to constantly changing business requirements, such as the ones previously mentioned. An architecture also ensures that an IT organization can respond to emerging technologies, such as the adoption of a continually increasing array of software defined functionality, without a significant increase in cost, complexity, or risk. This blog will discuss some of the key concepts that underlie an IT architecture and will use a mobile architecture to exemplify these concepts.

 

The 2018 Guide to WAN Architecture and Design highlights some of the challenges that IT organizations face when they attempt to adopt new technology and don’t have an effective architecture. According to that document, organizations that have already deployed a software-defined WAN (SD-WAN) reported that one of the major drawbacks of that deployment is the complexity of physically integrating the new SD-WAN with the existing WAN. For most IT organizations that complexity is just a small part of the overall complexity of implementing new functionality such as an SD-WAN which was not designed to seamlessly interface with the rest of the organization’s infrastructure, management or security.

 

As part of creating an effective architecture, IT organizations must answer four primary questions.  Those questions are:

  1. What are the major components of the overall task of providing IT?
  2. What is the scope and what functionality should be contained in each component?
  3. What technologies and protocols should be used to provide the functionality?
  4. How should the components interface with each other?

Because there can be a wide range of organizational goals and structures, there is some flexibility in terms of how an IT organization defines the major components of the overall task of providing IT. However, given the ongoing growth in the number of mobile workers, it is difficult to imagine a current IT architecture that doesn’t have mobility as one of its primary components.

 

In view of the broad movement to adopt applications built on the IoT, the scope of the mobility component of an IT architecture must cover both users and things. To minimize complexity, the architecture must include functionality that enables users and things to experience the same policies and permissions whether their connection to the network is wired or wireless. To respond to the growing sophistication of hackers, the architecture must also include several layers of security functionality.

 

The title of this blog identifies a key characteristic of the technologies and protocols that should be used in an IT architecture. That characteristic is that they must be open. In sharp contrast to the alternative, an open system architecture is a vendor-independent, non-proprietary architecture that is based on official or popular standards for technologies and protocols. One of the key advantages of an open approach to architecture is that it allows all vendors to create add-on products that increase the overall flexibility, functionality, inter-operability, potential use and useful life. In terms of how the components of an architecture interface with each other, the answer is the same. These components must interface using open APIs. An Open API is a publicly available API that provides developers with programmatic access to applications and/or web services.

 

Occasionally a vendor argues against the adoption of an open architecture that enables an IT organization to implement functionality from multiple providers. The argument these vendors usually make is that an architecture based on proprietary functionality from a single vendor is somehow more efficient. This argument was refuted in a recent article by Gartner which states that vendors tend to promote end-to-end network architectures that lock-in clients with the vendor’s solutions. To avoid that lock-in the article recommends that IT end users should always adopt multi-vendor network architectures that are based on industry-standard elements. 

 

Nobody would argue that the pace of either business or technology evolution is likely to slow down any time soon. To ensure that they can meet the continually evolving business requirements and seamlessly integrate new technologies, IT organizations must implement an end-to-end IT architecture. To be able to use best of breed products throughout the IT infrastructure and to avoid vendor lock-in, the architecture must feature open technologies, protocols and interfaces.

 

Jim Metzler is founder and vice president at Ashton, Metzler Associates.

 

Like this blog? Share it on social media or give it a thumbs-up using the buttons below.

 

 

Onion Approach To WiFi Troubleshooting Basics - Testing Voice Applications 1…2…3...

Wed, 06/06/2018 - 06:34

Voice over WiFi is one of many sensitive applications used over WiFi networks today. In some environments like Healthcare voice is critical. When a caregiver hits dial on a phone it has to go through there is no compromise and no forgiveness. In my environment we manage over 3,000+ WiFi voice handsets.

 

Either testing a newly deployed network or a suspected problem area the easiest thing you can do is validate the network with the actual voice handset.

 

Over the years you build a process that works for you. In this onion approach I will share my approach validating a the voice application. 

 

Here are two approaches:

 

Two Person Testing 

 

When testing in a team one user uses a wired LAN phone and the other a voice WiFi handset. We determine the test area as a team. The user testing the voice WiFi handset will walk the area and start the count. The user on the voice WiFI handset will start with  (1), the user on the LAN phone will follow with (2), the user on the voice WiFI handset will follow with (3) and so on. 

This test allows for both users to evaluate upstream and downstream traffic. It also allows you to hone into specific areas when you hear issues with call quality like roaming pops, lost words, or even drop calls. It is important to test with a known working phone first. Then test with the users phone. This helps to identify any possible issues with broken phones. 

 

Try and avoid voice WiFi handset to voice WiFi handset testing as your initial test. As you might imagine if you have issues it might be difficult to determine which user and handset had the problem and where. 

 

1 Person Testing 

 

Solo testing presents some challenges but nothing we cant overcome. Here are a few options to test by yourself. 

 

Using the voice WiFi handset you have a number of options. While these options only test downstream, meaning traffic coming to you, it is better then nothing.

 

You can: 

Call an outside weather station with a recording 

Create a test tone on a LAN phone 

Call a LAN phone and play a radio next to the phone 

 

BYOD in a HealthCare Environment

Mon, 06/04/2018 - 11:45

The Risk You Always Knew Was There.

 

BYOD, or bring your own device, is a concept that is becoming very common, whether you are a small office or a large enterprise. The fact that there are so many outside devices trying to gain access to your network is something most, if not all, network administrators are concerned with daily. It used to be that administrators were only concerned with intruders, but that is changing now with this new age of technology with so many connected devices. From tablets to smartphones to laptops, most people have some sort of connected device on their person whenever they are on the go. Simply denying access to these devices is no longer a valid solution. That being the case, these devices can pose a risk to the network and mitigating that risk is the challenge.


(Photo by mikecogh/Flickr)

 

Common Uses of BYOD in the HealthCare Workspace

 

Due to patient information, billing information, and other private data, healthcare workspaces need high amounts of security and segregation when it comes to different networks within their building. It used to be easy in the past to say, “authorized devices only” were allowed on the network, but now that is not the case. Some common examples of why this is not the case anymore are:

 

  • Patients and visitors
  • Vendors
  • Employees with personal devices

 

Patients and their visitors spend a lot of time in hospitals and with the dependency people have now regarding their connected devices, denying network access to them is a quick way to decrease patient satisfaction. Making sure these visitors have connectivity is important to keeping them happy and occupied whether they are a patient that is admitted or a visitor simply waiting for an appointment. These devices need network or web access while ensuring they are not able to access critical hospital systems.

 

Vendors are similar as well. Say you have a vendor providing support on their storage solution for instance. When onsite, their engineers need network access to be able to diagnose and resolve any issues that arise. That doesn’t mean they need wide open network access though. You, as the network administrator, need to provide access only to the things these types of vendors specifically need.

 

Employees are another perfect example. They have their own valid network logins and may know the business wireless SSID for instance. They may want to watch Netflix on their lunch break. Without regulation and profiling, their personal tablet could not be on the same wireless network as hospital controlled devices handling patient data. Not secure nor something we as administrators would want to happen.

 

The Answer: Device Profiling

 

Aruba has a product called ClearPass which is an access management system that would assist with BYOD devices such as the examples I listed above. In terms of guest users without a login, custom portals can allow users to get connected after agreeing to your specified terms and conditions. This would all happen while keeping them segregated on a dedicated guest network. The real benefits though come when you have a user with a valid network login such as an employee or vendor. With Aruba ClearPass QuickConnect, users can walk themselves through getting their BYOD device connected, whether it is wireless or wired, without any needed intervention needed from the IT staff. From there, any policies that you, the administrator, have configured will be applied to the device. If there are any changes that are required before the user can connect, such as critical security updates, the user will be walked through those as well. The overall goal here is self-provisioning of BYOD by the users while still maintaining ultimate control as the administrator.

 

The Future of BYOD

 

Today, network administrators are making great strides to provide connectivity to all devices while maintaining security. Looking at the progression from the past into today, it is clear this task will only become more important. The future will provide the challenge of scalability though. With more and more devices coming on the grid each day, the time to focus on network security in the BYOD space is now. The longer we as network administrators wait, the more devices we will need to contend with.

Which Should You Upgrade First: The WAN or the Branch?

Mon, 06/04/2018 - 10:00

This blog is written by Jim Metzler, founder and vice president of Ashton, Metzler Associates. 


About two years ago I was contacted by the network organization for a large enterprise. The enterprise has over 3,000 branch offices and they wanted my help with a project to upgrade both their WAN and the networking functionality inside their branch offices. It was a challenging project to organize in part because of the extend of the functionality that it encompassed and in part due to the rapidly evolving nature of the enabling technologies. One goal of this blog is to describe the overall project plan we used and another goal is to suggest the changes that I would make to that plan if we were starting fresh today.

 

Breaking the Project into Two Pieces

A lot has happened in the IT industry over the last two years. That is particularly true relative to the development of solutions that apply the concepts of being software defined to the WAN and to the branch office. Today many such solutions are being evaluated and adopted. However, two years ago the wave of articles and reports that preceed the development and adoption of any new technology were just beginning to be written about Software Defined WANs (SD-WANs). At that time little if anything was being written about fundamentally new approaches to branch office networking in general and nothing was being written about Software Defined Networks for branches.

 

The fact that SD-WANs were just beginning to be a hot topic and that new branch office solutions were virtually nonexistent was one of two key factors that caused us to make a couple of fundamental decisions relative to how we ran the project. One decision was to split the project into two components, a WAN component and a branch office component. The other decision was to finish the WAN component prior to starting the branch office component.

 

The second key factor that drove us to split the project into two components was our desire to not take on a project that was so all encompassing that it would take an unacceptable amount of time to complete. Adding fuel to that concern was the realization that back in 2015 there was little if any overlap between the providers of SD-WAN solutions, which were primarily small start-ups, and the providers of branch office networking solutions. Because of that, if we didn’t split the project into two components it would have required us to simultaneously interact with two very different sets of vendors.

 

Creating a Mini-RFI

One common way to approach a project like the one described above is for an enterprise network organization to issue a Request for Proposal (RFP) to a wide array of vendors. In addition to containing a broad range of questions about the vendors’ products and services, RFPs typically ask the vendors to provide detailed network designs and/or detailed pricing. After reviewing the responses and holding face-to-face meetings with some or all of the vendors, most network organizations then issue a second round of questions to a short list of vendors. If the network organization is satisfied with the answers to those questions they typically go forward with a Proof of Concept (POC) trial with one or two vendors. Because of the complex steps that are involved, an RFP-based evaluation project consumes considerable resources and typically takes nine months to a year from the start of the project to when a POC begins.

 

In contrast to an RFP, a Request for Information (RFI) is often less lengthy than an RFP and it doesn’t ask vendors to provide detailed designs or pricing. Since my client had no interest in a lengthy, resource consuming project we went forward with a process based on creating and distributing a small, highly-focused RFI, which we referred to a mini-RFI. Part of my role on both components of the project was to provide my client with a high-level summary of the feasible vendors. My client then used that summary to select a small set of vendors to receive the mini-RFI.

 

One of the goals that my client established for each component of the project was to use a mini-RFI to quickly get to where they were starting a POC and to use the POC to resolve any unanswered questions about what a solution did and how well it performed. While we have not yet finished the mini-RFI that is associated with the branch office component of the project, we are on track to achieve that goal in this component of the project. We achieved that goal with the mini-RFI that was part of the SD-WAN component of the project as it took us just over three months to go from the start of this component of the project to beginning a POC.

 

Evaluating What I Would Do Differently

An evaluation process based on an RFP is the right choice for some organizations in some instances. However, I tend to prefer an evaluation process based on an RFI or a mini-RFI and if I was starting this project fresh today, I would recommend taking that approach.

 

However, breaking the project into two components, which made sense at the time, is not something that I would do again. The reason for that is that we have recently seen the introduction into the market of unified branch solutions. These solutions provide several benefits, including the cost savings that are associated with SD-WANs and the benefit that is of upmost importance to my client – minimizing the complexity that is associated with managing networking in thousands of branch offices. One of the ways that branch-wide solutions reduce this complexity is by enabling all the branch office networking functionality with a single policy that is administered centrally. This includes the wired LAN, the wireless LAN and the WAN. In a growing number of instances, the WAN component of these solutions is an SD-WAN.

 

If I were starting fresh today I would have one project that encompassed both the WAN and the rest of the branch office networking functionality. As before, I would create for my client a list of feasible vendors. This time, however, the vendors would be vendors who provide viable branch-wide solutions that include SD-WAN functionality.

 

 

Jim Metzler is founder and vice president at Ashton, Metzler Associates.

 

Like this blog? Share it on social media or give it a thumbs-up using the buttons below.

 

Bandwidth limit enforcement on AccessPoint

Thu, 05/31/2018 - 13:28

WiFi networks are usually deployed to provide best coverage and performances for clients. In some cases performances of a single client must be reduced to allow a better average experience for all clients.

 

This example can be applied to public hotspot networks, fairground, conferences etc.

 

The goal is to provide enough bandwidth for each client without allowing someone to take advantage of the free bandwidth for uses outside the scope.

 

Per-client bandwidth limit can be applied and enforced on the wireless network itself or on the wired portion of the network, on a router, firewall, L3 switch or any uplink devices between the wireless controller and Internet.

 

Sometimes documentation about how the limits are enforced are not clear and there are some doubts where the enforcement should be applied for better results. There are many variables involved but some tests may help to clarify.

 

Let’s start with some over-simplified description of the two types of retransmission involved before proceeding further.

 

WiFi retransmission

 

It’s well known that any unicast frame on a WiFi network must be acknowledged. This includes UDP and TCP frames, it doesn’t matter upper protocol used, we are on Layer 2 here.

 

When a frame is not acknowledged it is retransmitted multiple times before being considered “lost”. Once the frame is lost upper layer protocol may take care of it and decide to retransmit again (in case of TCP), or simply give up (UDP).

 

If clients must transmit each frame multiple times to get them acknowledged the load on the cell will increase while reducing the overall throughput of the single cell. This is bad.

 

TCP retransmission

 

TCP is a connection oriented L3 protocol. That means if a packet is not acknowledged it will be retransmitted. Do not confuse this with WiFi retransmission. TCP/IP retransmission works end-to-end while WiFi retransmission works on the L2 scope of the single WiFi cell.

 

Bandwidth limit enforcement

 

Generally speaking when per-client bandwidth limit (policing) is applied on a wired network packets sent above the threshold speed are dropped.

 

But what happens when bandwidth limit is applied on the AP?

 

Let’s do some tests.

 

Testing environment

 

Testing environment includes:

 

  • Aruba AP 225 running latest available firmware
  • Wireshark 2.4.3
  • Test client - laptop with Intel AC7265 Wifi card and updated drivers
  • Router for wired traffic policing
  • iPerf3 for traffic generation
  • Metageek Chanalyzer 5.9.1.10

 

To simplify the tests a single 20MHz 2,4GHz cell, standard 802.11n is deployed. The test client is the only one connected to the AP.

 

Wireshark runs on the wired iPerf server. Wired and wireless traffic are collected by Wireshark. Two graphs are created, one showing WiFi retransmissions in red (Wireshark filter wlan.fc.retry eq 1) and one showing TCP retransmissions in green (filter tcp.analysis.retransmission).

 

The traffic generate for testing with iPerf is TCP to allow the measurement of retransmissions.

 

Metageek Chanalyzer with Wi-Spy and Ekahau NIC-300 USB are used to measure the channel use.

 

 

 

 

Running the tests

 

The first test is run to get a baseline to understand how the network behaves with a single client connected.

 

Results are embedded in the screenshots.

 

 

The following test show channel use, TCP and WiFi retransmission when per-client bandwidth limit is applied on the Access Point:

 

 

 

 

The following test show channel use, TCP and WiFi retransmission when per-client bandwidth limit is applied on the router placed between the Access Point and the iPerf server:

 

 

 

 

 

Results

 

The graphs show that TCP retransmission only happens when bandwidth limits are applied on the router. This means the limit applied on the AP works with different mechanism and does not drop TCP packets.

 

The channel use when different bandwidth limits are applied on Access Point and on the router show that the AP enforcement performs better:

 

 

 

Wrap up

 

The results shown here can be a good starting point to consider when designing a WiFi network that needs bandwidth limits to be applied to client traffic. It is recommended to repeat the test with the AP and clients actually used in production network to verify results are the same with different devices.

 

In this specific case it appears the AccessPoint can be trusted when applying per client bandwidth limits resulting in lower channel use and no TCP packet drops.





What Will 802.11ax Bring To Your Airspace?

Wed, 05/30/2018 - 09:17

The industry is on the cusp of a new wireless protocol. It's been almost ten years since 802.11ac was proposed, and five years since final ratification. 802.11ac has been built upon to deliver speeds past 1 Gpbs and has become the preferred method of wireless connectivity for computers and mobile devices alike.

 

However, 802.11ac exposes many of the problems we have with Wi-Fi coverage that is just faster. As Wi-Fi has become the primary method of connectivity for a range of devices we've seen how the protocol breaks down under certain conditions. We've seen how the accumulation of little issues can keep our speeds down and how simply making things bigger and faster won't fix them. That's why 802.11ax is taking a much firmer hand in directing wireless traffic.

Making Lanes For Data

One of the biggest changes in 802.11ax is the addition of Orthogonal Frequency-Division Multiple Access (OFDMA). That's a fancy acronym that describes the way that 802.11ax handles sub-channel communications. We've seen that the explosion of wireless devices in the past years has meant that there are many, many more devices trying to talk to the an access point (AP) at any one given time. This means that there are a lot of clients waiting in line to deliver and receive data.

 

In 802.11ac and earlier protocols any transmission has to use the entire channel to transmit or receive. That doesn't mean much if you have a relatively skinny 20 MHz channel width. But if you've cranked the radio all the way up to 160 MHz, you're sending 8 times the data but still using the entire channel no matter the size of the packet. This is inefficient and wastes valuable time that could be used by other clients.

 

802.11ax changes things by dividing those channels into a collection of subchannels. This allows data to be transmitted in parallel across a series of smaller channels instead of taking an entire wide channel for small things like acknowledgment (ACK) frames and such. For small packets, this means that a client can transmit and only use the necessary amount of bandwidth for their frame. This means they get off the air faster and can let the AP utilize those other subchannels for other clients.

 

For larger packet sizes, splitting things into a group of parallel transmissions saves transmission times versus sequential transmission. Research indicates that this could be up to three times faster for simple parallel versus sequential transmission. An increase in speed of 3x is nothing to sneeze at!

 

The best part is that these changes are in both the 5 GHz and 2.4 GHz spectrum. 802.11ac focused only on 5 GHz and left users of the older 2.4 GHz spectrum out in the cold. With 802.11ax, we're going to see improvements across the board. Much like the older 802.11n standard, even clients that don't support 802.11 ax should see an improvement thanks to better handling of transmission and such. This should really be helpful to the exploding Internet of Things (IoT) market, since most of those devices rely on inexpensive 2.4 GHz radios.

Waiting For Your Turn

The other thing that makes 802.11ax much more efficient is the idea of uplink scheduling. This is a method that allows the AP to decide who can transmit, what times they can transmit, and which channel/subchannels they can use. The analogy that is frequently used is of the air traffic control system in commercial flight. By having someone monitor and schedule takeoffs and landings you can serve a much larger flight schedule than if planes got to choose their own times.

 

Wireless clients are greedy by nature. They want to send their data right away and get a response as soon as possible. The interrupt-driven nature of communications makes it difficult for an AP to serve a large number of clients without eventually grinding to a halt due to the large amount of crosstalk and interruptions.

 

With uplink scheduling, the wireless AP can make sure that those interruptions don't happen very often. The scheduling algorithm on the AP can give clients a transmission window for sending large payloads. It can also choose when to answer client requests as well as sending partial acknowledgments to keep the clients happy while waiting for payload delivery.

 

Uplink scheduling also means that you can save battery power as well. By telling the client when they can transmit, the AP can also instruct the client to power down their radio until that time. Even if they schedule has the radio powered off and not transmitting for a few seconds those few seconds add up over the course of the day. Just like OFDMA, the little optimizations add up to make things better overall.

 

The future of 802.11ax is coming sooner than you think. APs and client radios should be out in the early part of 2018 ahead of ratification of the standard. That means you still have some time to take in what's being proposed and decide what your upgrade strategy is going to be. If you have a lot of high density clients or have many clients that still operate in the 2.4 GHz spectrum the move to 802.11ax should be an easy "yes". As for the rest, it's going to take time and research to find out if 802.11ax is going to give you the control you want at the price that's right.

Turn Off Your AP's??? You Should Try It.

Tue, 05/29/2018 - 12:45

Every tech conference is responsible for providing a wireless network for a large number of devices its attendee's tote with them. When that conference is put on by Aruba, a Hewlett Packard Enterprise Company, keeping the network up and usable is an absolute priority.

 

Some companies live and die by the uptime metric maintaining a hands-off approach unless something is broken. To them, the network is proof that they can meet their customers every expectation, real or imagined. At Atmosphere, Aruba takes a different approach. Instead, they see the conference network as a big, real-life lab, and they like to experiment.

 

During the day two keynote Partha Narasimhan, Aruba's CTO spent a few minutes talking about one of those experiments. The experiment asked the question: Can we dynamically turn off access points when unneeded for capacity? Aruba used data provided by their product NetInsight along with the conference schedule to make those decisions. It made for a compelling story, which is even more compelling once numbers are applied.

 

Many wireless engineers understand the vast difference between providing adequate coverage and adequate capacity. In carpeted office space, that may only be a two or three-fold increase in the number of required AP's. However, in many Large Public Venues (LPV) that increase may be six or more times.

 

This conundrum is further exacerbated by the fact that many wireless networks only need capacity coverage for a portion of each day. In carpeted office space, that may be 12 hours each day. In LPV, the capacity coverage may only be needed for 12 hours each week!

 

Currently, our wireless networks are incapable of adjusting to these needs, and that is where Aruba's experiment comes into play.

 

Each access point pulls approximately 20 watts of AC power after accounting for POE loss in ethernet cables, power backup, cooling, and AC/DC conversion. Twenty watts of power isn't a lot. But once you consider the number of AP's in many enterprise organizations or LPV's that adds up quickly.

 

Each AP using 20 watts of power consumes 175kWh of energy each year. The average US commercial power rate is $0.1047 per kWh, which brings the per AP power cost to $18.32 annually.

 

The national average CO2 footprint of each kWh is 1.222 lbs. Thus, each AP is responsible for 214lbs of CO2 annually.

 

To further explore the implications, let's walk through two examples.

 

First, a large enterprise environment with 500 AP's at locations spread across the US. During the evening, after most employees have left for the day, half of the AP's can be powered down for 12 hours while still providing full coverage of each facility. Powering down 250 AP's for 12 hours each day saves 21,900kWh of electricity.

In this scenario, our annual run-time costs reduce by $2,290. Our annual CO2 footprint reduces by 26,750 lbs.

 

 

 

Our second use case involves a multi-use LPV. It has 450 access points needed for full capacity, which occurs for 20 hours each week. During non-capacity hours, coverage for all occupied spaces requires 100 active AP's. By powering down, AP's the venue saves 53,872kWh each year. The run-time costs reduce by $5,640 and the carbon footprint by 65,831 lbs of CO2. 

 

Aside from the financial and ecological savings, the simple elegance of the solution requires mentioning. Aruba plans to use NetInsight to enable those AP's automatically anytime they are needed for capacity, which simplifies scheduling and ensures the facilities manager or network team have one less thing to consider.

 

Furthermore, without the signal attenuation provided by guest and attendees, a wireless network built for capacity is a highly non-optimal coverage design. As NetInsight disables AP's across a facility during non-peak times, co-channel contention and SNR metrics will improve. That ensures users who are on the coverage based network have the most available airtime and enhances their user experience, proving the mantra, "Less is more."

 

Disabling AP's based on demand was one of the many experiments which Aruba ran on the network during Atmosphere 2018. It might not be as flashy or as technically significant as some of the other items which Partha discussed. But, it has the potential to make a considerable impact on run-time cost, carbon footprint, and the user experience of many wireless networks.

  

[1] Aruba AP340 Specifications

http://www.arubanetworks.com/assets/ds/DS_AP340Series.pdf

 

[1] Average Commercial Energy Price for January 2018 https://www.eia.gov/electricity/monthly/epm_table_grapher.php?t=epmt_5_6_a

 

[1] Average CO2 emissions per KWH
https://www.epa.gov/sites/production/files/2015-10/documents/egrid2012_summarytables_0.pdf

Friesland College to Achieve 166% ROI Savings with the Aruba 8400 Solution, According to IDC Study

Tue, 05/29/2018 - 09:00

Today’s higher education needs are changing. Students expect a seamless, always-on network experience whether they are in a study lounge, football stadium, or dormitory. More users need to be on the network at all times, sharing files, voice, and video. With these new trends in the education realm, IT teams are looking for more intelligent solutions to keep up with today’s network challenges.

 

 

The Netherland’s Regional Training Centre

Friesland College is a vocational school in the Netherlands that has more than 10,000 students and 1,300 faculty members. When Friesland refreshed its aging network with a private cloud solution that offered mobility tailored to collegiate usage, it decided on Aruba’s core switching solution for its software-defined capabilities such as programmability, automation, and analytics. Our Aruba 8400 core solution is one of our newest innovations in the campus core and aggregation space.

 

Before the refresh, every building had its network and IT support team. Each team managed countless servers and could feel the weight of new methods of network usage such as video streaming, new education technologies, and online course offerings. When Friesland was ready to deploy the Aruba 8400 switch, it had a running network by the end of the day.

 

Innovative, Flexible Campus Core and Aggregation

Our game-changing solution in the core and aggregation space has sparked a huge amount of attention. With a flexible and innovative approach, the 8400 comes ready with the Network Analytics Engine (NAE) built into ArubaOS-CX network operating system for higher visibility, faster troubleshooting, easier automation, and improved network assurance. REST APIs allow for programmability and modularity. For high performance in a more compact 1U form factor, the Aruba 8320 Switch Series runs the same innovative ArubaOS-CX.

Friesland College Realizes Tangible Benefits 

Friesland College only recently deployed the Aruba 8400 switch, but the 8400’s capabilities already have had a positive impact on its users. IDC, a leading provider of market intelligent and advisory for the IT industry, worked with Aruba to perform an ROI study on the impacts of the Aruba 8400. Based on interviews with the college’s IT team, IDC calculated that Friesland would see $493,119 of total benefits over a three-year period—resulting in an ROI of 166% over a payback period of three months.

 

Before, Friesland’s IT team had a hard time allotting enough time to address the many network issues experienced by students and faculty, including many complaints about inadequate Skype performance. Ronald Kollen, an IT consultant at Friesland, commented, "Before when we experienced performance degradations, we couldn't pinpoint it to one specific thing. That's all changed with the 8400. It's already meeting my expectations of improved network performance and solving the issues we couldn't pinpoint on the old system."

 

Friesland College chose the Aruba 8400 switch based on its programmability, automation, monitoring, analytics capabilities, and high throughput. "Using network statistics and automation to improve network performance is one of the most powerful features of the 8400. It can directly improve the user experience without even requiring IT involvement,” commented Kollen. IDC also noted that having REST APIs and built-in Network Analytics Engine also provided high automation and increased visibility.

 

Friesland College takes its high standard of education seriously. It wants students to be able to take advantage of top-of-the-line facilities and services, which it recognizes as crucial pillars of delivering quality vocational education.

 

Read IDC ExpertROI Spotlight study on Friesland College

 

Jessica Dinh is a product marketing manager at Aruba, a Hewlett Packard Enterprise company.

 

Did you like this blog? Share it on social media or give it a thumbs-up.