Recently I worked with a magazine editor who was evaluating and writing about some of the new 802.11n WAPs out in the market. These particular WAPs were aimed at the small business and home office. The testing went well and I think it was a good contest and should make for a great article.

While this type of testing is helpful, as I was working from home this weekend over my 802.11 network I was thinking that what we really need is a test that is designed to catch the issues that typically tick off users like me. Lab tests typically involve testing for throughput, evaluating the installation/configuration experience, and evaluating against a list of desired features. But when asked "What Would the Geek Do" with regards to testing these devices, my preference would be to run each of them for a week or two in production and see how they hold up and compare them against the user experience when using the older WAPs to see if they offer a real, tangible improvement. The Top 5 Things that I look for in a WAP are:

1. Reliability - once I configure it and get it up and running, I don't want to have to screw around with it again. It should just work from that point on. It's freaking ridiculous for me to have to walk my wife (or any non-technical user) through resetting the WAP when it's decided to stop working and I'm on the road.

2. Performance (Throughput) - not only for wired to wireless speeds but also for wireless to wireless connections. Additionally, how is wired to wireless speed affected when you have 3 or more devices downloading simultaneously?

3. Performance (Scalability) - sure it works with 1-2 laptops connected but what happens when I add 5-6 additional laptops, a handful of iPhones, and a couple of AppleTVs? If I'm in the middle of a 4GB download and someone turns on a cordless phone, microwave, or etc am I going to have to start over?

4. Range - I don't have a huge house so I should be able to get good wireless signal anywhere in the house. Nothing hacks me off like not being able to surf from bed because of a lousy signal. Sure, there's a rack full of test gear sitting near the WAP but that's no excuse for poor performance.

5. Security and Manageablity - This is a no-brainer and it's non-negotiable. The teenagers in my neighborhood are relentless (my son is one of them and is almost as good at hacking into networks as I am). With regards to manageability, it needs to support basic SNMP monitoring so I can at least monitor throughput and device performance.

So, I'm going to do this. If you are a hardware vendor or reseller and want your devices included in this test then drop me a line at and I'll send you the shipping information. Otherwise, I'm going to go buy a handful of what I think are representative models and see if I can find a winner or two...


Flame on...

When last I wrote on this subject, I was in Cork Ireland and I'd just switched from a Windows Mobile device that I used as a phone and PDA to a new Blackberry Curve. I will admit that my opinion of the Curve was somewhat hasty. I used it for about a month and after learning several of the shortcuts and best practices that diehard Blackberry users leverage it was definitely more usable than I first thought. I can't honestly say that the UI was really all that much worse than on the Windows Mobile. The real difference is that I'm used to the Windows UI so I was already trained in its advantages and disadvantages. At the end of the day, these were the three largest issues that I had with the Blackberry. First, the Exchange sync isn't very good, even with our corporate REM server in the mix. After spending the day working from my laptop and wrangling through hundreds of messages in my Inbox the last thing I want to see is that the messages I'd removed my my Inbox are still there on the Blackberry. Second, the web browser is very weak. Going from the FireFox v3 beta on my laptop to that thing was depressing. Third, the multimedia capabilities aren't mature yet and I found myself still carrying my iPod everywhere I went.

So, it just so happened that my wife had started swiping my iPod Nano and so I picked up an iPod Touch. It only took me about 20 minutes to decide that it was the coolest thing since variable length subnet masking and so I returned it and upgraded to an iPhone.

Thus far, I freaking love it. I spend more time at home on my iPhone utilizing my WiFi network than I do on my laptop. The UI is fantastic - virtually no learning curve and a few features that just make you say "wow". I'm an iTunes fanatic so the fact that I can skip the laptop and go straight there from the iPhone is awesome. No more carrying a phone, PDA, and/or iPod. This is truly an all-in-one device.

The real test will come the next time I have to travel and rely heavily on the PDA functions of the phone for e-mail, viewing documents, and etc. Here at home it seems pretty good, but this isn't a fair test for those features and certainly doesn't compare to being stuck in Heathrow for several hours with nothing but a Blackberry and a ton of work to do.

I never thought I'd say this, but my experience with Apple products has been so good the last couple of years that I'll probably replace my laptop with a MAC. I know - what the heck am I saying - but, wow this phone is cool. I'm also in the midst of ordering an AppleTV for the house which I'm hoping will turn my HDTV into a giant iPod.

More to come in the next few weeks as I have some trips coming up that should push this thing pretty hard. BTW, if you're out at InterOP this year come and see me and I'll hook you up with some free stuff. If the phone proves to be a bad travel companion for work my teenager will inherit it and I'll go back to the iPod Touch for my music and video needs and try one of the next generation Windows Mobile devices next.

Flame on...

