5 Things you should do to have a Successful WLAN Deployment

 30 Jan 2007 11:10:10 pm

Just a quick list to get you started

5 Things you should do to have a successful WLAN deployment:


  1. Do predictive modeling of the environment prior to placing (or running cable for) APs.
  2. Perform a site survey and validation of the environment to ensure consistent signal quality AND minimal Interference.
  3. Create a detailed design of the wireless infrastructure (the same way you would do for routing/switching). QoS and security should be part of the design from the start.
  4. Publish your wireless SLA and educate your users on the advantages/disadvantages of WLANs. Believe me; it doesn’t take long before they expect it to behave exactly the same as the wired LAN.
  5. Regularly track and monitor the environment. Remember with RF your environment is going to be constantly changing and there are some great products out there that can do a lot of the hard work for you (like Cisco’s WCS).


Cheers,
Erik Szewczyk

Posted By : Erik | Category: Networking | Comments [[145]] | Trackbacks [0]

  Why Wireless Design is Essential in the Enterprise

 25 Jan 2007 11:05:08 pm

The past year wireless has gradually become the piece of technology I deal with more than anything else. Most of my time is spent in the large to enterprise environments with Cisco’s centralized architecture (formerly AireSpace). A portion of the increase is new wireless deployments; however the majority of it is organizations trying to replace or repair their existing wireless infrastructure because they don’t meet the current needs or has large problems that cannot solve internally.

My (brief) take on the evolution of LANs throughout the years. Once upon a time LANs were small, slow, expensive, used a shared medium, built ad-hoc and to serve a specific purpose (i.e. connectivity for a LOB system). Fast forward to today and LANs are built to be pervasive, fast, secure, switched, multi-purpose and always available.

Similar to the evolution of LANs WLANs started small, were expensive and often to serve a specific purpose. As the WLAN continues to evolve organizations are starting to expect the same level of service that now exists on the physical wire.

Unfortunately many IS groups still have (or had during deployment) a narrow view of the WLAN. Part of it may be due to the security issues that existed, or the way it become pervasive in the Home or Hot-Spot markets first. Add to that the issues that come with using a medium which is inevitably shared and best-effort and you can really get yourself in trouble.

There are a lot of sites out there that already go into much greater technical depth than I’m looking to in something as simple as a blog post so I’ll only touch on the basics for those of you who are unfamiliar.

Wireless is inherently a shared medium, similar to a network where all the devices are connected to a hub rather than a switch (where every device gets a dedicated path). We could take the analogy even further back by comparing it to your Party Line versus switched phone circuits. Now when you have a small amount of traffic this works okay, however when you get a lot of devices on the network it can very quickly become an issue. Issues can be as simple as the network running slower, or they can be as agonizing as business applications ceasing to function.

With shared Ethernet (hub) you have collisions, and a means to detect and mitigate them, CSMA/CD. With wireless you have interference, and a means to avoid and mitigate, CSMA/CA. And yes even with the party line there is a way to try and work around the problems – “Hello, is anyone using this line?”

When the wireless network becomes critical to your business is when you really get into trouble. For example, when your doctor is using a VoIP wireless phone and doesn’t get a call. I’ve been there, believe me it’s not a fun situation to have the hospital director yelling at you about how worthless the network is.

So to make your life easier, keep your users from screaming, keep up with your SLA, save money, etc I challenge you to put even more effort into designing your WLAN than you did on your LAN. The devil really is in the details. If you don’t have experienced, competent folks on staff than hire a contractor to figure out the details and train your staff on what they need to know.

Cheers,
Erik Szewczyk

Posted By : Erik | Category: Networking | Comments [[120]] | Trackbacks [0]

  Please don’t feed the “Free Public WiFi” troll!

 29 Nov 2006 09:54:05 pm

A couple of weeks ago I was at a training up in Seattle and saw the open wireless SSID “Free Public WiFi”; I tried to connect but didn’t get an IP and disconnected. Than last week I was in LAX and saw the same SSID, after trying to connect and failing to get yet another DHCP address. I checked and noticed that this was an ad-hoc network (computer to computer).

At first I just thought it was a strange coincidence but then today I was on the phone with one of our sales guys who was in Eugene (Oregon) and he mentioned that he was trying to get on a wireless network with the same name.

A quick Google search shows that I’m not the only one noticing these networks popping up all over the place. Apparently if you configure Windows XP to connect to an ad-hoc network (as everyone who tries to connect to one of these networks is doing) than it adds them to the list of preferred networks and tries to connect to them in the future (broadcasting out the SSID for everyone else to see).

For those of you running Vista whenever you connect to a new network you are given the option of whether to save the connection (the default is not to). So long as you tell it to not save the connection your computer shouldn’t broadcast this network in the future.

Aside from just being obnoxious this could have some security implications for you. For example if you aren’t running a software firewall (or if you are but have made exceptions) anyone could connect to an ad-hoc network you are broadcasting and attempt to access your computer.

The solution appears to be simple. Configure your client to connect to only infrastructure networks. I think this should be the default anyways considering the infrequency that users connect to ad-hoc networks.

Cheers,

Erik

Posted By : Erik | Category: Networking | Comments [[140]] | Trackbacks [0]



1
Nov 2017 December 2017 Jan 2018
S M T W T F S
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31       

Categories

Recent

Archives

User List

Search

Syndication

rss0.90
rss_2.0