Geek Speak

September 2007 Previous month Next month

First of all, I know that I said that the next post would have more information about disaster recovery scenarios. However, this topic is hot on my mind and I'm in a location with very limited internet access this week so I'm going to defer the additional disaster recovery information for something that is more interesting to me at the moment...

I'd like to talk a little bit about wireless networks. For those of you that have been using wireless networks for a few years, you'll agree that they've come a long, long ways. I'm sure that someone will argue with me here, but nowadays I have a hard time justifying cabling a new office vs. using a next-gen wireless infrastructure. The new wireless network equipment from Aruba, Cisco, Proxim, and others is very reliable, easy to deploy and manage, and offers more bandwidth to the desktop than the typical user will need for years to come. It's easy to deploy, inexpensive, and in the cube-land that most of us live in it works very reliably.

<warning - vicious rant follows>
This week I'm staying at a hotel out in Tinton Falls, New Jersey. It's an area frequented by technical people as AT&T, the US Army, and others have tech centers here. So why is it that the hotels here have such horribly slow internet access? And more directly, why is it that in today's day and age so many of the hotels that we frequent still don't have wireless networks available? This is, in my opinion, pretty freaking ridiculous. As a technical person (and especially as a network engineer) I guess I just expect better than this. I mean, come on. How many of us have high-speed wireless networks at home? My son setup the last wireless system that we bought for my house and he was 12 at the time - there really are no excuses here... I mean, given a choice of sitting at a desk and using the free wired access or being able to sit comfortably in bed, watching TV and working via a wireless connection - who wouldn't pay an extra $10 for the convenience of wireless? I sure as heck would... These guys are missing both an opportunity to enhance customer service and an opportunity to increase revenues... What gives?
<end rant>

With regards to wireless infrastructure, there are three primary categories of wireless equipment. First, there are small, inexpensive wireless devices intended for homes and small businesses. These are the devices made by Linksys (Cisco), Netgear, Belkin, D-Link, and the like. These devices are very affordable and easy to configure but don't offer the manageability or performance that you need in the enterprise environment.

Next, with regards to enterprise class wireless infrastructure, there are two primary classes - systems using fat WAPs and systems using thin WAPs. There are many different terms for these technologies and some people don't consider the fat/thin phrasing to be PC but this is how I learned it when the technology was just emerging and the terms stuck with me.

Fat WAP infrastructure is the traditional 802.11x systems where each WAP operates and is managed individually. This technology is very mature - it's been around several years - and it doesn't require very much expertise to set it up.

Thin WAP infrastructure is a bit different. Within this environment you have a central WAP switch that acts as the brain of the operation. Then, you have dumb WAPs that basically act as antennas - bridging the wireless networks from the switch out into the areas where wireless access is desired. While this architecture is a bit more complicated and harder to setup it can offer huge advantages in terms of advanced features and manageability. I have a good friend who is one of the old timers over at Aruba and some of that they and Cisco can offer through their next-gen wireless technology is really amazing. Imagine being able to walk anywhere in your company carrying your laptop, without ever losing wireless access, changing IP addresses, VLAN, or etc... I'll see if I can get my buddy to post some information about some of the more cool features they offer today. 

Now to pay the bills...
As you know, I try to add a little something to every post to help keep the lights on around here. For those of you that have deployed wireless networks or are planning to, Orion does a great job of managing this type of infrastructure. For fat WAP environments, we offer an add-on to Orion called the Wireless Network Module. This is an inexpensive way to enhance Orion so that you can track more information on your wireless network like signal quality, errors, and traffic on a per WAP and per wireless user basis. For those of you that are deploying thin WAP systems, you can use the Custom MIB Poller in Orion to track statistics within the wireless switch for both the thin WAPs and the users connected to the wireless network (the specific statistics will vary a bit based upon the hardware vendor and the information that they make available via their MIBs, but more are very good). If you want to learn more about how Orion can help you manage your wireless infrastructure contact your SolarWinds sales dude and he or she will be more than happy to assist.

That's it for tonight.

Flame on...



First of all, thanks for stopping by to read this blog. I'll try to keep it interesting and provide at least a couple of new posts per week.
Today's topic is disaster recovery/failover. As you may have noticed, we added this blog to the community site today at noon but it's now several hours later that I'm providing the first entry. This is because at around 12:05 today the location that I was working from experienced a network outage and by the time that they'd resolved the problem I was already locked into my next set of meetings. Now, I don't know exactly why this happened other than it was carrier related. If I had to guess, I'd say that some newbie in the provisioning department accidentally provisioned part of my circuit to someone else. Either way, it got me to thinking about disaster recovery, protection, and failover solutions.

As I see it, there are three important trends that amplify the need for disaster recovery planning. First, companies are relying more and more on the network as we continue to distribute systems across our WANs and even across public internet connections. Second, we are continually replacing traditional dedicated circuits with MPLS based networks and internet based VPN solutions. Third, because of the continuing demand for network engineering expertise (i.e. you just lost the best guy on your team to a new company) and the growing complexity of today's networks (there's just plain more to learn nowadays), many of the people we rely on to provision and maintain these networks are less qualified than the people doing these jobs 10 years ago.

The most important part of any disaster recovery methodology is simply to have a plan. Not just in your mind - have an actual written down plan. Print off the plan and put it in a white binder with big black letters on the spine and label it "Disaster Recovery Plan". Put a copy on your desk, give your boss a copy, and be sure that if you have a NOC they have a copy as well. I can tell you that even if what's in the binder isn't all that impressive, just simply having a few copies of it around and making sure that it weighs at least as much as a nice notebook will help your career...

Now that you have decided to have a plan the next step is you have to have a budget. Probably the biggest roadblock to acquiring this budget is the word "disaster". When people think about disasters, they envision hurricanes, earthquakes, and fires. Because of this, many people think that the chances of them needing a disaster recovery plan are pretty slim. Let's be clear about something - disasters are much more common than this. If you've only got one circuit leading to a site and that circuit goes down you have a disaster. If your company has only once Exchange server and that server goes down - disaster. If your core router/switch ever goes down guess what - disaster. When you go to start arguing for budget for disaster planning and mitigation be sure to document what can happen if you don't get the budget. Point out some of the outages that have occurred over the last few years and the frustration and/or lost revenues that they caused and this should help to ease things along.

In the next entry we'll talk about some technical best practices with regards to planning for and around these disasters. Be sure to send me your thoughts on this topic if you have some and I'll try to get them included.

Now to pay the bills...
Since this blog is on the SolarWinds community site I'll try to add a little something to most topics to help keep the lights on. With respect to disaster recovery planning, this is also very important to think about when architecting your NMS. There are several ways to make your Orion server fault tolerant and to plan for disaster recovery. One of the easiest ways is to purchase a copy of the Orion Hot Standby Server. This application sits on a physically separate box from your main Orion system and monitors the Orion database to ensure that your data collectors are healthy. If one of them goes down, it automatically picks up the load - impersonating the failed polling engine. If you don't have a copy of the Orion Hot Standby Server, ping your sales dude and have him/her send you a quote.

That's it for tonight.

Flame on...


Filter Blog

By date: By tag:

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.