Here’s the scenario: The development guys have just deployed the new version of your CRM application, and the infrastructure group has finally upgraded the backbone to Gigabit Ethernet. So why are the users still complaining about poor performance? Where’s the bottleneck?
You could spend hours doing trial-and-error troubleshooting. Or you could quickly get to the root of the problem using a network forensics tool such as the NetSensory NP-500 from Network Physics.
This 1U appliance may be small in stature, but it is big on performance. The NP-500 captures, collates, and analyzes enterprise network traffic at speeds of up to 20MBps. From there, it equips IT staff, from network designers to help-desk personnel, with the tools to drill down into captured data and efficiently identify problems such as slow servers, congested links, worm outbreaks, or bandwidth hogs.
Installation of the NP-500 requires connecting the appliance’s capture port to the span, or mirror, port of a managed workgroup switch. The NP-500 comes with two monitor ports so you can monitor two different sources at once. Choosing the proper location in the network infrastructure is important: Make sure that the traffic flows you will be monitoring pass through the switch and that the traffic is mirrored to the NP-500. Notably, the NP-500 only has copper interfaces; its big brother, the NP-2000, has copper and fiber interfaces, and can monitor traffic speeds at more than 750MBps.
Initial setup is accomplished via a browser-based UI, but all day-to-day management is done through a Java-based UI. The NP Management Console is a typical Java app: a little sluggish, but well organized overall and neatly laid out. I was able to navigate it without too much trouble.
Part of the configuration of the appliance involves defining business groups. These groups are nothing more than logical containers of network resources based on their IP addresses. For my tests, I had one business group that had my Windows Small Business Server 2003 as its only member, while other business groups included my local and remote LAN clients.
It is important to define the groups correctly from the start. While the NP-500 looks at all of the traffic sent to it, it only stores detailed information based on the business groups. I found that even though the appliance had been capturing traffic for weeks, I couldn’t analyze any traffic prior to a new business group’s creation. This is by design; because the data captured can grow so large, only the information specifically associated with a business group is kept for ongoing analysis.
The NP-500 does more than simply sniff packets on the network. It measures app response time and network performance, and helps track down traffic anomalies such as worm outbreaks. It does this by analyzing each packet of data, both TCP and UDP (User Datagram Protocol), and by measuring various aspects of an IP conversation. Some of the metrics collected include server-response time, data-transfer time, time to first byte, initial application-response time, and round-trip time.
Many applications use persistent TCP connections to reduce the number of TCP sessions between client and server, thus improving network performance. Network Physics uses the concept of a “turn” when describing application response instead of simply counting new TCP connections. A turn is a single request-response interaction between client and server. The NP-500 can “see” inside of the nailed-up TCP connection (one that is open for an extended period of time and is reused by the same application) and count the number of turns for a specific period of time.