Recently in Wireless Network Category

The whole Google debacle - collecting "wireless payload data" with its Google Street Views (GSV) data collection system -  comes down to nothing more than a greed-driven lawsuit disguised as a case of social justice.

Let's face it, the security of wireless data from 802.11 networks has been talked about for years. But if someone is doing  important things on their wireless network and they're not employing a reasonable level of security, then do they really have anyone to blame but themselves? They've opened their data up to anyone and the ones who really want that data aren't going to openly admit that they collected some while driving by, like Google. No, those that want credit card and personal banking information and possibly someone's identity, will sit much farther away, use directional antennas and collect data for much, much longer than Google does during a GSV drive-by. That's the only way to get meaningful data.

To further illustrate this point, let's assume the GSV vehicle drives so close to someone's house that it passes an AP within a few feet. Let's assume the vehicle is following a typical residential speed limit of 25mph as it drives directly by the AP. A typical AP has a range (and a generous one at that) of a few hundred feet in either direction, that's about 400 linear feet, again assuming the GSV vehicle has driven right up to the AP. At 25mph, the vehicle can travel the 400 feet by the AP in just a little less than 11 seconds. So at best, Google has collected 11 seconds of data, assuming that the person was online at that specific time and that they have completely ignored all pleas by every 802.11 device manufacturer to use wireless security.

The issue, however, is that Google has no idea what channel anyone's AP is set to, so it can't drive by scanning on just one channel. It needs to scan all of the available channels to collect the data that's really of interest, namely whether or not there's an AP around, its network name, and the channel it's broadcasting on. In the 2.4 GHz band there are 11 channels (in the US) and in the 5 GHz band there are typically 8 (again, in the US). Assuming they need to scan through all of these channels, data is only being collected on an individual's specific channel 1/19 of the time, reducing the slice of data that has been collected by Google to less than 0.6 seconds. Perhaps some critical, unsecured data did cross the network in those 0.6 seconds, but that data is now combined with similar data from thousands upon thousands of other users. This sure doesn't sound like the most effective solution to try to get access to user's critical wireless data.

So in the end it's not about data privacy, it's about greed. Could Google have been a bit smarter and not collected the payload data? Well sure they could have. But is there anything malicious going on here? Only on the part of those trying to hide behind data privacy invasion for financial gain.

What's not even considered in this debacle is all of the real data Google does collect, freely and with all our consent, every time we surf the web ...

Roaming occurs when a handset moves out of the range of one access point into the range of another. It gives users the mobility to move around within a local coverage area and still be connected to the network. However, roaming is one of the primary reasons why users experience problems on wireless networks. Excessive roaming times lead to poor quality for voice and video over wireless and can lead to dropped calls or data connections.

Roaming usually involves a channel change, but that depends on the type of technology deployed. If it's a multi-channel architecture, which is most likely the case, a channel change is required. When roaming occurs, the client needs to be re-authenticated and re-associated with the new access point, which takes longer than 150 milliseconds in most instances, especially when advanced features like WPA2 and WMM are in use. Most organization's wireless networks are outfitted with multiple access points (APs) and users can experience poor signal strength and performance despite proper coverage in the area if the client is connected to the "wrong" AP. Even in the most modern, centrally managed systems, the wireless client is the one who decides when to switch from one AP to another. This decision is typically determined based on the current signal strength and is executed by the underlying software controlling the wireless client radio (the "supplicant"). This software is different from manufacturer to manufacturer and from device to device, so the way the decision to roam is made varies widely. In most cases, the wireless client will wait too long and as a result the available signal strength lowers, before the client switches to an AP with greater signal strength.

New and improved standards are available that specify the conditions for "fast roaming," enabling transitions that take as little as 5 - 10 milliseconds. These specifications include:

  • 802.11i - with opportunistic key caching so there is no re-authentication step
  • 802.11r - fast BSS transition, which optimizes the hand-off as clients move from one access point to another
  • 802.11k - radio resource management of WLANs allows re- authentication to be maintained between multiple APs and has predictive capabilities

These new standards (802.11i isn't new, but it's still part of an improving situation for roaming) allow APs greater control in determining when roaming should occur and the APs are more in tune with the current performance of, and demands on, the wireless network. However, this situation is even better when the overall wireless network is under the control of a centralized manager. The issue is that adoption of 11k and 11r has been very slow, especially in wireless clients, and until adoption increases significantly users will continue to suffer slow AP transitions when roaming, leading to poor voice and video over IP performance.