So I got a chance to catch up on some basketball this weekend and then this morning we were all chatting about the NCAA tournament and a friend of mine told me that her husband wasn't going to shave until the Jayhawks won the tournament. Several years ago I lived in Kansas City and helped to design and deploy the network that is now Sprint PCS. One thing I learned while I was there - those people are passionate about their basketball...

Anyhow, that got me to thinking about the lengths to which people will go when they are passionate about something and since I'm passionate about Orion and I know that some of you are too I thought I'd write the "Sweet 16 Ways to Optimize your Orion Installation". Yeah, this would've been easier to do once we get down to the Elite 8 or Final 4, but those who put off until tomorrow...

Sweet Sixteen Best Ways To Optimize Your Orion Installation

16. Use the new, updated AJAX version of the All Nodes resource (and others) on your Orion web views to enhance performance.

15. Move away from RAID 5 for your SQL disk array. Stick with RAID 1+0 or some other RAID that offers higher disk I/O performance.

14. Disable any unused services on your Orion server. This includes any services that might've been installed by Orion but that you're not using (Traps or Syslog for instance) and especially any unused instances of SQL.

13. Separate Orion and SQL Server onto separate machines. Sooner or later you're going to have to do this anyway...

12. Don't use System Manager. Yes, run the System Manager to add devices, make config changes, and etc - but when you're finished shut it down (gracefully) and use the website for viewing the data. System Manager is intended to be used for administrative purposes...

11. If redundancy and fault tolerance are a concern, buy a copy of the Orion Hot Standby Engine. 

10. ICMP Packet Payload - by default, Orion includes data within the payload portion of the ICMP packets that it sends for checking node status, availability, and latency. In many cases, you can improve performance by removing this data (go to "Settings", "Network"). Caution - in some cases, network devices (especially firewalls) will block ICMP packets an empty payload. Use this power carefully young ones...

 9. Polling intervals - trust me, you don't need to poll as often as you think you do. Most people poll for status every 5 minutes and collect statistics every 15. Orion's default values are 2 and 9. If you do need to poll some devices more often, divide your devices into groups for "normal" and "critical" and then manage only the critical devices with the tighter interval.

 8. Remove unused web resources from your Orion views. You know, those resources that you never really look at anyway - they're slowing down your website and eating into SQL resources.

 7. Use the Orion website for viewing data and only use the System Manager when doing administrative tasks. Yes, this is a duplicate of number 12. I will give a free shirt to the first 5 people that catch this and comment about it. Send me your shirt size and etc via e-mail after commenting on the blog.

 6.  Tune your polling engine. Do this with the "Polling Engine Tuner" or just do the math and update the registry yourself. Either way, do it.

 5. Add Orion polling engines. If you're polling more than about 10,000 elements on your Orion server or 1500 elements per minute consider this.

 4. If following number 5 and adding polling engines consider deploying them on virtual servers vs. physical ones. This can save both time and money.

 3. Do daily database backups. I shouldn't even have to tell you this but some of you (and you know who you are) don't think this is important. Trust me, at some point that Windows server is going to burp and you're gonna wish you'd listened...

 2. Get a copy of Orion for you lab. Deploy and test new versions, significant configuration changes, and etc in the lab before you deploy them into production. In case you haven't noticed, I'm big on labs...

 1. Use the Orion Modules - this is an inexpensive and easy way to expand your Orion implementation and add new features such as NetFlow, application monitoring, and VoIP network analysis.

