Many companies depend on 802.11b wireless networks to complement their wired LAN connectivity, but wireless networks can pose unique administration challenges that require special attention. Small flaws can quickly compound to bring a wireless network to a crawl. Exercising extreme care in configuring and managing your wireless network is crucial. The wireless ISP (WISP) UtahWISP learned this lesson the hard way.
When UtahWISP started operations in northern Utah, it was among the first to provide broadband Internet access to fringe areas and new residential developments that lacked other affordable broadband solutions. The company placed a pair of wireless access points (APs) on nearby towers and installed receivers on customer rooftops so that anyone within line-of-sight of a tower would have broadband Internet access.
However, by providing a service where no other was available, UtahWISP saw its network quickly stressed by rapid customer growth. When its customer base reached more than 200 users and 12 APs, some wireless customers began to experience sluggish browsing, lost packets, and slow ping times. And because UtahWISP was hardly utilizing the bandwidth leaving its network, it was clear this was a wireless problem.
Crowded wireless networks are an increasingly common problem, so I thought UtahWISP would be a perfect candidate for a network makeover. After gathering a little more background information about the performance concerns, I visited UtahWISP to see how such a network makeover might help. Here's the story of one company's complete network makeover—from getting a bird's-eye view of the symptoms and identifying potential causes to implementing solutions and finally solving the problem.
Getting the Big Picture
I knew the network was slow, but after a cursory examination, I didn't know exactly why. I found plenty of unused bandwidth, and performance problems didn't correlate with typical usage patterns. Furthermore, performance concerns didn't affect all users at all times. Some users regularly reported problems, but others experienced quick response times and fast download speeds. According to Dale Meredith, UtahWISP's IT manager, "It didn't make sense. It was frustrating because we were nowhere near our expectations of wireless capacity."
I had dealt with slow wireless networks in the past, but this one was particularly difficult. In UtahWISP's demanding wireless environment, many problems seemed to compound to have a significant impact on network performance. But was this network really different from any other office environment? Surely, radio interference and signals blocked by buildings and trees weren't terribly different from those blocked by the walls and furniture of an office environment. The only real difference was scale.
Before delving into the nitty-gritty, I wanted to step back and get the big network picture. I knew UtahWISP had 12 APs on two separate towers. Each tower served customers within a 10-mile radius and had a fast wireless backhaul link to the main office, at which point it connected to the WISP's main router.
To map the network, I used AdRem Net-Crunch 3.1 Premium. NetCrunch not only got me started visualizing the network but also would give UtahWISP a long-term monitoring and reporting solution. Using NetCrunch's automatic-discovery feature, I built a visual map of the network. Although the result of the automatic discovery required some manual tweaking, it saved me a considerable amount of time. After some fine-tuning, I came up with an accurate representation of Utah-WISP's network, which Figure 1 shows.
To monitor network performance, the company had been using a variety of different tools— mostly Ping. When a customer called once to complain of slow performance, Utah-WISP's administrators opened up a command prompt to ping that customer for a certain-period and watch for problems. Unfortunately, the Windows Ping utility doesn't have much flexibility, and the continuous echo requests contributed to the user's problems by generating even more traffic on the network. Furthermore, Ping is hardly scalable and its output is difficult to visualize.
NetCrunch offers better monitoring features, including the ability to monitor SNMP counters, Syslog data, Windows Performance Counters, and ping times. The software provides dozens of configuration parameters for customizing monitoring for specific networks. NetCrunch also provides powerful charting features for real-time monitoring of the aforementioned parameters.
My primary objective was to track down network performance problems. The Net-Crunch network map, when we first saw it, clearly illustrated the existence of a problem: The map showed slow response times for some hosts, and the network seemed generally sluggish at times. I noticed that hosts would frequently go down, appearing as red icons on the map. These occurrences were probably the result of dropped packets, particularly considering the random nature of hosts' icons turning red.
Previous
Register