In the meantime, the best approach is to carefully monitor and analyze the roaming activity on your network. Obtaining a complete and accurate view requires real-time aggregation of data from multiple channels and APs, with integrated analysis that leads to detailed reporting - who is roaming, how long each event is taking and what does the average look like for each AP. The end result is simple, yet the process is complex, demonstrating why proper network analysis tools are key to staying productive. 

The recent approval for Yahoo to build a massive campus in the heart of Silicon Valley is the perfect example of how wireless networks can grow and evolve. The sprawling campus will consist of thirteen six-story buildings across 3-million square feet. As a result, the 12,000 Yahoo employees will likely become much more dependent on wireless access, demand it from more locations and expect to have the performance and reliability characteristics of the wired network. There are several issues to consider in a wireless campus environment. As new standards come into play like fast roaming, capacity will become even more of an issue. As more people try to access the network in one area, density will increase and put significant strain on the access point resource. Security is always an issue but in a wireless network environment, it's more about the nature of those on the network and their desire to cause harm. Besides coverage, capacity, density and security issues, below are some key considerations for Yahoo and other enterprises that have distributed wireless worlds.

1. Take advantage of a single vendor's access point management system

These management systems are key in a distributed world. Before, there were wireless monitoring vendors called overlays, which offered additional sensors to access points deployed in the network. However, they were costly in terms of power, equipment and network drops. With access point management systems, companies have access to software that can control channels and power on the fly. Depending on the amount of traffic and people accessing one particular point, the power can be adjusted appropriately.

2. Keep an eye on the spectrum

There are still several interferers out there. 802.11n uses an unlicensed spectrum meaning a lot of other technologies share that same spectrum including Bluetooth, cordless phones, video cameras and microwaves. It's important to be aware of interferers, know what they are and how to manage them.

3. Don't forget about troubleshooting

Monitoring the network through access point management systems isn't enough. It only indicates trouble - it doesn't troubleshoot and solve problems. Being at the scene isn't always effective with campus wide networks, especially when you have satellite offices or are spread across acres of land. Enterprises need an analysis and troubleshooting capability on top of management that can be distributed. This can be done through purchasing additional software probes with wireless adapters. Another option is to leverage the network that is already in place by switching thin APs into promiscuous mode, where their only purpose is to receive and collect packets to be analyzed. Lastly, enterprises can equip network USB hubs with wireless adapters that plug into the Ethernet network. This makes the network transparent and businesses can access adapters to use along with their network troubleshooting software anywhere on the network.

Online mobile VoIP (or VoFi) is coming. In-Stat anticipates 171.3 million users by 2013, with annual revenues projected at $10.8 billion ("Mobile VoIP - Transforming the Future of Wireless Voice; In-Stat In-Depth Analysis," Frank Dickson, Sept. 2009). Previously on our blog we've talked about why VoFi and why now, specifically the benefits of VoFi. Now we'll focus on VoFi monitoring, analysis, and troubleshooting.

Before you panic, take a deep breath. Analyzing VoFi traffic is basically the same as analyzing VoIP traffic. Remember though that wireless exacerbates factors such as jitter, latency, and packet loss that affect VoIP. Watch Using VoIP Metrics to Identify Network Problems for the specifics.

Begin at the Beginning: Your End User's Call

When problems arise with VoIP or VoFi applications, you start in the same place. Your first step - before you begin to worry about statistics or packets - is to take the time to listen to representative calls. You want to hear what your end users are experiencing. Your ear will reveal telltale signs of latency, jitter, and packet loss. Be sure your VoIP analysis application supports playback of call audio, specifically the playback of individual RTP streams as well as the playback of the complete call. Without the audio, you can spend hours tracking down problems that aren't due to either the application or the network - for example, clicking due to a damaged handset.

Take Your Network's Pulse

Once you have listened to the call, you'll want to take a look at what's going on in your network.

33.png

Figure 1: Overview of Network Health

Immediately you see what you heard - the call quality was poor. The Mean Opinion Score graph gives an average over all calls occurring on your network. In this example there's just one call, so you see the average for the duration of that call.

Dig Deeper

With Expert Events you're able to verify what your ear told you.

3.09.png

Figure 2: Event Summary

With this call, you can see that there are a lot of physical errors: late packet arrival, retries, out of sequence packets, packet loss, excessive jitter, and more. With the cause identified, you can quickly begin to fix the problem. Looking at the call in its entirety, you'll notice the call is closed, it had a successful ending - meaning the call wasn't truncated - what CODEC was used, how long it was, and what the Mean Opinion Score was.

