Network Computingwww.networkcomputing.com

Few employees work all hours of the day, but probes can provide information and alert your operations staff to outages or problems that occur at any time without your having to rely on the service provider for notification. And there's nothing more effective at keeping your provider honest than having data in hand to show when and how often outages occurred. Knowing how much traffic an individual link handles also can be an important factor in the decision to upgrade that particular link. And armed with individual stats on IP addresses, you can easily determine if employees are just checking e-mail occasionally or running their own adult Web sites on their desktop systems.

Probing Questions

The first thing to look for when choosing a probe is how it connects to your WAN. You'll have two options: vampire and inline. A vampire probe sinks its teeth into a line and monitors traffic by copying all the data that travels past it. This probe usually requires a "T" connection to be placed on the line. But in the vampire's favor, once the connection is inline, the probe itself can be replaced or removed without interrupting data flow.

Inline probes have matured over the years and are now a little easier to handle. They are placed between the ingress and egress data flows. Early versions would stop all data traffic in or out if power to the probe was lost or if the probe went four paws to the sky. Most current versions automatically pass data even with the power disconnected. If you choose an inline probe, make absolutely sure the only reason it would stop data flow is because of a cable disconnect. While human error can cause an unintentional power loss, a more pressing concern is the remote chance that the device will go south.

If you can afford to place probes on all your network connections, both inline and vampire work well. However, if you must move a probe around a lot, it may be less frustrating to users if you purchase several vampire cable attachments and bring the lines down only once--instead of each time you need to move an inline from network to network.

Feature Comforts

Consider features next: specifically, what types of data the probe monitors, how it keeps stats and how long it will maintain this information before its buffer overflows or begins erasing data.

On the statistics front, it's crucial that your probe monitor dropped frames or cells. While probes report when packets are dropped below CIR (committed information rate) or SCR (sustained cell rate), they may not tell you when frames or cells are pushed above CIR or SCR. You'll need to be notified of the former because of possible SLA (service-level agreement) violations within the carrier's network that require your attention. Knowledge of the latter condition is useful so you'll understand just how congested your carrier's network is. If bursting is consistently close to port speed or PCR (peak cell rate), your carrier probably has little congestion and overbuilds its network well. If, however, you are unable to get above CIR/ SCR, your carrier may have some serious congestion problems that might eventually cut into your data flows.

Methods for determining throughput and packet-size distribution vary from vendor to vendor. Some probes take averages on a per-second basis, and that's how the data is presented. But if your traffic is occasionally bursty, you may never know about it. If you want a more accurate accounting, look for a probe like Paradyne Corp.'s FrameSaver, which monitors traffic on a per-packet basis. This type of probe creates "bucket counters" for varying traffic types; when a packet comes in, it is noted by the applicable counter depending on what size it is and whether it fell into or above CIR or SCR.

Of course, all this data won't do diddly unless you have some sort of management capability. Management capabilities can be as simple as SNMP support by the probes or vendor-specific NMS (network-management software). Both management types have their advantages and disadvantages. Using an SNMP management system lets you integrate one piece of software into all areas of your IT department--from monitoring probes to servers. While all probes should support SNMP data collection, vendor-supplied software may have capabilities unavailable in a third-party application.

Regardless of which way you go with network management, also consider your methods of data acquisition. Some vendors require the probes to communicate with the NMS via a separate PVC (permanent virtual circuit), but it's preferable to have the probes communicate over the same PVC that your normal traffic uses. The traffic increase is negligible and the cost savings can be substantial if you have a large network.

Your probe also should hold its statistics for several hours without being polled by the management system. Outages can occur--and not only from the WAN connections. If the NMS is down, the probe needs to maintain its data and continue collecting. While the probe is up, data is best obtained by polling the probes every few minutes. However, it's not uncommon to poll them only once a day, so make sure your probes can handle the wait.

Analyze This

