TechRepublic member REZUMA
recently posed this question in the Technical Q&A:

“I have a new client who wants me to solve a few
problems and also to do a report of things that could be improved. It is a Windows
2000/2003 network with several satellite offices, so I know that I need to
check the router, Active Directory sites configuration, etc… I am wondering is
there is a book or paper that gives you an organized step by step of things to
do when auditing a network. I could work on my own protocol of auditing a
network but I would prefer to see if somebody has already done this.”


TechRepublic member steve.freke
responded with a detailed recommendation for getting started with a network

“I would use the OSI model. Define what it was layer 1
– that is, all the physical connectivity between the active devices on the
network. This includes cable runs between server rooms and wiring closets. This
step will take the longest and is the most often ignored because it is the most

“Move up to layer 2 – document collision domains, STP
instances, etc. Move to layer 3 – document broadcast domains, subnets and
routing instances, including which routing protocol is being used, interface IP
addresses, etc.

“Once you have documented layers 1-3 and understand the
network infrastructure, you can start looking at the client/server
infrastructure. There are many tools available, but you probably won’t have the
budget to spend $10K on audit or packet analysis tools. You can manually get this
info from examining the active equipment, ARP tables (cross referenced with
forwarding tables), and the routing tables. DHCP scopes are also useful.

“Ensure that you have a complete picture of each layer
before you look at the next. If you don’t have an accurate picture of layer 1,
any info you collect about layers 2-3 will be flawed. For example, I once
discovered that a cable I thought ran the length of the building was actually two
cables connected with an old bridge that was hidden in the ceiling and also
happened to be an STP root bridge. Disconnect that and the network would stop.

“Be methodical and take the time that is necessary to
complete the task. I once audited a 2,500 desktop site with 80 servers in a
farm. Working by myself for 12 hours a day for 4 days of the week, it took me
nearly 3 months because I could trust nothing the client said, since he had not
conducted a reliable audit using a sound methodology. It turned out he had two
STP instances running, which explained why his network stopped working when he
disconnected an “unused” segment.

“Never trust what the client says – always confirm any
information for yourself. If he was to be trusted, you wouldn’t be needed in
the first place. Collect your raw data and then use it to produce node lists
and physical and logical diagrams.”


The text of discussion posts from TechRepublic members has
been slightly edited for spelling and clarity.