Some of these tips were contributed by Denny (Orion's Product Manager and all around cool guy), Dan (Orion guru and shotgun aficionado), and Destiny (Orion expert and part time ninja).


Flame on...

A subject that I get asked about a lot is how to monitor and measure network traffic. There are many different ways to look at network traffic and link performance and several different schools of thought on which measures hold the most value.

In discussing this subject, let's first limit the conversation to WAN link analysis which is usually where people start to see issues with bandwidth utilization and latency. This isn't to say that you can't see these issues on the LAN - just the other day I was talking to an engineer that is daily fighting these issues on his LAN where the amount of data, voice, and video traffic is overwhelming even 10 gbps links in cases. Nevertheless, much more commonly the issue is on the WAN so let's talk about that first.

The first thing to understand about WAN links is that they're pretty much all full duplex. This basically means that they can both send and receive traffic simultaneously. You might compare a full duplex link to a typical highway bridge and then contrast that with a half duplex link which is more like one of those old time wooden bridges that is only wide enough for one car. This is important because you now have to analyze the traffic in each direction, almost as if they were two separate links. I do see a few cases where you may need to understand the aggregate in/out traffic on a link, but those cases are usually limited to situations where you either a) are getting billed for the total amount of traffic in/out of a location by your service provider or b) you're concerned about the total amount of traffic going through a device. "b" is only typically a concern if you're sending an extremely high amount of some very specific traffic types and you'll probably be working directly with your hardware vendor if you suspect that this is the issue.

So, let's assume that we're analyzing the network traffic in each direction separately. Next, you need to understand that each network interface is unique - meaning that you have to evaluate each hop separately along the traffic path. Case in point - we get asked sometimes for "network wide" bandwidth utilization reports or for reports that aggregate these statistics for all of the links along a specific path. As an engineer, I can't think of a case where I've actually used this data other than to satisfy the curiosity of some executive that didn't really understand network traffic anyway and was basically trying to figure out if they were spending too much on bandwidth or not. So in a nutshell, you need to analyze each LAN link or network interface separately and you need to analyze the traffic going in each direction separately. Effectively, for every link between two devices you now have 4 different places to look for issues. Trust me, it's much more complicated to try to troubleshoot an application performance issue over the network without this knowledge - even though at first it may seem complicated.

The next thing that's really important as it relates to analyzing network traffic and performance is understanding the difference between bandwidth and latency. To go back to our highway example, imagine that the bandwidth is the number of lanes that have going in each direction. If you have the same number of lanes going to and from the destination then you could say that your bandwidth is symmetrical. However, many times, for instance if you have a broadband connection at home, there will be only say 2 lanes heading away from your house and 10 lanes heading towards it. In this case you would consider the link to be asymmetrical.

Latency quite simply is the amount of time that takes to drive to the other end of the highway and back. This is usually described as Round Trip Latency (RTL) or Round Trip Time (RTT). In some cases you'll see the latency measurement broken out for each direction, but not commonly.

Anyhow, that's a very quick summary of some things that you need to know in order to get started with understanding how to measure your network traffic. I'll stop here otherwise nobody will read this far   If you're interested in hearing more on this subject or if you're interested in understanding how to more deeply analyze a specific type of network traffic or network topology, please let me know.

Flame on...

Now to Pay the Bills...
For those of you that have Orion, you'll see that when you look at the Interface Details page for a managed interface you see not only the average bandwidth utilization in each direction (receive and transmit) but you'll also see  high and low water markers. This is really important, because you need to understand how often and for how long your network traffic spikes to the maximum allowable level. Additionally, if you have the VoIP module, you can view latency as it is measured from the remote router to the device on the other end of its WAN connections. This is pretty cool, especially if you put it on the same page with the other interface details and statistics and can really make it quick and easy to diagnose network performance issues. If you don't have Orion, you can still check it out on our online demo server at:

I read an interesting article today by Bill Brenner over at SearchSecurity about how network configuration can affect network security. You can read the article: here


 While this topic is somewhat parallel, the article got me to thinking about how many times we focus on what we have to do with regards to security vs. what we should do. Nearly every day I hear someone talking about the extra work that SOX or HIPAA has caused them and I see them focusing much of their time, especially with regards to security, in these areas. It's gotten so bad that many people think that the terms "security" and "compliance" are one and the same. Do a quick Google search on these topics and you'll see what I mean.

While compliance can certainly be important, focusing exclusively in this area seems to me sort of like considering yourself safe driver just because your wear a safety belt and obey the speed limit.

Let's face it - if your company is required by law to think about things like SOX or HIPAA then as a hacker I'm not going to focus my attention in those areas. Instead, I'm going to look for the things that you probably didn't have time to worry about and/or are more abstract in terms of achieving compliance. Some of the top items that people overlook are:

1. Physical security - there are a lot of things that fit into this area all the way from securing access to your switch ports/LAN drops to making sure your users aren't leaving their passwords written down at their desk (more and more common with today's trend of requiring ever more complex and frequently rotating passwords).

2. Network Application/Traffic Security - is there really a valid reason to allow outbound telnet, RDP, FTP, and SSH connections from your network? What about allowing RDP/telnet security from a user subnet into your core routers?

3. Configuration Management - if someone makes a change on one of your devices are you paged? Do you compare the current configs of your routers and firewalls to the configs from last month and validate the changes against an engineering work order or some other tracking mechanism?

With regards to configuration management, there's really no excuse not to have a solid solution in place in today's day and age. A few years ago the choices were limited to very expensive and hard to use enterprise apps or open source applications and the time investment that those imply. That simply isn't the case anymore - take the Cirrus Configuration Manager we offer here at SolarWinds for instance. Very easy to use, inexpensive, and meets most of the common use cases for config management in the enterprise today.

Let me know if this is a topic (network security) that you'd like to read more about and I'll start including some deeper content in this area.


Flame on...

Head Geek's Top 10 Most Annoying Topics in Networking