WAN analyzers reside higher up the OSI ladder--and the price scale--than do probes, but analyzers provide a level of detail on WAN traffic that is simply unavailable to probes. You're probably accustomed to having a LAN analyzer around so you can have a look at the Ethernet traffic running over your internal network. It should be comforting to know that WAN analyzers aren't much different. WAN analyzers are generally designed for inline network placement so they can monitor the traffic going over the line and decode that traffic-- packet by packet.

If you have WAN connections, you should have a WAN analyzer in your shop, but it is usually cost-prohibitive to all but the larger enterprise customers. WAN analyzer prices can start in the tens of thousands and climb to the hundreds of thousands. Depending on the interfaces needed, it's even possible to spend millions of dollars.

The interfaces, and the chassis into which they fit, are the first things to consider. In design, WAN analyzer chassis can start the size of two thick laptop computers stacked on top of each other, like the Acterna Corp. (formerly TTC/Wavetek Wandel Goltermann) Fireberd 500. This design is beneficial because it's a self-contained unit with a built-in monitor and keyboard. Just plug in the interface and you're good to go. However, there are two major drawbacks. First, the unit typically accepts only one interface at a time. If you need an interface other than what's installed, you must power-down the unit, swap the interface and then power back up. Second, this type of laptop-based device is not known for its expandability past OC-3 or even DS-3. It is great for connecting to DS-1 or DS-3, but if your network expands to greater bandwidths, you'll need something larger. If you don't mind single-interface units and want something even smaller to carry around, Acterna's Domino series offers compact single-interface modules for BRI, PRI, DS-1, V.35 and twisted-pair Ethernet (for the LAN) that can be attached to your desktop or laptop computer.

To avoid these drawbacks, you'll need to move to a larger chassis, which you can do in one of two ways: You can step up to four- to six-port chassis, or you can climb up to a 12- to 16-port design. A smaller unit has a portability advantage since it usually incorporates a built-in handle. But even though you can carry the smaller units around, they're not self-contained units. Both the luggable and the larger WAN analyzers have their own processor units and hard drives but require either a monitor and keyboard or a LAN connection to a remote system to operate. Luggable chassis analyzers are available from Acterna, Adtech and GN Nettest.

Remote Analysis

The larger 16-port units from Adtech and Agilent Technologies are Unix-based and can be remotely controlled via an X terminal or remote software. When WAN analyzers require their own remote software, there are usually versions available for popular platforms like Microsoft Windows and Sun Microsystems Solaris. If you need to access the WAN analyzer from a different platform, make sure it's supported or consider purchasing a unit that runs the software locally and is accessed via an X terminal.

No matter where the software runs, many WAN analyzers can be placed in an equipment room and remotely controlled from a desktop computer via an Ethernet connection. This capability lets you go about your business at your desk while the WAN analyzer runs a test. WAN analyzers with a multislot design can hold more interfaces simultaneously, thereby avoiding the need to swap out cards, so the unit can run continuously. And since most of these larger units accommodate multiple users at the same time, you'll save yourself and your co-workers a lot of headaches.

Both the large and the small chassis can hold higher bandwidth interfaces--even OC-192 is now available. Your future bandwidth requirements will be the deciding factor between the laptop-based units and the larger ones. If you're going with the larger units, your decision among those will depend on the number of interfaces you want available concurrently and how portable the units need to be. It's important to note that some WAN analyzers, like the Adtech AX/4000 and Agilent 75000, require the interfaces to function in pairs. One card is the dedicated generator/analyzer card; the other is the actual interface module. When you do the math, a four-slot chassis actually holds only two interfaces at once.

Obviously the WAN interface will analyze the particular transport protocol, but the ability to decode the higher layers is another matter. You can combine some of the features of LAN and WAN analyzers by purchasing something that does both lower- and upper-layer protocols. If you have voice-over traffic, then H.323 or SIP (Session Initiation Protocol) decodes would be helpful to see at the WAN analyzer, instead of having to decode such traffic on another unit. Your WAN analyzer should decode--at least--AppleTalk, IP and IPX or the appropriate LAN protocols, then add additional protocols as needed.

Send your comments on this article to Darrin Woods at dwoods@nwc.com.