December 2001
Networks Work Great
(Without any users…!)
December is generally the most welcome Month for network fire-fighters (post
Y2K). It's the time of year when many users are on vacation, and network
problems seem to disappear. There is not much use in baselining a network with
many users absent, so what is a network person to do? Head to the lab! Don't
have a lab? Now might be a good time to set one up!
Setting up a lab does not have to be expensive or elaborate. A lab should
consist of EtherPeek, a server, workstations, switches, routers, and lots of
cables. The lab should resemble your live network as closely as possible. In
many instances, start-up lab costs can be justified as the means for providing
backup replacements against a main node failure. And labs will return the
investment quickly as they become the venue for testing hardware and software,
even before they are introduced to a live network.
A packet analyzer is a critical resource in a lab environment. EtherPeek should
be used for verifying anything from utilization to QOS devices for capturing
application data, as well as for studying the program's graphs, charts and
decoders. This will ensure that everything is working the way it should be
working. And, because EtherPeek has the ability to play back previously captured
packets and can even change the values inside the packets, it is an excellent
testing tool for "hexadecimal hobbyists"!
AN EXAMPLE LAB TEST SCENARIO
People often ask if EtherPeek can capture traffic and then increase that traffic
to simulate multiple users on a network. While this is possible, it discounts
too many aspects of network communications, including TCP/IP negotiation,
application negotiation, switching, routing, precedence, and how a server will
react. For example, you baseline a new application and are able to successfully
capture one session from client to server. You then want to play this back in
multiples to simulate multiple sessions. But the application only allows one
simultaneous user! It works well for one user, but the search function is very
labor intensive, and two sessions may significantly impede the server. Your plan
involved installing this application on a server running many other types of
software with multiple users, so discovering this problem saves many days of
troubleshooting!
To make lab exercises like this fruitful, you will want multiple clients,
multiple size files, and you may also want to produce some background traffic to
mimic live network levels and activity.
STEPS TO LAB SUCCESS
- Set up your lab to reflect the architecture of your network, i.e., hook
up clients and server to a switch. Or, if clients will be at 10 half and
server at 100FX, set up the lab to emulate this.
- Ensure EtherPeek is set up correctly and port mirroring/spanning is
enabled on switches. It is important not to set filters initially, because
you want to know about everything that is on the network.
- Start with one controlled session from one client to the server. A
controlled session includes knowing how large the file is and how the search
mechanism works in the server. Be mindful of any caches (making testing
biased to pre-accessed files) and delete these caches between tests.
- Continue with additional clients, and move to larger files and multiple
smaller files to replicate a live network situation.
- Save the trace-files in a naming convention that states what the
test was (file size, # of nodes, etc.) for future reference.
After lab testing, you will know how an application should work; if it doesn't
work the same way in the field, you will have a greater understanding of the
source of the problem. You will also have a greater knowledge of how
applications will work with existing bandwidth and when to plan on increasing
that bandwidth.
United States
UK