10. Overlapping IP address ranges. Let's face it folks, if you've inherited a bunch of overlapping or duplicate address ranges you're going to be better off just to figure out a solid addressing strategy and readdress the problem areas. Otherwise, you'll be stuck trying to work around this issue forever...


 9.  "Classful" IP Address speak. When people are speaking about any /24 as a "Class C" or any /16 as a " Class B" it just gets in my craw...


 8.  Access Lists. There has got to be a better way to implement the features that ACLs provide. Sure they're easy enough for those of us that have been using them for years but for newbies they're a nightmare even when trying to accomplish a relatively simple task.


 7.  The old "SNMP isn't Secure" compliant. So what exactly is the argument here? Yeah, I use SNMPv2C to poll the devices on my network and the data is transmitted in clear text. Let me tell you, if there is someone running around my network looking at packets with a sniffer there is way more dangerous stuff for them to see than the most recent ifInOctets counter values from one of my WAN routers. And as for SNMPv3, it's great but hardly anyone uses it... Bottom line - there are plenty of ways to secure your SNMP traffic - not  managing the network really isn't an option though is it?


 6. Over protective DBAs. Dude - we just want to put a database on your gargantuan SQL server and store some statistics there. You'd think I was asking to date your daughter or something...


 5. Dress codes. Yeah, this topic isn't technical but all of us networking geeks have to wear clothes to work and we oughta be able to wear whatever the heck we want to wear.


 4. Annual budgets without any allocations for lab gear. Hey, if you want me to do my testing on the production network then it's OK by me.


 3. Devices that don’t even support the most basic, standard MIBs. Those RFCs are there for a reason people. Implement the standards based stuff then put all of your special, fancy data in your own private MIBs. Don’t skip the prerequisites…


 2. SOX. I've seen this used for justification for everything from Exchange mailbox size limits to how often we change the coffee filters. One of these days we’re going to find out that it’s a bigger conspiracy than the murder of JFK and that the whole dang thing was made up by one of the big 5 consulting firms that are pulling in all of the cash telling us about everything we can and can’t do…


 1. Copycat network management products. If you can come up with something original then I'm all for it. But if you’re just putting new skins and UIs on existing functionality then what's the point... We don't use these tools because they're pretty, I mean, dude, we spend half our day in a freaking CLI for crying out loud...



Flame on...

Well, I'm over in Ireland this week working from our office in Cork. I must say, the weather here is amazing. Five minutes ago it was warm outside and the sun was shining through the window of my office so brightly that it made my laptop screen unreadable. Now, it's cold as heck and pouring down rain and it looks like it'll be snowing any minute. One of my buddies just told me that the great thing about the weather in Ireland is that they have 4 seasons - nearly every day... Good thing is, the people here are fantastic and there always seems to be someone around offering me a swig of warm Irish whiskey to take the chill out so believe me - I'm not complaining...

Anyways, today I thought I'd write about mobile devices. For the past few years I've been using a Windows mobile device. It was one of the ones with the slide-out keyboard, Windows Mobile 5, blue tooth, WiFi, and etc. I've used it for almost 3 years now and it finally died on me. So, I decided to try something different... These are the main products I evaluated and what ended up being the deciding factors of each for me:

AT&T Tilt
Deciding Factors - a) I wanted something smaller than what I have now and b) I wanted to try something new vs. just a new version of what I have.

Deciding Factors - a) I wanted something that had a persistent mail store so that I could work on e-mail while not connected and b) I type on my PDA a lot so I wanted a fast, tactile keyboard.

Blackberry Curve
Deciding Factors - a) My IT department officially supports the Blackberry. Otherwise you're kind of on your own. b) Came highly recommended from my co-workers.

So, here I am with my new Blackberry Curve. I can see why it sells well. It's light, fits in my pocket easily, attractive looking, and comes with all of the features that you would normally want.  I hate it.

If I'd never owned a more advanced PDA I probably wouldn't notice - but then again if you'd never ridden in a car you probably wouldn't mind riding a horse to work so much. The lack of a touch screen is driving me insane. The web browser is a joke and the integration with Exchange, even with our REM server, is poor. It reminds me of when I used to receive e-mail on my old text pager (during the last century). If I delete an e-mail from my PDA I also have to delete it from my Outlook client (never a problem with my other device). Likewise, spam that should show up in the junk mail folder for some reason shows up in my Inbox on this device. It just plain sucks.

So, since I'm in Ireland for the remainder of the week I won't be returning this device and trading it in for something else until at least 4-5 days from now, I have time to reconsider and get feedback from any of you loyal Blackberry users out there. There are millions of people that swear by these things so maybe some of this is just setup/user error and maybe I can get used to not having a full browser or touch screen.

Flame on...

p.s. Remembering that this is a SolarWinds sponsored blog/site, I thought I'd mention that I am able to get alerts from my Orion server on any of these devices (including my 15 year old pager). Of course, on my Windows Mobile device and on the iPhone I was able to login to the Orion website remotely and diagnose the issue, but that's another story...

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.