3.43.png

Figure 3: Call Statistics

In this example, the mean opinion score of 2.5 lets you know that the quality of the call was pretty poor. In the media view, you can drill down into each segment leg to determine why the quality was poor.

5.11.png

Figure 4: Call Details - R Factor, Mean Opinion Score, Packet Loss Percentage, One Way Delay, Etc.

Understand the Differences between Wired VoIP and VoFi Calls

The next two figures show both a Wired VoIP call and a VoFi call packet-by-packet. (For an in-depth discussion of these calls, watch Anatomy of a VoFi Call: Packet-by-Packet.) You'll notice that they're pretty similar. The protocols used are different and with VoFi there's the additional step of authentication.

vofi_post1.png

Figure 5: The Anatomy of a Wired VoIP Call

The differences involve: wireless segments instead of wired segments; signal interference; and wireless roaming.

vofi_post2.png

Figure 6: The Anatomy of a Mobile VoIP (VoFi) Call

Learn More

Last week in Toronto, Joe Habib, Director of Global Services, presented "QoS of IP Telephony: Slaying the Three-Headed Beast of Jitter, Latency, and Packet Loss" at IT360. His presentation (PDF) is now available online. If you're interested in ensuring QoS for your current (or future) VoFi deployment, you should definitely check it out.

In the presentation, you will learn:

  • What six factors contribute to poor voice quality
  •  How to establish metrics for evaluating VoIP call quality
  • How to balance high-speed, bursty data requirements with requirements of high quality voice calls
  • How to capture data for VoFi Analysis and use VoIP metrics to identify developing problems
  • How to analyze a VoFi call packet-by-packet and verify voice quality with call playback

The OmniPeek Plug-ins are flying off the shelves.  And they should, since they are free to customers with maintenance.   There are over 40+ plug-ins available on MyPeek.   Some are more popular than others.   To help you decide which ones to try first, we have taken a look at the stats, and have come up with the top 10 most downloaded plug-ins.


top_10_omnipeek_plugins-11.png

Compass Forensics Dashboard with enhanced Milliseconds view

The Compass Forensics Dashboard is our latest innovation, fundamentally changing the way network analysis is done with OmniPeek.   Compass analyzes and loads node and protocol statistics across multiple trace files into a database.   The user can then selectively overlay  those statistics in a graph over time, visually correlating network traffic details.   The graph is an interactive timeline that  can change the statistics on the fly to bits, bytes, megabits, gigabits, or packets per second.  The timeline has sliders that are used to drill-down to an enhanced milliseconds view, or load the packets for the currently selected slice of time.  Read more...


top_10_omnipeek_plugins-1.png

Google Map Plug-in!

The Google Map Plug-in displays a Google Map in the OmniPeek capture window showing the locations of all the public IP addresses of captured packets. This feature is a great way to monitor your Web site at a high level and to see in real time where in the world those hits are coming from.

Read more...




top_10_omnipeek_plugins-2.png

The Instant Messenger Plugin

This plugin displays conversations for the AIM, MSN, and Yahoo protocols in real-time, showing the screen names of the people chatting as well as the actual text.   Individual screen names can be selected, showing only the conversations for that screen name.

 

Read more...



top_10_omnipeek_plugins-3.png

Remote TCPDump Adapter

The Remote TCPDump Adapter for OmniPeek is a revolutionary new way to monitor network traffic remotely. With OmniPeek and the Remote TCPDump Adapter you can dramatically extend the reach of your network monitoring capabilities by turning virtually every Linux and Unix based machine on your network into a network probe, and you can do this without installing any new software on those remote machines.

 

Read more...




top_10_omnipeek_plugins-5.png

NetFlow Analyzer Plug-ins

The NetFlow Analyzer Plug-ins for the OmniPeek Console and OmniEngine collect NetFlow traffic and display NetFlow statistics in OmniPeek.

 

Read more...









top_10_omnipeek_plugins-6.png

Wireless Channel Aggregator

The WildPackets' Wireless Channel Aggregator captures wireless packets from multiple channels simultaneously (without scanning), measures vital statistics on each channel separately, and calculates the latency of devices roaming between access points.

Read more...


top_10_omnipeek_plugins-7.png

Regular Expression Filter Plug-in

The FilterMe Plug-in allows the user to create and maintain a list of regular expressions that can be used as filters during real-time capture and file windows.

 

Read more...


top_10_omnipeek_plugins-8.png

WatchMe Plug-in

The WatchMe and Browser Plug-ins displays web pages.   The WatchMe Plug-in follows links in real-time that network users are surfing to, while the Browser Plug-in reassembles packets back into web pages.

 

Read more...



top_10_omnipeek_plugins-9.png

FindMe Plug-in

The FindMe Plug-in adds a tab to the capture window that contains a list of text strings that are searched for each packet. As packets are being processed, the plug-in searches for each instance of each text entry in each packet and makes log entries when the text is found.

Read more...



top_10_omnipeek_plugins-10.png

Latency Monitor

The Latency Monitor measures network and application latency.   These are graphed together and can be easily compared to determine which one is the culprit.   Alarms can also be set to inform you if latency thresholds are exceeded.

 

Read more...

Three benefits of VoFi

| No Comments | No TrackBacks
The use of VoFi, or Voice over Wireless, has been rather limited. But now, with the newly ratified 802.11n standard, we're expecting to see a surge of interest in this technology since 802.11n and its increased throughput and range is what makes VoFi feasible. 

Three benefits of VoFi are:
  • Reliable coverage
  • Moving billable, cellular minutes to Wi-Fi
  • Increased mobility

We all continually suffer through the issue of poor cellular coverage indoors, whether at home or in the office. VoFi and VoFi enabled phones provide the capability to transition calls and data activity from cellular to Wi-Fi when in range of an 802.11 network. Since 802.11 is typically deployed to cover indoor spaces, like your home and office, call and data quality will be dramatically improved indoors with VoFi enabled technology.

An added benefit of transitioning a call to your 802.11 network is that it reduces cellular usage, saving minutes on pay-per-minute plans. Granted, this hand-off is still being worked out between carriers and equipment manufacturers, and may not result in a complete minute-for-minute reduction in usage, but more than likely some level of savings will be realized, allowing you to much more quickly capitalize the expense of an 11n upgrade by eliminating some of your billable cellular traffic and carrying it on your 802.11 network.

802.11 has always been about mobility, but up until now it's been manifested more in being able to move from your office to the conference room with your laptop and maintain connectivity. VoFi significantly extends mobility by including voice communications as well. You no longer need to be tethered to a desk phone, or limited by the base-station range of a cordless handset. Wherever there's 802.11 coverage there's voice coverage. This technology was already in use by some industries, large retailers for example, allowing customer service reps to wander the store while helping customers. But 802.11n and VoFi will take this to the mainstream, both in the office and at home.

A key element of VoFi, of course, is the voice component. It's very similar to VoIP in that it's susceptible to jitter and latency, and thus dropped calls, interruptions, and other issues. As a typical wireless network has more latency and interference than a wired network the susceptibilities are that much worse. So with this new technology comes new problems. Are you prepared to manage your new VoFi environment?

On November 18, we're hosting a webinar to explain how best to manage your VoFi environment.

The Cisco AP Capture Adapter is a feature in the OmniPeek Console that can capture and aggregate wireless packets from multiple Cisco Access Points.    This feature is especially useful to companies with large numbers of Access Points (APs) that are spread throughout offices, stores, and warehouses.    It allows any one or more of the APs to be temporarily used as probes to capture traffic, and then switched back to AP mode, all remotely through software.    Being able to multi-purpose the APs in this way increases the ROI of both OmniPeek and the Cisco AP.

So the Cisco AP Capture Adapter, as a solution, is very good.   Of course, as the developer of the Cisco Remote Adapter, I am going to say that, right?    But seriously, we have been pleasantly surprised by the  popularity of this feature, and the growing number of customers who are using it.  

However, it has its drawbacks.    Because it runs on the OmniPeek Console, the captured packets have to be streamed over the network from the APs to OmniPeek, wherever it may be.    This could be on a different segment, in a different building, or in a different country.    The stream is also not encrypted.    Furthermore, if the IP address of the OmniPeek Console machine changes, which is likely, the AP configuration has to be changed to reflect that.

The point here is that the distance the packets must travel could be long, possibly over the internet, it is not secure, and it changes locations.    These are not ideal characteristics of an enterprise solution, which is why the Cisco AP Capture Adapter is used mostly for local troubleshooting.    This is too bad, since the potential is so much greater.

Now for the good news.  (Imagine a drum roll in the background.)  Ladies and gentlemen ... we have just ported the Cisco AP Capture Adapter to the OmniEngine.   (Now imagine roaring applause.)  Yes, this is good news indeed.   

By running the Cisco AP Capture Adapter on the OmniEngine, and placing the OmniEngine on the same segment or subnet as the Cisco AP wireless mesh, all of the packets from any one of the Cisco APs can be streamed and aggregated directly into the OmniEngine.   The OmniPeek Console is then used to connect to the OmniEngine and view the results of the analysis.  

By inserting the OmniEngine into the equation, a new tier is added, providing better performance, less overhead, and security.    The performance is better because the packets only have to be streamed to the OmniEngine, not all the way back to the OmniPeek Console.    This also provides a permanent capture environment, so that your AP configurations do not have to change.   

The overhead to the network is also less, since the packets have to travel  a shorter distance, through fewer routers and switches.   Security is also much better, because the OmniPeek Console interaction with the OmniEngine is through a secure and compressed connection.

But that's not all.   There are many advantages of using a distributed OmniEngine, and now users of the Cisco AP Capture Adapter will be able to take advantage of them.   Yes, this is good news indeed.    The Cisco AP Capture Adapter  for the OmniEngine is in test now, and will be available to maintenance members soon.    I am sure it will be a big hit.

-SpacePacket



Fact: wireless networks save money and increase productivity. Craig Matthias of Farpoint Group has identified five key themes relating to WiFi that have emerged in 2009. These themes are important to consider as organizations plan, deploy, and manage their networks.
 
1. 802.11n is here

Even though the IEEE has yet to ratify the 802.11n specification, the Wi-Fi Alliance has been certifying 11n equipment for 2 years now, and it's been a very successful program for them. The reasons are obvious: 11n equipment is already in widespread use and deployment rates will only increase as use of the technology shifts from consumer-based equipment to widespread enterprise deployments. All new deployments, as well as any replacement projects which are in place for 802.11, should be with 11n gear, period. The benefits are tremendous. Prices are highly competitive. It's not only here - it's thriving.
 
2. Unified networks

I've been saying this since I first started working with 802.11 - if you have a wireless network, you must have a wired network. They do not exist in a vacuum. So to even think of one as separate from the other is ludicrous. Granted, network management may be a bit different between the two, the network must be viewed as a whole, meaning a unified wired/wireless network. And unified wired/wireless network management systems. Look for lots of development in this area over the next few years.
 
3. All applications are going wireless

Even more to the point, all applications ARE wireless. Users don't distinguish between wired and wireless networks when they sit down to work, so applications shouldn't behave differently either. Fortunately, 802.11 has been well specified to deal with this and the cases where applications don't behave well over wireless are few and far between. Though VPN and other tunneling protocols may be exceptions, we're also seeing rapid improvements in these areas as well.
 
4. Wireless security is a myth

Maybe it's more like "wireless security is mythical" based on all of the iterations and misconceptions that have developed over time. This topic has truly been covered to death, so let's just sum it up: WPA2 is easy to use and highly secure, perhaps even more so than your wired network. The debate is over; the myths are debunked. More to the point is that security is a policy, not just a technology, and this policy transcends both the wired and wireless network. For example, authentication can and should take place on the wired network (802.1x), even when users are wireless. The policy must be integrated and consistent, and cover all use cases, whether wired or wireless. This is a topic unto itself for perhaps a deeper dive in an upcoming blog entry.

5. Increased distributed operations

Wireless networks, especially in the enterprise, are often deployed with what I call the "Old McDonald's Farm" approach - "here a WLAN, there a WLAN, everywhere a WLAN". In other words, WLAN's are seen as a "fill in" technology to cover only specific areas where wired coverage may be difficult or where large numbers of transient connections may be required. Fortunately, just as we all outgrow the joys of "Old McDonald Had a Farm," enterprises are outgrowing this deployment mentality in favor of organized, distributed wireless deployments with centralized management. This of course plays into most of our 5 key themes, including unified networks and unified security policies. The last step is high quality, tightly integrated, centralized management and assurance tools for both wired and wireless. Only then do we achieve true unification.
 

So, why does any of this matter to you? Wireless will save you money and increase productivity, and that's with what has been available so far - a/b/g networks and limited integration between wired and wireless network management. With 11n and an upcoming focus on wired and wireless network unification, we're on the verge of something really big. We'll no longer be singing, "Old McDonald Had a Farm" while planning our wireless network. We'll be scoping wireless into our overall network architecture, and including wireless as an integral part in our selection of network management and assurance tools as well as our network usage policies. Oh yeah, and we'll be saving even more money and making our "network customers" ecstatic.
 

802.11n is a newer standard of WiFi LAN, or wireless local area network technology. For context, preceding standards have equally "exciting" names including 802.11a, 802.11b and 802.11g. Joking aside, in what seems to be consistent in the world of technology, the hype around 80211.n in the trades and blogosphere outpace current realities and deployments.

 

In fact, while not yet mainstream - to date it has not been ratified as a standard by the Wi-Fi Alliance - 802.11n has been mentioned in articles and blogs more than 1,000 times in the past six months according to ITDatabase.

 

Beyond the general appeal of 802.11n being the latest and the fastest WiFi LAN, there are certainly benefits with 802.11n - three worth mentioning in particular.

  

1) Better range

 

While users can expect a variance of capabilities in client devices using 802.11n depending on a host of variables, 802.11n products for consumers and small businesses deliver at least twice the range of 802.11g products. If you add in enterprise Access Points (AP), the range can grow well beyond that.

 

2) Runs on 5-gigahertz spectrum

 

802.11n runs on the 5-gigahertz spectrum, which is beneficial because there are fewer devices in that spectrum. By comparison, 802.11b and g run at 2.4- gigahertz. Many have had to move from b and g just to avoid interference with microwave ovens, cordless phones, Bluetooth, etc. Their environments were too noisy yielding too much interference. They literally had to change technology - to 802.11a, which also runs on 5-gigahertz spectrum - to fix their issues.

 

3) Backwards compatibility

 

As mentioned above, 802.11a runs on the 5-gigahertz spectrum while b and g runs at 2.4- gigahertz. Here's the cool part - n also runs on 2.4 and 5. What's the significance? Backward compatibility. Prior, 802.11a was not backwards compatible with b or g. It was a cost benefit issue on changing technologies. Now, those who have invested in either spectrum have an option to start upgrading to n. They simply take parts of their environment as necessary to the 5-gigahertz spectrum, which removes a lot of their interference while at the same time having complete backwards compatibility with all their b and g technology.

Google Maps Mania

| No Comments | No TrackBacks

Two years ago, WildPackets released the first version of the Google Map Plug-in for OmniPeek. It was an instant hit then, and continues to be the most downloaded plug-in on the WPDN.

The Google Map Plug-in is free, so that is a pretty good reason to at least try it. But more than that, it is a compelling mash-up of two very useful applications. Since then, WildPackets has released a virtual army of Google Map downloads, including two OmniPeek Google Map Plug-ins, a remote Google Map client for the OmniEngine called OmniMapper, and a very simple to use, standalone Google Map application called PlaceMap. Ok, so that's only 4. Still, it is more Google Map applications than most companies have.

In case you don't know, the OmniPeek Google Map Plug-in maps the locations of network devices to the Google Map. Different colored markers are used to represent network devices, where each marker has a color that specifies the amount of traffic from a device. By clicking on a marker, a balloon appears with more information about the IP address. In the balloon, there are also helpful links that will take you to websites with more information about that IP address. The websites include DShield, Whois, SpamCop, and SenderBase.

This week, WildPackets posted a new version of the Google Map Plug-in, as well as a new version of the PlaceMap application to the WPDN. The new Google Map Plug-in is sporting a new look, with a fancy tool bar, and much better marker drawing. PlaceMap has all of the new features of the plug-in, plus it runs all by itself. No OmniPeek necessary. Of course, running within OmniPeek provides much more information about the network. But for high level monitoring, PlaceMap is a good place to start.

The Google Map Plug-in is what we call the good map. It represents all network traffic, or at least the traffic that can be mapped from an IP address to GPS coordinates. This is great for some types of monitoring, but when it comes to network troubleshooting, most IT people are only interested in the bad map. This is the map that displays network devices that are experiencing unacceptable levels of latency. In OmniPeek, we call this an Application Performance Index or APDEX score, and when a users APDEX score exceeds a certain threshold, an event is generated. Sound interesting? Well, we wrote a song about it. Actually, it is a plug-in called the APDEX Google Map. It is the "bad map", and only maps nodes whose APDEX scores have exceeded the specified threshold.

But ah, you have an OmniEngine? Or even better, you have multiple OmniEngines, running at different sites? Hmmm, then you should try OmniMapper. OmniMapper is a standalone Windows client that aggregates nodes from multiple distributed OmniEngines, and maps them all to the same Google Map.

And this is just the tip-o-the-berg. Who knows what we will do next. Actually, I do. :-} But if you have any requests, please let us know.