Sei sulla pagina 1di 68

A Documented Network Is Easier to Troubleshoot

One of the oldest abbreviations used on the Internet doesn't have anything to do with a
specific protocol or network service. It's RTFM. If you ever get this in response to
posting a question on a newsgroup you can probably guess what the letters stand for.
For those who don't know it's so!ething along the lines of "read the fine !anual#"
although "fine" is often replaced with a slightly different word. $se of this ter! is
intended to point out that your question is a si!ple one that you can easily find an
answer to so you should quit wasting bandwidth by your postings.
%ocu!entation consists of the !anuals that co!e with software applications operating
syste!s switches and other network co!ponents. The quality of this sort of vendor&
supplied docu!entation can vary widely fro! one vendor to another. 'ou'll find that
!any co!panies such as (isco Microsoft and )ovell provide a lot of online
docu!entation for their products. Often the docu!entation you get fro! a vendor is a
si!plified booklet co!bined with !ore e*tensive docu!entation on a (%. One of the
!ost widely used for!ats for creating user docu!ents is the +dobe ,ortable %ocu!ent
For!at -.,%F files. and you can download the +dobe Reader application free fro!
www.adobe.com.
/owever after you find yourself with an assort!ent of docu!entationfro! hard&copy
!anuals to files on a (% or a 0eb sitethen it's ti!e to consider what you will use to
docu!ent how your particular network is laid out fro! both the physical and the logical
point of view. 0hen it co!es ti!e to troubleshoot a proble! on the network it's nice to
have docu!entation that enables you to quickly get an answer to such si!ple questions
as "0here are the configuration instructions for that router stored1" or "2ust who is that
user anyway1"
)ote
%ocu!entation !ade available online via the Internet can serve two purposes. First
you can quickly search and find infor!ation in a proble! scenario. 3econd you can
read through any online docu!entation a vendor provides before you !ake a decision
to purchase the particular software or hardware product. +long the sa!e lines you can
also get an idea of the type of support you'll receive if you review the docu!entation
before you buy. If the docu!entation isn't up to par it !ight not !atter how good the
product issupport is everything.
For individual applications or operating syste!s you can visit $34)4T newsgroups
and participate in -or 5ust lurk around and read. discussions about proble!s with
particular products. 'ou !ay 5ust find your answer there. If not you can post your
question. One of the things that newsgroup !e!bers !ost dislike is so!eone posting a
question without providing the details that led up to the proble!. ,rovide the details# If
you read the newsgroups on a regular basis you !ay be apprised of proble!s before
they appear on your network.
Tip
The !ost convenient way to search $34)4T newsgroups is to use 6oogle's 6roup
search option -http788groups.google.co!. and use the +dvanced search option to
specify the groups to search te*t to search for dates and so forth.
3o!e of the i!portant things you should consider as potential candidates for
docu!enting include the following7
+ logical !ap of the network. This !ay or !ay not !atch up with the physical
way the network is laid out.
+ physical !ap of the network. This docu!entation should describe each
physical co!ponent and illustrate the ways in which the different co!ponents are
connected.
(abling and patch panel infor!ation. 0hen you've got hundreds of cables in a
wiring closet patching together different physical seg!ents you'll need to know
which cable connects this to that.
%efault settings for co!puters and other devices on the network. + spreadsheet
is good for this. +n application that !anages servers network co!ponents and
client co!puters is even better.
9istings of applications and the co!puters or users that !ake use of the! as
well as software versions patch levels and so on. :e sure to know who to
contact for a particular application. If you are a network ad!inistrator you are
pri!arily responsible for the underlying network. If a particular application is
failing but the network is up and running you need to know who to call. There
should always be a contact on your list for application !anagers. + network
!anager can do only so !uch.
Infor!ation about the user accounts and associated per!issions and rights for
the users and user groups on the network.
+ network overview. It's nice to be able to give a new user a docu!ent that
e*plains what she needs to know about the network. This should be a short
docu!ent telling the user such things as which drives are !apped to her
co!puter and which printers offer what features. This should not be an
e*tensive docu!ent such as the physical and logical !aps described earlier in
this list.
,roble! reports. ;eep track of proble!s as they arise and docu!ent the cause
and re!edy. )o need to solve the sa!e proble! twice# This also includes
outage reportskeeping track of unscheduled downti!e for a co!puter or network
device can tell you over ti!e 5ust how capable the device is.
+ logical !ap of the network shows the relationships between co!ponents and the flow
of infor!ation through the network. + physical !ap of the network tries to appro*i!ate
on paper a representation of how each co!ponent of the network is connected to the
network. For e*a!ple a logical !ap for a 0indows network !ight show co!puters
grouped by do!ains even though the co!puters are not located physically in the sa!e
part of the network. + physical !ap would show the location of each of the co!puters
the hub or switch to which they are connected and so on. In general logical !aps can
be used to help isolate configuration or application proble!s whereas physical !aps
can be used to isolate a proble! that affects only a portion of the network perhaps a
single co!puter or other device.
'ou can do the sa!e for any 4thernet or other technology&based network. ;nowing the
physical layout can be a very i!portant factor in troubleshooting a network proble!. For
e*a!ple $ni* and so!e 9inu* syste!s use both )I3 -)etwork Infor!ation 3yste!s.
and now 9%+, -the 9ightweight %irectory +ccess ,rotocol..
)ote
'ou can learn !ore about )I3 in (hapter <= ")etwork )a!e Resolution." 'ou can
lean !ore about 9%+, in +ppendi* % "The 9ightweight %irectory +ccess ,rotocol." If
you want to learn about a specific instance of 9%+, read (hapter >? "$sing the +ctive
%irectory."
'ou can use si!ple tools such as Microsoft ,aint to create network !apping
docu!ents or you can buy applications that auto!ate the process. $sing an application
that is written specifically for creating network !aps should be considered for anything
but the s!allest network. The capability to locate co!ponents update the! and
produce easy&to&understand printed docu!entation is the hall!ark of a good network
diagra!!ing application. One such tool is Microsoft's @isio which allows you to create
co!ple* network drawings and includes pictographic ele!ents for !ost !odern
network devices that you can easily use.
Inside the wiring closet you can have a tangled !ess of wires on a patch panel that
haphaAardly tie one network link to another. Or you can have an orderly syste! in
which each port on the patch panel is labeled using a standardiAed !ethod so that
!aking changes won't be a hit&or&!iss effort. The sa!e goes for configuration
infor!ation for other co!ponents of the wiring closet such as switch ports or routers.
In&depth docu!entation is i!portant so that you can re&create the configuration fro!
scratch if it beco!es necessary to replace a device.
+pplications should be standardiAed which !eans you shouldn't have !ultiple
applications that all perfor! the sa!e function. It's !uch si!pler to support a standard
application such as an office suite than it is to support !ultiple applications. +nd
although the sa!e configuration !ight not be appropriate for every user you can at
least try to create several standard configurations for classes of users. This !akes
deploying a desktop co!puter for a new e!ployee !uch easier. On that odd occasion
when you find that so!ething nonstandard is required docu!ent that also and also
docu!ent the reasons behind the decision to use an alternative configuration.
;eeping track of which applications are in use and how they are configured serves
another purpose. 3o!e applications interact with others or are tied to specific versions
of an operating syste!. If you have adequate docu!entation of the applications used
on your network you can better plan for upgrades.
+fter you've docu!ented the physical co!ponents of the network and the applications
what's left1 Oh yes the users. If not for the users you would not have a 5ob. /aving a
docu!ent of so!e sort that shows a user profile can be useful for troubleshooting
purposes. If you know only a user's logon userna!e and the na!e of his co!puter you
have little to go on when he calls in with a proble!. If you can quickly locate !ore
infor!ation about the user such as the applications installed on his co!puter or the
privileges and per!issions assigned to the user account or the co!puter then you have
valuable infor!ation to use to help solve proble!s. Often you can't get all this
infor!ation fro! the user over the phone because !any users don't know that !uch
about what resides on their syste!. They know only the applications they use and how
they use the!.
9astly keep track of proble!s. Record the sy!pto!s the tools used to troubleshoot the
proble! and the resolution of the proble!. This docu!entation can assist you in the
future so you can quickly deter!ine the solution to a proble! based on the sy!pto!s
reported by the users. 'ou can also use this infor!ation to assist in creating
docu!entation that you give to new users. :y infor!ing the! of proble!s that have
occurred in the past you can help prevent the sa!e proble!s fro! happening again.
Documentation and MaintenanceKeeping Things Up-to-Date
%ocu!entation is an ongoing process. )etworks rarely stay the sa!e for a long ti!e. It
has been !y e*perience that the larger the network the faster the rate of change as
users or depart!ents are relocated and new equip!ent replaces older equip!ent. 3o
when you consider what !eans you'll use to create network docu!entation be sure to
take into consideration that it will need to be updated and you'll need so!e way for
keeping track of changes in an orderly fashion.
3o!e of the tools you can use to create network docu!entation include these7
0ord processors and spreadsheets 4ach of these is beneficial. 0ord processors
enable you to create professional&looking docu!ents that can be easily changed
and reprinted. 3preadsheets can be used to locate infor!ation quickly and that
infor!ation can be easily organiAed by inde*ing.
Online tools $se si!ple 0eb pages to create online docu!entation. If you have
a specific application that has been custo!iAed for your network create a
frequently asked questions -F+B. docu!ent for it and put it online -on your
intranet.. +dditionally you !ight shy away fro! pointing users to F+Bs and other
docu!ents available on the Internet unless they are sites known to contain
accurate infor!ation -such as www.rfc-editor.org.. There is a great deal of
infor!ation as well as disinfor!ation on the Internet.
)etwork !apping tools Microsoft's @isio and other applications can assist you
with developing a co!plete !ap of your network. This type of tool is not
ine*pensive but it !ay prove invaluable in a large installation.
/ard copy ,rinted paper docu!entation. Two words7 Read it.
Tip
0hen you find a useful page online you can save the page and all its graphics as a
single file by using Internet 4*plorer. (lick File 3ave +s and specify 0eb +rchive as
the file type.
This is also a useful way to record the current configuration of a router a wireless
access point or any other device with an integrated web server.
Word rocessors and !preadsheets
These two tools can be useful for creating docu!entation. 'ou can use either one to
gather infor!ation about the network and organiAe it to locate infor!ation quickly and
easily. 0ord processing and spreadsheet applications are easy to update and for
instances in which printed docu!entation is necessary !ost of these progra!s provide
e*cellent for!atting and printing capabilities. For e*a!ple you can use tables in
Microsoft Office's 0ord progra! or possibly a spreadsheet to create a list of all the
network devices and co!puters that have an I, address assigned to the!. If you want
to locate a particular ite! of data 0ord enables you to search a docu!ent and
spreadsheets allow you to create !ultiple indices so that i!portant identifiers are sorted
to !ake it easy to locate infor!ation.
For a typical 9+) today it's likely that you'll have only a few i!portant devices or
servers that have static I, addressing infor!ation assigned. It's easier to use %/(,
servers to allocate I, configuration infor!ation to co!puters auto!atically when they
boot. To keep track of dyna!ically assigned I, configuration infor!ation you can
consult the %/(, server application to deter!ine what listing or reporting features are
available. For co!puters or devices you configure with static I, infor!ation you can
use a spreadsheet to keep track of this infor!ation. Then when it beco!es necessary
to replace a router or si!ilar device you can consult the docu!entation to get the
required configuration infor!ation to use on the replace!ent.
)ote
The %yna!ic /ost (onfiguration ,rotocol -%/(,. is discussed in detail in (hapter <C
":OOT, and %yna!ic /ost (onfiguration ,rotocol -%/(,.." If you use the Microsoft
%/(, server that co!es with 0indows <??? 3erver and the 0indows <??> fa!ily of
servers you can also enter into the %/(, database the static infor!ation that you
!anually configure so!e of your servers or devices to use. 'ou can do this by entering
static I, addresses and setting up reservations using the 6$I for the %/(, service. In
addition to being sure that the %/(, server doesn't try to use an address that you've
already !anually assigned to another co!puter this enables you to use the %/(,
database for reporting and analysis. Microsoft's %/(, server and !any others allow
you to e*port data to files such as co!!adeli!ited +3(II te*t files that can be
i!ported into progra!s such as spreadsheets or other databases.
Many other progra!s and utilities have "output" capabilities so that you can send their
infor!ation to a file. For e*a!ple on 0indows -both workstation and operating&syste!
platfor!s. fro! earlier versions to 0indows 3erver <??> servers the IPCONFIG
co!!and can be used to display infor!ation about the current I, configuration on the
co!puter. If you use the synta* ipconfig /all > %computername%.txt the output fro!
the co!!and is sent to the file na!ed the sa!e as the co!puter's na!e with the .txt
e*tension instead of to the screen. The point is that you don't necessarily have to
!anually create all your docu!entation. Instead !ake use of the tools and utilities
provided by the operating syste! and applications to get the data and then i!port it
into other progra!s that !ake it easier to !anage.
Other i!portant things you !ay want to consider keeping track of for individual
co!puters include the particulars of the hardware that !ake up the syste! any
custo!iAations !ade on the syste! that aren't part of a standard and the user-s. of the
syste!. If the co!puter is a server on your network it's a good idea to keep track of
contact phone nu!bers for client representatives so that you can keep the! infor!ed
during any troubleshooting efforts or downti!e.
"nline and aper Documentation
The paperless office that was forecast during the early days of the ,( revolution in the
D=C?s has yet to co!e about. )o !atter how s!all ,%+s and laptops beco!e it's
generally easier to sit down with a printed !anual. /aving to stare at a screen for hours
at a ti!e can be a lot !ore cu!berso!e. +lthough word processors and other
progra!s are great at !aking it easy to find infor!ation quickly so!eti!es the best
option is to print things for easier handling.
Today it is not unco!!on to find paper docu!entation being replaced by hyperlinked
te*t files on a 0eb site. Instead of looking in the inde* of a book to find the infor!ation
you need you can utiliAe the 0eb. + 0eb site can be useful for several reasons. First
for co!!on proble!s a si!ple F+B docu!ent can help end users solve proble!s
the!selves so that your help desk doesn't get a call. 3econd for those who do sit at a
help desk clicking through a set of links to find infor!ation can be faster than having to
5uggle one or !ore !anuals and talk to the end user on the phone at the sa!e ti!e.
User #eedback $an Impro%e Documentation
'ou can easily 5udge how well your docu!entation assists end users by soliciting
feedback. If you create the greatest looking docu!ents that can possibly be created
that won't !atter if the end user can't !ake sense of the content. +fter you've created
any kind of docu!entation be sure to provide a !echanis! that can enable users to
provide you with questions or co!!ents on the docu!entation. Take these suggestions
into consideration when it co!es ti!e to !ake updates.
http://www.freeopenbook.com/upgradng-reparng-networks/ch48ev1sec1.htm
http://technet.mcrosoft.com/en-us/brary/bb726961.aspx topc 2
Network Analysis and Optimization Techniques
27 out of 31 rated ths hepfu Rate ths topc
By Dane |. Nassar
Chapter 5 from Network Performance Baselining, published by New Riders Publishing
When performing a network baseline study, specific techniques enable an analyst to troubleshoot
network issues. ome of these techniques in!ol!e processes discussed earlier in this book, such
as utili"ation and quantitati!e measurement analysis. #nique methods e$ist to isolate specific
traffic flow e!ents, which can be !ery helpful during isolation and statistical baselining.
%irst, an analyst must engage the standard methodology as presented in the preceding chapter.
Ne$t, the analyst should apply techniques that pro!ide a more focused re!iew of dataflow from
each specific baseline session. ome of these techniques can be applied to cause isolation& others
can be used to optimi"e a network's performance (see %igure 5.)*.
Figure 5.1: The main network optimization techniques.
+mong the techniques in!ol!ed are the following,
Physical health analysis
-roadcast storm analysis
Network capacity o!erload analysis
Network throughput analysis
Network end.to.end interpacket timing analysis
/ransport and file retransmission analysis
Packet route and path cost analysis
0nd.to.end file transfer analysis
1rill.down data.decoding steps and specific techniques
/he techniques listed abo!e will yield a palette of data information that will be e$tremely
!aluable in problematic and network baseline data profiling situations.
When re!iewing a data trace during a network baseline session, an analy"er's 0$pert system
output information or the internal indications in the data trace may immediately point to a
specific type of problem, such as e$cessi!e physical errors. Rather than quickly taking the
information from the 0$pert system and immediately attempting to troubleshoot the specific area
of the network flagged as troublesome, the analyst should also further e$amine the internal data.
trace results. 2t is highly likely that the data.trace internal !iew holds additional information that
should also be re!iewed and cross.mapped to a higher.le!el report information.e$traction engine
or 0$pert system screen results. %urther e$amination of the data trace will most probably result
in a more e$act cause analysis mapping of the problem, yielding a more e$act technical synopsis
and applied recommendation.
/his chapter describes each analysis technique. /hese techniques should be applied when
performing a network baseline study. /his is important so that you can isolate issues to their
e$act cause and profile data for optimi"ation reasons.
On This Page
Physical 3ealth +nalysis
-roadcast torm +nalysis
Network Capacity 4!erload +nalysis
Network /hroughput +nalysis
Network 0nd.to 0nd 2nterpacket /iming +nalysis
/ransport and %ile Retransmission +nalysis
Path and Route +nalysis
0nd.to.0nd %ile /ransfer +nalysis
/race 1ecoding /echniques
Conclusion
Physical Health Analysis
/aking into account the many physical topologies in the 5+N and W+N en!ironments, it is
natural to assume that many different physical error types may be encountered. When performing
physical health analysis in a network baseline session, it is important to quickly note all
information gathered in an 0$pert system or management system platform. 2nformation related
to error type, time of the error e!ent, the associated addresses or network segment in!ol!ed with
the area in question, and protocol e!ent sequence in!ol!ed with the error must be clearly
documented. /he internal data.trace analysis results should then be cross.mapped to the output
report of the error.
6any different host systems and internetwork de!ice platforms (such as routers and switches*
ha!e their own internal method of reporting errors through !arious management platforms. 6any
different protocol analysis and management tools report error.count le!els and time.of.
occurrence conditions. +ll these systems yield !aluable 0rror log or error.report information,
which is a primary focus area when re!iewing data. /he 0rror log information must always be
carefully gathered and documented.
%or the purposes of illustrating error.report gathering, the following discussion describes how to
apply this approach using a protocol analy"er tool.
Using a Protocol Analyzer for Error-Report Gathering
+ protocol analy"er used during a network baseline session enables an analyst to quickly assess
the types of errors encountered, the error count, and the time of occurrence. /his rele!ant
information pro!es e$tremely !aluable because it assists in identifying the error e!ent and the
possible impact of the error on a network. 2n a reacti!e analysis session, this information is
crucial and rele!ant to a rapid troubleshooting process. 2n a proacti!e network baselining session,
this information is also important& howe!er, the information can be quickly noted and
documented for later re!iew through the baseline process. /his is especially important during a
large internetwork study in!ol!ing many different network areas, because certain physical errors
may repeat and show a pattern of e!ents that might be related to a center networking de!ice, such
as a main computer room hub, switch, or router. Within the protocol analysis capture, the error
e!ent is contained within a frame or a packet sequence, depending on the 5+N or W+N
topology.
2t is important to cross.map the statistical 0rror log or output report from a specific management
system (if one is present*. 2t is important to map the 0$pert results with the internals of the
protocol analysis dataflow e!ents. /he protocol analy"er error.reporting screens should be
carefully e$amined for the key error e!ent. +fter the error e!ent information has been noted, the
protocol analy"er should be paused or stopped. /he capture should then be immediately sa!ed to
disk to ensure that the error frame or error frame occurrence is stored properly within the
protocol analy"er platform. /he data trace should then be opened and re!iewed carefully,
following a 7page through the trace7 process. /he process of paging through the trace 8ust
in!ol!es slowly mo!ing through the internal data gathered by the protocol analy"er to locate any
unique anomalies. ome protocol analy"er 0$pert.based systems ha!e a hotkey filtering system
to quickly filter to the error e!ent inside the data.trace results.
+ protocol analysis trace taken during a network baseline session, may contain a large number of
packets and frames. ome data traces could contain 59,999 or )99,999 frames or e!en more
within one single capture. 2t can be quite cumbersome to page through the complete data trace
after the trace has been opened for re!iew. +n 0$pert system feature pro!ides a hotkey filtering
system can facilitate an immediate e$traction filter based on the error occurrence in the particular
analy"er 0$pert system screen. /he approach in this case is to highlight the error on the analy"er
0$pert system or statistical monitoring screen. +fter the error has been highlighted, a an analyst
can use this feature to quickly filter to the area within the set of packets within the o!erall data
trace to the e$act area of the error occurrence. +fter the error e!ent has been found, other
rele!ant information in packets surrounding the error occurrence frame may also be identified&
these may point to the actual cause of the error.
+n ine$perienced analyst may too quickly map the cause of a problem to an 0$pert system error.
output report or a management system 0rror log. -y using the actual data.trace error e!ent and
packet.sequence re!iew process to access packet data around the error, it is possible to be more
defined and accurate as to the cause analysis. 2n summary, a thorough re!iew of the error frames
within the trace may unco!er packets or frames surrounding the error occurrence that may
pinpoint the cause of a problem.
Consider, for e$ample, ):6bps /oken Ring network that is operating abnormally from an upper.
layer application standpoint. #sers are complaining significantly about performance. 2n this case,
the analyst should immediately deploy a protocol analy"er, because this is a rapid baseline
situation (or a reacti!e analysis e!ent*.
+s stated earlier, certain quantitati!e baseline measurements must be taken prior to topology
error analysis, such as utili"ation, protocol percentages, and other statistical measurements. 2f the
analyst mo!es through the initial steps in the quantitati!e baseline measurement process and
notices a high number of error reports from the protocol analy"er indicating a high ring purge
error 6+C occurrence, this is a rele!ant e!ent.
+ssume, for e$ample, that through an analysis session a high number of ring purge 6+C frames
are found within a /oken Ring en!ironment. /he protocol analy"er could then 8ust stop the
capture, sa!e the information, and filter on the ring purge e!ents !ia a hotkey filtering system.
/he analyst could identify the ring purge 6+C frames within the /oken Ring trace analysis
session. 2f, prior to the ring purge 6+C frames, it is noted that e$cessi!e ring insertion failures
are associated with a specific de!ice, or e$cessi!e oft 0rror Report 6+C frames, this might
indicate the cause of the ring purge error noted in the 0$pert system or 0rror log. Chapter ;,
7/oken Ring and witched 0n!ironments,7 discusses /oken Ring issues in more detail. /his is
8ust one e$ample of how internal data.trace analysis, as associated with 0$pert system mapping,
facilitates a cross.re!iew process that yields a more accurate analysis.
+nother illustration is an 0thernet internetwork that is showing a high number of corrupted CRC
frames within the analy"er 0$pert system analysis screen. 2f the protocol analy"er filters on the
artificial intelligent 0$pert screen displaying the CRC corrupt 0thernet errors, the analyst should
then mo!e directly to the internal area of the trace that shows the CRC.corrupted error frames
in!ol!ed. -y doing so, the analyst can determine that prior to the CRC frames, and possibly after
the frames, certain frames indicate a high number of communication e!ents on the 0thernet
medium. -ecause the 0thernet medium engages a carrier sense multiple access/collision
detection (C6+<C1* sequence that is an ongoing process and is part of the 0thernet
architecture, the cause analysis can be somewhat comple$. Certain 0thernet frames, when
including errors such as a CRC type, may be shorter than normal and may ha!e physical
addresses that cannot be interpreted. -ecause of this, sometimes the source and destination
addresses may not be able to be read related to the CRC error cause. 2f prior to the CRC error
frames, the trace shows that a certain set of de!ices are communicating, it is quite possible
(based on the operation of C6+<C1 within 0thernet* that these de!ices are in!ol!ed in
con!ersations when a high number of CRC errors are occurring.
2f retransmissions of frames at the 0thernet le!el are occurring, it is !ery possible that the CRC
errors that are not readable are related to the frames that communicated most recently prior to the
CRC error. /his is another e$ample of how a cross.mapping of the internal data.trace results as
related to the analy"er 0$pert system are in!aluable to protocol analysis and network baselining.
5ater in this book, specific topology techniques such as analysis of /oken Ring errors, 0thernet
errors, and W+N errors is discussed in detail. 2n the conte$t of this discussion, howe!er, the
point is that more is in!ol!ed in isolating errors !ia network baselining other than 8ust a simple
re!iew of protocol analy"er 0$pert screens or management system 0rror logs. +ll error reports
encountered in these types of systems should be backed up by a close re!iew of the internal data.
trace results. /he information should be cross.mapped between the management or 0rror log
systems and the internal data.trace results. /his method allows for a more accurate physical
health analysis technique (see %igure 5.=*.
Figure 5.: Approach o! physical health analysis.
Top of page
Broadcast Storm Analysis
When encountering a broadcast storm in a network baseline session, analyst can apply a specific
technique to isolate the cause of the storm and the possible effect of the broadcast e!ent on the
internetwork.
+ broadcast storm is a sequence of broadcast operations from a specific de!ice or group of
de!ices that occurs at a rapid frame.per.second rate that could cause network problems.
Network architecture, topology design, and layout configurations determine the network's
tolerance le!el as it relates to frame.per.second broadcasts.
Consider, for e$ample, a frame.per.second rate related to a broadcast storm generation of a
specific protocol (Address Resolution Protocol >+RP?, for e$ample*. uch generation, at more
than 599 frames per second and on a continuing basis, is considered an abnormal protocol.
sequencing e!ent and can be e$tremely problematic.
/he key here is to understand the difference between a normal broadcast e!ent and an actual
broadcast storm. When a normal broadcast e!ent occurs, the broadcast is engaged from a specific
physical de!ice on a network for the e$press purpose of achie!ing a network communication
cycle. /here are conditions when a de!ice, such as a router, broadcasts information to update
other routers on the network to ensure that routing tables are maintained as consecuti!e and
consistent related to internal route table information. +nother standard broadcast e!ent is when a
de!ice attempts to locate another de!ice and requires the physical address or 2P address of
another de!ice.
When a specific workstation de!ice has a default gateway assigned, a 7normal7 broadcast e!ent
can occur. /he de!ice knows, for e$ample, the target 2P address of a de!ice on the internetwork.
2t is common for this de!ice to broadcast an +RP sequence to attempt to locate the target
hardware address. +RP broadcasting is discussed in detail later in this book.
+ workstation that broadcasts an +RP sequence to locate a target ser!er but doesn't establish a
broadcast resol!e and doesn't recei!e a target hardware address for the ser!er pro!ides an
e$ample of an 7abnormal7 broadcast e!ent. 2f the target de!ice fails or the source broadcast
operation mechanism or protocol.sequencing mechanism of the de!ice fails, the source
workstation de!ice could start performing a loop +RP sequence that could be interpreted as a
broadcast storm. uch an e!ent in itself could cause a broadcast storm.
Figure 5.": #roadcast storm analysis.
/he point to be made here is that the frame.per.second rate of the broadcast sequence and the
frequency of the broadcast sequence e!ent occurrence can constitute an abnormal e!ent.
+nother e$ample can be found in a No!ell en!ironment, when the Service Advertising Protocol
(+P* sequencing is engaged by specific ser!ers. 2f the ser!ers are broadcasting an +P on
standard NetWare sequence timing, the occurrence may take place on :9.second inter!als. 2f
there are hundreds or thousands of ser!ers, the +P sequence packets generated may become
highly cumulati!e and affect areas of the enterprise internetwork that are not utili"ing No!ell
processes.
2n large internetworks, many of these concerns are addressed through protocol filtering within
routers and switches in the network 5ayer @ routing design. When a problem does occur because
of an anomaly or possible misconfiguration of an internetwork, it is important to capture the
information upon occurrence.
-y applying an e$act technique with a protocol analy"er, an analyst can !ery quickly capture a
broadcast storm and identify the cause of the broadcast storm and de!elop a method to resol!e
the storm. 6any different tools enable an analyst to achie!e this. +lmost all management
systems for internetwork hubs, routers, and switches facilitate broadcast storm identification. /he
threshold that determines what is an actual broadcast occurrence !ersus an actual broadcast
storm is usually set by the network manager or the configuring analyst of the network
management platform.
/he following discussion details the use of a protocol analy"er for broadcast storm analysis.
When performing a data.analysis capture, a protocol analy"er is a useful tool for capturing a
broadcast storm. 6any protocol analy"ers ha!e thresholds that allow for an artificial intelligentA
based 0$pert system to identify a broadcast storm. + storm can be identified by preconfiguring
and studying a trigger or threshold for determining what would constitute a storm occurrence.
When performing a network baseline, an analyst should always engage the threshold setting on
the protocol analy"er prior to a baseline session.
Using a Protocol Analyzer for a Broadcast Storm
-ased on the network architecture, the protocols, and the node count on a site being studied, an
analyst must determine what constitutes a broadcast storm. /his requires the analyst to be quite
familiar with the topology and types of protocols and applications being deployed. + general
benchmark is that a broadcast sequence occurring from a single de!ice or a group of de!ices,
either rapidly or on an intermittent cycle at more than 599 frames per second, is a storm e!ent. +t
the !ery least, the sequence should be in!estigated if it is occurring at 599 frames per second
(relati!e to 8ust a few de!ices and a specific protocol operation*.
+fter the threshold has been set on the protocol analy"er, a data.trace capture should be started.
+fter the capture has been in!oked, and a broadcast storm e!ent has occurred in the 0$pert
system with notification or in the statistics screen, the time of the storm and the de!ices related to
the storm should be carefully noted. /he addresses should be noted in a log along with the time
of the storm and the frame.per.second count. 6ost protocol analy"ers pro!ide this information
before the capture is e!en stopped. +s soon as the broadcast storm occurrence takes place, the
analy"er should be immediately stopped to ensure that the internal data.trace information is still
within the memory buffer of the protocol analy"er. /he data trace should then be sa!ed to a disk
dri!e or printed to a file to ensure that the information can be re!iewed. /he data.trace capture
should then be opened and the actual absolute storm time noted from the 0$pert system or the
statistical screen. -ased on the absolute time, it may be possible on the protocol analy"er to turn
on an absolute time feature. When turned on in the data trace, the absolute time feature enables
an analyst to search on the actual storm for the absolute time e!ent. /his may immediately
isolate and identify the cause of the broadcast storm.
Certain protocol analy"ers offer hotkey filtering to mo!e directly within the data.trace analysis
results of the storm e!ent. 0ither way, by using absolute time or hotkey filtering, the broadcast
storm should be located within the data.trace capture.
4ther metrics can be turned on in a protocol analysis display !iew when e$amining a broadcast
storm, such as relati!e time and packet si"e. +fter the start of the storm has been located, the key
de!ices starting and in!oking the storm should be logged. ometimes only one or two de!ices
cause a cyclical broadcast storm occurrence throughout an internetwork, resulting in a broadcast
storm e!ent across many different network areas. /he de!ices communicating at the time closest
to the start of the storm inside the data.trace analysis results may be the de!ices causing the
e!ent.
+fter the storm has been located, the Relati!e /ime field should be "eroed out and the storm
should be closely re!iewed by e$amining all packets or frames in!ol!ed in the storm. 2f 599 or
),999 frames are in!ol!ed, all frames should be closely e$amined by paging through the trace.
+fter the end of the storm has been located, the time between the start of the storm and the end
of the storm should be measured by using a relati!e time process. /his is achie!ed by 8ust
"eroing out the relati!e time at the beginning of the storm occurrence and e$amining the
cumulati!e relati!e time at the end of the sequence. /his pro!ides a clear picture of the storm
de!ice participation and processes, the packet.si"e generation during the storm, and the source of
the storm location. /he initial se!eral packets located for the broadcast storm should be
in!estigated for the physical, network, and transport layer addressing schemes that may relate to
the storm occurrence. /his helps an analyst to understand the sequence of the storm e!ent.
/his is an e$tremely important process in network baselining and should be engaged in proacti!e
and reacti!e analysis. 2n proacti!e baselining, an analyst must configure the proper broadcast
storm thresholds on the protocol analy"er. /his way, the storm e!ents will show during the
network baseline session. 2n a troubleshooting (reacti!e* e!ent, it is important to know whether
certain failure occurrences or site network failures are also being reported by the users& these
may relate to the time of the storm occurrence. 2f this is the case, 8ust isolating and identifying
the broadcast storm may make it possible to isolate the de!ices causing the storm or the protocol
operations in!ol!ed. 2t may then be possible to stop the storm occurrence. /his will increase
performance le!els and optimi"e the network.
Top of page
et!or" #apacity O$erload Analysis
When e$amining utili"ation, it is important to understand both the a!ailable capacity on any
network medium and actual achie!ed utili"ation le!els from an a!erage, peak, and historical
perspecti!e. 0!ery network 5+N or W+N topology has an a!ailable capacity. 1etermining the
utili"ation le!els of a topology is important, but equally important is identifying any problematic
utili"ation le!els or saturation utili"ation le!els. +s discussed earlier, saturation of any main
network medium can cause outages on a network related to an end.to.end session. Peak
utili"ation and time measurement methods must be used to identify any outages.
4ther conditions e$ist when the capacity, e!en if a!ailable, may be in an o!erload condition in
certain topologies.
Consider, for e$ample, a )96bps shared media 0thernet topology operating at :9BC utili"ation
le!els. /he 0thernet topology in a shared configuration normally allows for a specific ma$imum
capacity of )96bps or )996bps. Can the shared 0thernet medium sustain the applied utili"ation
le!els and continue to operate in a positi!e mannerD +lthough capacity le!els may only be
operating at a peak transition of :9C or E9C, and appro$imately @9C to F9C of medium may
appear a!ailable, the C6+<C1 mechanism of shared 0thernet could trigger an e$cessi!e
collision problem at this le!el. +s noted later in this book, in shared 0thernet media the collision.
detection mechanism can increase to a le!el that causes problematic e!ents at the physical le!el
when utili"ation e$ceeds @9C of a!ailable capacity. 2n this e$ample, a le!el as high as :9C of
the a!ailable capacity can constitute a network o!erload condition.
With most network analy"ers and management systems, an analyst can set a threshold that will
immediately identify whether a specific 5+N or W+N is in o!erload. /he thresholds of certain
internetwork management systems are specific to switches, hubs, and routers, and usually
facilitate this process.
%or the purposes of this discussion, a protocol analysis approach is followed. When performing a
network baseline, the protocol analy"er should be preset for a network o!erload threshold setting
(if an a!ailable option*. /his feature is usually found in an artificial intelligent 0$pert system
threshold setting mode. +n analyst should determine whether a network o!erload threshold setup
feature is a!ailable prior to a baseline session. /he ne$t focus is the e$act type of topology and
protocol sequencing being e$amined. + ):6bps /oken Ring network requires a different
o!erload threshold setting than a )96bps 0thernet en!ironment requires.
+nother consideration factor is the type of application traffic and N4 en!ironments that are
deploying !arious protocols across the architecture. /he combined topologies and protocols
create a specific architecture that must be considered when assessing an o!erload condition
during the network baseline process. 2n a network continually sustaining a 59C utili"ation le!el,
for e$ample, setting an alarm below this le!el will trigger abnormal error occurrences or will
cause already well.known information to be continuously logged. Presetting the threshold setting
is somewhat of an intuiti!e process on the part of the analyst. /he message here is that the
analyst must understand the type of topology and protocol en!ironment deployed and determine
what type of a condition will cause a utili"ation o!erload of the a!ailable capacity. %igure 5.F
illustrates the concept of analy"ing a network o!erload e!ent.
Figure 5.$: Analyzing a network o%erload e%ent.
+ dedicated.circuit W+N with a fractional /) link engaging a =5:G circuit pro!ides another
e$ample. Hou should not continue to run data across the circuit at I9C to ;9C capacity. /his
type of le!el could cause e$cessi!e retransmissions and o!erflow of some of the buffers in the
end.to.end router platforms between two specific wide area sites. 2f more than I9C to ;9C
utili"ation is being achie!ed, e!en though there is still )9C a!ailable capacity, it would be better
to upgrade the circuit to increase performance le!els. /he other factors in!ol!ed in making this
decision would be the type of router technology, the type of protocols, and the consistency of this
traffic le!el. /here are many factors related to this occurrence.
+ protocol analy"er e$ample illustrates this technique. + protocol analy"er can be deployed
across a certain network topology. When the network baseline session is initially configured, a
threshold can be set for the proper o!erload condition. /his is the alarm that occurs when the
o!erload e!ent happens. 2f the network baseline process is acti!e, and the analyst encounters a
network o!erload alarm, the protocol analy"er should then be stopped and the capture should be
sa!ed. /he analyst should note the network o!erload e!ent as to the time of occurrence and the
type of de!ices in!ol!ed. /he data.trace capture should then be re!iewed by isolating high.
utili"ation occurrences within the trace. ome, but not all, network analy"ers enable an analyst to
turn on network utili"ation as a metric within the data.trace !iew results. /he key is to properly
mark the absolute time of the occurrence from the analy"er 0$pert system or the management
system. /he +bsolute /ime field should be turned on within the data.trace capture results.
Whether the network o!erload is located through a hotkey filtering system or absolute time, the
o!erload occurrence should be closely e$amined. 6ost likely, a set of de!ices is in!ol!ed in
communication when the network o!erload occurrence takes place.
/he network utili"ation column in the data trace should be e$amined and noted. /he internal
trace results should also be closely e$amined for the type of packet si"e used during the data
mo!ement when the utili"ation o!erload condition occurred. +s noted earlier, utili"ation is a
component of data si"e and rate of data mo!ement. 2f an o!erload condition of ;9C occurs when
packet si"es are increased abo!e =G from an area of )99 bytes, this clearly indicates that larger
blocks of data are present at a consistent data rate (increasing utili"ation on the medium*. /he
actual protocol e!ent sequences can then be e$amined for the cause of the o!erload. -ased on the
start time of the o!erload occurrence identified within the data trace, it may be possible to note
the data.trace e!ents in the first se!eral packets identified at the time of the occurrence. e!eral
features can be acti!ated in the protocol analysis detail re!iew to e$amine information such as
3e$ or +C22 data !iew of packet internals to identify the opening of a certain type of file. /he
application layer protocol could also be e$amined for a specific file sequence that has been
opened. -y identifying the types of files opened and the protocol e!ents occurring at the time of
the network start sequence, an analyst can relate the utili"ation o!erload to a specific application
operation or occurrence on the networkJa ser!er synchroni"ation e!ent, a unique application
launch, or a communication cycle such as database transfer, for e$ample.
%igure 5.5 shows how changing the si"e of data mo!ement affects network utili"ation.
Figure 5.5: &hanging the size o! data mo%ement.
2t is critical to perform network capacity o!erload analysis during network baselining. +n analyst
can use this technique in both a reacti!e analysis for emergency troubleshooting, as well as in a
proacti!e way to e$amine capacity o!erloads.
Top of page
et!or" Thro%ghp%t Analysis
When performing a network baseline, effecti!e throughput should always be considered a
standard measurement. /he most accurate way to perform effective file throughput (0%/*
analysis is to measure 0%/ against e$act file transfer. Keneral throughput measurements can also
be taken against a specific network 5+N or W+N area.
+ specific technique applies to performing throughput analysis consistent with protocol analysis
methodology in a network baselining session. /his technique in!ol!es cross.mapping throughput
measurements obtained from a protocol analy"er statistical or 0$pert screen with the throughput
within the actual data.trace results.
When performing throughput analysis, it is !ery important to mark the beginning of a file open
and a file close sequence. /his is because after a file transfer begins, the transfer of data units in
packets between two specific de!ices is usually a consecuti!e process and data mo!ement can be
consecuti!e and rapid.
6arking the file open and close sequences helps the analyst to determine the throughput across
the internetwork channel in a 5+N or W+N area. /he following discussion focuses on
measuring 0%/ with a protocol analy"er.
Prior to the study, the protocol analy"er deployed on the network should be set up for a network
baseline study, and any 0$pert system threshold in an artificial intelligenceAbased protocol
analysis or statistical screen threshold should be set. e!eral effecti!e throughput le!els are
standard. 1uring the network baseline study, the analyst should be familiar with the internetwork
architecture and aware of the throughput typically achie!ed in the particular internetwork
architecture. +fter the standard throughput le!els for the specific network ha!e been determined,
they should be entered into the 0$pert system.
2f the required achie!ed le!el of effecti!e throughput for a network baseline study is 599Gbps,
for e$ample, this threshold le!el should be set in the protocol analy"er prior to a capture session.
+fter the 599Gbps threshold has been set, the protocol analy"er alarm triggers or a statistical
screen is identified while a capture is acti!e when a file transfer drops below the 599Gbps mark.
/he analyst should mark the time of the effecti!e throughput drop and note any de!ices in!ol!ed
in transfer during the low effecti!e throughput drop. 2t is ne$t important to identify the timing
e!ent of the actual low effecti!e throughput alarm occurrence. 6ost analy"ers include an
absolute time mark in the statistical output screen or the 0$pert analysis screen. With these items
being noted, a low 0%/ e!ent could then be cross.mapped to the internal area of the trace by
using the effecti!e throughput measurements discussed earlier in this book.
+fter the trace analysis data has been sa!ed and the detail trace opened, it is then possible to
!iew the data and locate the low 0%/ occurrence within the data by cross.mapping the statistical
absolute time or hotkey filtering to a low effecti!e throughput e!ent.
When a low effecti!e throughput occurrence is found within the trace, it should be !erified by
setting relati!e and cumulati!e bytes and adding the relati!e.time metric against data mo!ement
that is cumulati!e to determine the effecti!e throughput achie!ed for the dataflow operation.
%igure 5.: displays the technique of measuring 0%/.
Figure 5.': (easuring )FT.
2t is also possible to trace throughput on a consistent basis by setting se!eral protocol analy"ers
or management systems at specific threshold le!els. /his is another unique technique, because it
enables the analyst to consistently capture the throughput le!els of !arious de!ices
communicating across an internetwork. 6ost protocol analy"ers can de!elop multiple sets of
!iews against certain de!ices communicating with application. or connection.based protocols
within a 5+N or W+N topology. When specific de!ices are being tracked in a statistical or
0$pert screen of a network analy"er, it is possible to monitor the ongoing effecti!e throughput by
e$amining statistical screens.
6easuring effecti!e throughput is not only !aluable for low effecti!e throughput occurrences,
but also for ongoing tracking of file transfers. /he technique for this process is to set up the
thresholds correctly and to consistently !iew the specific de!ices being re!iewed for throughput
during the baseline.
+n e$ample is to monitor the client stations related to the most critical ser!ers at the site.
pecific applications could be launched and the throughput could be compared for different
applications. /his enables an analyst to determine the data mo!ement and the data.rate for
standard throughput& it also enables an analyst to compare application P1# inputs within
different application profiles. /his identifies throughput differences in certain areas of the
internetwork and also the throughput differences related to certain application sequencing.
/his is a critical technique that should be followed in proacti!e baseline studies. /his process can
also be used in reacti!e analysis for low throughput or performance problems.
Top of page
et!or" End-to End &nterpac"et Timing Analysis
Network communication in!ol!es at least two de!ices communicating with each other, a
workstation and a ser!er& or a ser!er communicating with another ser!er (at a minimum*.
pecifically, any two de!ices communicating across an internetwork identifies an end.to.end
communication channel. + data communication sequence occurs across a network channel and
data is processed and a data transfer is achie!ed.
2t is possible to use protocol analy"ers and network management systems to e$amine the network
end.to.end timing between two specific de!ices. +s discussed under the timing section in the last
chapter of this book, se!eral different timing metrics or statistics can be acti!ated in a protocol
analy"er when measuring this process. ome of these metrics or statistics include absolute, delta,
and relati!e time.
+ specific technique applies, howe!er, when e$amining how workstations and ser!ers are
communicating as to timing in a network baseline session. /his is accomplished by determining
the time difference between Request and Response sequences.
+ workstation and ser!er across any topology usually in!oke a specific protocol sequence to
transfer information, and may engage another protocol sequence to call on a specific ser!er file
and so forth. 5ater in this book, there are e$tensi!e discussions on specific protocol sequencing
methods for different protocol types and suites such as No!ell and /CP<2P. %or the purposes of
this discussion, it is important to understand that there is an e$act technique for measuring end.
to.end interpacket timing that enables an analyst to quickly determine how !arious workstations
and ser!ers are responding to each other in terms of performance across the internetwork. /he
process of using a protocol analy"er is used for illustration.
When using a protocol analy"er for end.to.end interpacket timing analysis, it is first important to
set the proper thresholds that will trigger alarms when an e$cessi!e response time occurs
between a workstation and ser!er. 6any network analy"ers and management systems ha!e
threshold settings that set off an alarm when a ser!er or workstation responds o!er a certain time
period. Normal internetwork end.to.end channel communications on a 5+N with multiple
segments should take no more than )9 to )5 milliseconds (ms*, and in fact it is common to see
response time well under 5ms on most internetwork infrastructures. +cross W+N infrastructures,
interpacket latency for end.to.end sessions can be as high as 59ms. + response time of less than
=9ms is more typical, howe!er. ome W+N designs are based on different deployment design
criteria, such as whether ser!ers are centrali"ed or decentrali"ed across an infrastructure. /he
ser!er positioning design must be considered when deploying se!eral protocol analy"ers against
the end.to.end channel.
+n e$ample of this process includes a multiple protocol analy"er data.capturing session against
an 0thernet end.to.end channel that in!ol!es three segments including a W+N. %or e$ample, a
multiple analy"er positioning 7map7 relati!e to the complete internetwork layout can be drawn
up. egment ), for e$ample, in!ol!es a shared 0thernet segment, which connects to a router and
then connects to a W+N %rame Relay circuit. /hat circuit interconnects another W+N site noted
as the remote location with an additional router, which is connected to another shared 0thernet
segment, egment =. /his mapping in!ol!es the following three specific network areas that must
be tra!ersed,
egment )
/he W+N %rame Relay cloud, and
egment =
With this e$ample in mind, at least four protocol analy"ers are required to e$amine an end.to.end
channel communication session. 4ne protocol analy"er could be placed on the egment )
location in the shared 0thernet area. +n second protocol analy"er could be positioned at the
e$terior side of the W+N router connected to egment ) and connected to the %rame Relay cloud
or the Frame Relay Assembler issembler (%R+1* link. + third protocol analy"er could be
positioned at the remote site on the e$terior side of the W+N analy"er connected to the %R+1
link at the egment = site, and a fourth protocol analy"er could be connected to the remote
0thernet shared egment =. /his setup places four network protocol analy"ers in a parallel mode
for synchroni"ed analysis.
%igure 5.E shows how end.to.end channel analysis can be used in a network baseline study.
Figure 5.*: )ngaging in end+to+end analysis.
/he ne$t step is to synchroni"e all the protocol analy"ers in terms of date and time to ensure that
all the relati!e base measurements for time in each analy"er platform are as close as possible.
ome network protocol analy"ers offer synchroni"ation of time through K6/ synchroni"ation,
depending on the manufacturer. 4ther inband and outbound triggering mechanisms in different
analysis tools also enable an analyst to configure synchroni"ation.
+fter the analy"ers ha!e been engaged, application characteri"ation techniques can then be
deployed against a network end.to.end channel being timed. +n application can be launched
from a local workstation at one segment to access a ser!er at a remote site. /his would be !alid if
a distributed ser!er is placed at the remote site. /he application, when launched, can be
monitored by all four protocol analy"ers. With absolute time set as acti!e, it is possible to trace a
specific packet, such as a /CP or a No!ell PL packet, by monitoring the sequence number as it
tra!els from the source workstation to the remote ser!er.
2t is also possible to track the /CP or PL response by e$amining the sequence and
acknowledgment number as well as the identification fields of the networks tra!ersed in the
network and transport layer protocols of each packet.
-y tracking the packets sent and recei!ed, the end.to.end network channel interpacket timing
measurements can be determined. +n analyst can make delta time acti!e on the ection )
analy"er to e$amine the request outbound process from the original workstation and to e$amine
the inbound ser!er response. 0!en by 8ust using the first analy"er, howe!er, the actual time spent
across ection ), across the W+N %rame Relay cloud, across ection =, and across the remote
segment is all compiled into the remote response. -y using se!eral analy"ers, an analyst can
determine how much time is spent on egment ), how much is related to the internal turn time of
the workstation or delta time on egment ), how much time is spent across router one at the local
station, how much time is spent tra!ersing the %rame Relay cloud, how much time is spent
tra!ersing remote router two at the remote site, and how much time is spent accessing the ser!er
on the remote 0thernet segment at the remote site. +n analyst can actually determine the amount
of time spent in the ser!er, the ser!er turn time, as well as the ser!er delta time at the remote site.
/iming analysis is an e$tremely !aluable technique, but it must be !ery carefully configured and
engaged. -y applying this technique, an analyst can e$amine the appropriate analy"er screens
and cross.map high response time or long acknowledgment time errors, as well as other
conditions such as slow responding ser!ers. /he analyst can check these occurrences against
actual timing e!ents in the internal data.trace analysis results. /his technique enables the analyst
to accurately isolate the cause and results in e$tremely on.target information.
/his process can be coupled with multiple application.characteri"ation techniques, such as
launching certain e!ents. 2t is then possible to determine delays that may be related to the
application processing or delay e!ent sequences that take place when packets are tra!ersing
routers or switches on large internetworks.
Marious tools enable an analyst to process data scripts across an internetwork based on this
sequence.
ome of the most !aluable tools a!ailable for this type of process include the Chariot platform
offered by Kanymede oftware and 4ptimal oftware's +pplication 0$pert. /he Chariot tool
allows for immediate generation of data scripts across the internetwork& this will quickly show
defined data mo!ement, and allows for !iewing transaction time, throughput, and response time
operation. Chariot tools can be placed at multiple network points.
Network analy"ers can also be placed at the same points to e$tract data. 4ptimal's +pplication
0$pert pro!ides response.time prediction and data analysis in a multipositioning process, but
adds a feature to e$amine an application's thread across an internetwork.
6any different management systems offer unique platforms and features that can engage tests
similar to Kanymede's Chariot and 4ptimal's +pplication 0$pert.
/he key factor to remember is that timing measurement is a !alid process and should be
configured and performed !ery carefully. -y so doing, an analyst can isolate delays and perform
specific optimi"ation tuning against internetwork transfer.
/his is a !alid technique and should be used consistently by an analyst in both proacti!e and
reacti!e analysis situations.
Top of page
Transport and 'ile Retransmission Analysis
When conducting either a proacti!e or reacti!e network baseline study, it is important to monitor
the transport layer and application layer for retransmission e!ents. + retransmission occurrence
can cause an inefficient situation in terms of final data communication. + retransmission is a
redundant dataflow e!ent that adds to the amount of cumulati!e bytes transferred on a network to
effect a final transmission of an intended application process or N4 data.
/he specific purpose of the transport layer mechanism operation is to ensure connection. 6ost
transport layer protocols engage a connection process that in!okes a sequence.and.
acknowledgment cycle between two specific end nodes. /his sequence.and.acknowledgment
maintenance cycle causes, in certain cases, a higher transmission of redundant data. /his is
common if there are delays or other abnormal occurrences in the communication channel
between two end de!ices. 5ater in this book, an e$tensi!e discussion is presented on !arious
types of transport layer protocol operations and processes.
%or the purposes of this discussion, the main function of the transport layer in network
communication protocol sequencing is to ensure that there is a transport mechanism in place for
transferring data from specific protocol port areas within certain workstations and hosts across an
internetwork. 2n certain cases, the transport layer also generates packet traffic that allows the
transport channel created to be maintained for connection.
Protocol analysis enables an analyst to monitor the transport channel that has been established
between a workstation and a file ser!er for general operation and transfer of data across the
channel. /he analyst can also monitor the transport layer for recurrences of transmission of data
considered redundant. 2n this case, the focus would be monitoring transport layer
retransmissions.
-ecause the transport layer is essentially in place to establish a network channel for data port
communication and, at times, to maintain the communication channel in a consistent and reliable
state, it is critical to monitor this area through a network baseline process to ensure connecti!ity.
2f a transport layer connection is established with /CP, two specific ports for /CP may be
opened on a respecti!e end.to.end channel on an internetwork. /he endpoints could be a
workstation and a file ser!er, each of which would ha!e a /CP port open. /he transport layer
protocol /CP would maintain the connection. Polling e!ents between the two protocol ports in
the two de!ices would take place that would allow for maintaining the /CP port transport layer
channel that is open related to the port transmission acti!ity.
With the aid of a protocol analy"er, an analyst can monitor this channel. 2f a delay is present in
the internetwork, or if one of the two de!ices encounters a problem, the end.to.end
communication may be negati!ely affected. +gain, this might result from internetwork delays or
because one of the de!ices has an internal issue related to resource handling or processing of
data. When this occurs in the /CP en!ironment, the transport layer may show e$tensi!e
retransmissions of data because it is attempting to ensure that the data required for achie!ement
of an application process is sent on a continuous basis. When retransmissions occur, redundant
data is sent. 4ne of the endpointsJfor e$ample, the workstationJcould encounter a situation in
which it is not recei!ing required data responses from the ser!er because of delays. +s this
occurs, it is likely that the workstation will re.request the data on a continual basis. #nder certain
conditions, the host may retransmit the data for integrity purposes, based on the inherent
operation of the transport layer protocol /CP.
%igure 5.I shows retransmission analysis being engaged.
Figure 5.,: )ngaging in retransmission analysis.
+fter a protocol analy"er has captured the retransmissions, an analyst can mark the percentage of
data related to retransmissions as related to standard data process transmissions to understand the
retransmission le!el. +n e$tremely high retransmission le!el, such as =9C or @9C of all frames
transmitted, shows an e$cessi!e le!el of redundant communication.
/his e$ample clearly shows how transport layer transmissions can become an issue. /he simplest
way to t monitor transport layer retransmissions is to use a protocol analy"er.
Application-Based 'ile Retransmission
+pplication.based file retransmission is another type of retransmission e!ent that can take place
in application operations when communication occurs between workstations and ser!ers. 2n most
cases, a complete file retransmission is usually in!oked by application operational sequencing, or
de!elopers may intentionally code it into the application process for redundant cycles to enable
integrity checks in the application transfer.
When a file is sent across a network, a file open and a file close sequence is usually in!oked. +
protocol analy"er enables an analyst to monitor how often files are opened and closed. 2f some
files are opened and closed on a consistent basis in consecuti!e order, the application code or the
application process may !ery well be in!oking the file retransmissions. When this type of
situation occurs, it is critical to monitor the e!ent with a protocol analy"er. 1oing so enables the
analyst to identify the inefficiently designed applications causing redundant e$cessi!e
communication on a network.
/o monitor transport retransmissions, the network protocol analy"er should first be set for the
appropriate thresholds to capture this error. ome network protocol analy"ers enable the analyst
to set up a predetermined threshold or filter for this type of e!ent. +fter the network baseline
session has been started, if any of the transport layer retransmissions alarms are triggered, the
error occurrence and time can then be documented. + hotkey filtering system can then be
in!oked after the file has been captured and sa!ed. /he hotkey filtering system can be engaged
or the time of the transport layer retransmission can be marked from the appropriate analy"er
screen. +fter the time e!ent of the retransmission e!ent has been identified and noted, the
internal areas of the data capture can then be e$amined for the actual retransmission e!ent.
2n some cases, it is possible to mark the transport layer sequence and acknowledgment fields for
the retransmission e!ent. ome protocol analy"ers highlight this alarm& with others, only a
detailed analysis can identify this concern. /he technique in!ol!ed is to cross.map any statistical
alarms on the analy"er from an 0$pert or statistical screen against the retransmission e!ent inside
the data trace.
+fter the retransmissions ha!e been found, they should be correlated to any file open and close
sequence prior to the retransmission. /his process enables the analyst to identify the file being
transferred and to possibly identify the application being in!ol!ed. 2f the retransmissions are
e$cessi!e, the amount of retransmissions in terms of the data transfer frame count for normal
retransmitted frames should be compared and documented. + percentage of retransmissions
should be calculated against o!erall standard data transmission e!ents. 2f retransmissions e$ceed
)9C of o!erall traffic, this is a problematic le!el that could cause redundant communication and
additional utili"ation on the medium. Retransmission le!els as high as =9C and @9C could cause
application integrity issues and<or application failures. /he le!el of retransmissions should be
carefully noted.
%igure 5.; presents the concept of file fluency analysis.
Figure 5.-: File !luency analysis.
When monitoring application.based file retransmissions, it is also important to set up a protocol
analy"er prior to starting a network baseline to capture any concerns related to this type of e!ent.
ome protocol analy"ers enable an analyst to set up a filter or an 0$pert system threshold to
trigger an alarm. 2f when performing a network baseline session, a file retransmission alarm is
triggered, or if a statistic is reported on a screen for an e!ent, the analy"er can then be stopped
and the data should be sa!ed for re!iew.
/he e!ent occurrence from the statistical or 0$pert screen should also be noted for the absolute
time of occurrence and the de!ices in!ol!ed in the file retransmission. 2t may also be possible in
some circumstances to mark the protocol type or application in!oked. #sually this is 8ust noted
as the protocol layer engaged and not the application type.
+fter the capture has been sa!ed, the data trace should then be opened and the e!ent should be
located by hotkey filtering or matching of the absolute time of occurrence. +fter the file
retransmissions ha!e been located, the type of files being opened should be e$amined and, if
possible, cross.mapped to an application engaged at the site. 2t is sometimes possible to turn on
3e$ or +C22 data display !iews with an analy"er to e$amine the internals of the file open
statement (if the application layer does not report the file type, for instance*. /his enables an
analyst to identify the application access that is occurring.
Ne$t, the file open and close process should be monitored for how often the file is opened and
closed in a consecuti!e manner. + file opened and closed once is a normal e!ent. 2f a file is
opened and closed =5 consecuti!e times with the same data being transferred, this is an e$cessi!e
file retransmission e!ent. /he application de!elopment team should be contacted to in!estigate
whether this is an intended application e!ent or whether this is an abnormal e!ent. 2n most cases,
this issue can be resol!ed by working in tandem with the application de!elopment and N4
ser!er support teams.
%igure 5.)9 shows file access.error analysis.
Figure 5.1.: File access+error analysis.
-oth steps of e$amining transport and file retransmissions !ia network baselining are e$tremely
important. /hese techniques assist in identifying redundant communication that can be
eliminated from a communication session. /hese steps also assist in identifying network.based
foundational or application process issues.
Top of page
Path and Ro%te Analysis
1uring a network baseline, it is important to always in!estigate the route of packet transfer
across a network or internetwork channel. 2t is also important to determine the number of hops or
paths taken across internetwork inter!al points when transferring information.
/he use of protocol analysis in this area is an e$tremely !aluable process. Path route and path
count analysis can be used in proacti!e and reacti!e network baselining sessions. /o e$amine
path route concerns, it is important to understand that within network layer protocols, and also
internal to some of the data in!ol!ed abo!e the physical layer inside a packet, there is
information that may identify the route that a packet has taken through an internetwork.
When e$amining a simple /oken Ring frame, for e$ample, it is !ery common to e$amine a
Routing 2nformation field. /he Routing 2nformation field includes specific information as to the
bridge, router, or switch that been tra!ersed, and how many hops ha!e been taken related to the
/oken Ring packet. +n analyst can use a protocol analy"er to capture this information.
%igure 5.)) illustrates route and path analysis in a /oken Ring network.
Figure 5.11: /oute and path analysis.
e!eral network layer protocols can also be e$aminedJsuch as 2P, 2PL, and e!en atagram
elivery Protocol (11P* in the +pple/alk en!ironmentJfor a 3op Count field. + 3op Count
field can be e$amined and re!iewed for a quick !iew of how many routes ha!e been tra!ersed. 2t
is important to associate the hop count with the point of capture and where the packet is tra!eling
through the internetwork.
Certain network layer protocols, such as 2P, pro!ide e!en more information. /he 2P protocol
pro!ides a 3op Count and combined /ime in /ransit field, associating how long a packet has
spent on a network in the term of actual seconds or time metrics. /his a combined field and
shows time.to.li!e (//5*. /his field is discussed in detail later in Chapter E, 75+N and W+N
Protocols.7
/he technique of e$amining packet, route, packet count, and path count is e$tremely important
and can become intuiti!e for analyst.
6ost protocol analy"ers enable an analyst to immediately e$amine the internals of a packet or
frame in a detailed manner. ome protocol analy"ers ha!e alarms settings for e$cessi!e hop
counts or path routes tra!ersed. /he protocol analy"er should be set up for any alarms or
thresholds required.
+fter the capture has occurred, if any e!ents take place in a network baseline session, the
information related to a path count e$ceeded or a hop count e$ceeded field should be noted. /he
absolute time, the occurrence of the e!ent, and the de!ices in!ol!ed should also be noted. /he
capture should then be stopped and sa!ed. When the data trace is opened, the e!ent should be
located through absolute time cross.mapping or hotkey filtering. When the frames showing the
e!ent are located, the frames should be opened in a detailed mode. /he information related to
path route or hop count should be e$amined. 2n most cases, this e$amination focuses on the
network protocol in!ol!ed. 6ost network layer protocols usually 8ust display the source network,
source node, and sometimes the socket or protocol port being communicated to across the
internetwork. -y e$amining the source network relati!e to the destination network, the hop count
can be determined for the data communicated across a set of routes.
2n a flat internetwork, such as a switched 0thernet en!ironment, a hop count marking in a 3op
Count field within a network layer protocol may not be !alid or e$ist. -y e$amining the source
and destination network, howe!er, an analyst can determine whether a de!ice is located across an
0thernet end.to.end channel that in!ol!es two, three, or four switches. +gain, it is e$tremely
important to understand that, in most instances, the network layer protocol holds this
information.
%igure 5.)= illustrates route analysis of an 0thernet network.
Figure 5.1: /oute analysis o! an )thernet network.
/he source and destination networks in!ol!ed should then be marked, and then the de!ices
should be mapped against the physical topology of the network. -y 8ust locating the source and
destination network, the de!ices can be re!iewed against a physical architecture or topology
map. -y locating where the de!ices are positioned on the network and associating this with the
route taken, it is sometimes possible to identify inefficient design or incorrect implementation of
ser!ers and workstations across an internetwork. Remedies can then be taken, such as relocating
a ser!er or reconfiguring switches or routers in such a way that fewer routes are tra!ersed.
+t times, e$cessi!e multiple.route occurrences can be identified. 2n some cases, routing loops or
delays can be identified in this sequence. ometimes a passthrough route through a ser!er that
pro!ides for 2P forwarding or has multiple N2Cs can be located through this technique.
/his is e$tremely important and allows for route protocol analysis to be used to e$amine the
route that a packet actually takes and the number of hops that the packet encounters when
tra!ersing the internetwork from the source to the destination.
/he ability to map this to an actual sequence flow or roadmap taken through the internetwork is
an in!aluable process to a network baseline study, in both a proacti!e and reacti!e mode.
Top of page
End-to-End 'ile Transfer Analysis
+nother important technique in network baselining is end.to.end file transfer analysis. %ile
access is the main operation of an internetwork. +s mentioned earlier, a protocol analy"er can be
used consistently to mark a file open and a file close sequence. +n analyst can re!iew when files
are opened and closed, and can identify the source and destination de!ices related to the transfer.
+s discussed earlier, the analyst can e$amine the internal time sequences between a file transfer
and mark the timing related to the file transfer e!ent as well as the amount of data mo!ed.
/aking into account the techniques presented in the application discussion of this book, it is ne$t
important to note that a simple technique should be followed during e!ery network baseline
study to e$amine end.to.end file transfer. When performing a network baseline, e!en with the
absence of errors, it is important to constantly monitor file transfer e!ents when e$amining the
internal le!els of protocol analysisAbased traces captured during a session.
+ simple way to do this is to ensure that any protocol analy"er or network management tool used
is set up for the appropriate thresholds that will enable identification of any abnormal
occurrences of this type. ome protocol analy"ers enable an analyst to set up a threshold that will
alarm when a certain file is opened and not closed in a relati!e amount of time.
%igure 5.)@ illustrates a file transfer delay e!ent being analy"ed.
Figure 5.1": Analysis o! a !ile trans!er delay.
+n analyst can also identify this process by setting specific alarms, such as alarms to a
nonresponsi!e host en!ironment or a slow responding ser!er. 2n certain conditions, this may
enable the analyst to immediately identify any abnormal end.to.end file transfers within a data
capture.
+ normal process is for a file to be opened, accessed, and closed. 2n some cases, a file is opened,
accessed, and then abruptly stopped. ometimes the e!ent can be caused by delays on the
network or failure of the N4 or failure of the application itself.
4ften a de!ice failure in the workstation or file ser!er causes this e!ent. 2t is important to
e$amine this e!ent on a consistent basis as a thread throughout many network baselining sessions
in an enterprise internetwork study.
+ protocol analy"er can set up in a predetermined configuration prior to a network baseline
session to allow for a threshold alarm to acti!ate upon incorrect file closures or any
nonresponsi!e conditions on workstations and ser!ers.
+fter the protocol analysis network baselining session has been started, it is then possible to
identify any alarms that may be triggered. 2f any alarms occur related to file transfer sequencing,
the de!ices in!ol!ed and the absolute time of the occurrence should be noted. +fter the capture
has occurred, the data trace should be sa!ed. /he data captured should be opened and the
abnormal file transfer located through a hotkey or absolute time cross.mapping sequence.
2n the e!ent that alarms are not triggered, a page through the trace e$ercise enables the analyst to
e$amine file open and close sequencing. 2f the error is located, the file open and close process
can be e$amined. 4nce marked, the open and close process should be considered the start and
stop point for a file transfer. /he packets should ne$t be e$amined from the open state to the
close state for redundancy or abnormal retransmission e!ents. 2n some instances, the trace data
will show an abnormal stop and file close as e!en be present in the trace.
/he key factor here is that normal consecuti!e file open and close sequencing is essential to a
positi!e network communication process. 2t is also the main reason that we ha!e file open
occurrence, an access e!ent such as a data transfer, and a file close. 6ost of the time, the
application layer protocol is monitored for this type of cycle. +pplication layer protocols include
such types as NCP and Windows N/'s 6-. %urther information on application layer protocols
appears later in this book.
2n closing, it is important to e$amine end.to.end file transfer in e!ery network baseline study
session.
Top of page
Trace (ecoding Techni)%es
When performing a network baseline, the final technique is the actual method used by the analyst
to identify specific e!ents and perform trace decoding. 0arlier in this book, a brief discussion
was presented on a process termed 7paging through the trace.7
When mo!ing through a data capture, the data must be e$amined on a consecuti!e basis and
re!iewed closely by carefully mo!ing through the trace information. 5arge data captures can
include multiple frame sequences that can in!ol!e thousands of frames. ome network baseline
capture sessions in!ol!e anywhere from @9,999 up to )99,999 or more frames. -ecause of this, it
is important to ha!e a technique that allows for quick e$amination of the frame sequencing. 4ne
technique is to use an 0$pert or statistical screen for cross.mapping e!ent errors and quick
hotkey filtering to the area in the trace that shows the problem. +t times, an 0$pert or statistical
screen may actually show the frame number prior to stopping the capture when an error e!ent
occurs.
When performing a network baseline, careful notes should be taken from the 0$pert system or
the statistical screen prior to stopping the capture. 2f critical information is noted, such as
absolute time of occurrence, de!ices in!ol!ed, or frame numbers related to error occurrence, an
analyst can mo!e through the trace more quickly after the capture has been sa!ed for re!iew.
0!en if an 0$pert system is not a!ailable, there are ways to page through the trace to obtain
important information that is essential for a network baseline session. /his is an e$tremely
!aluable step in network baselining.
%igure 5.)F illustrates the concept of trace note taking during a network baseline study.
Figure 5.1$: Trace note.
/he following is an e$ample of using a protocol analy"er to page through the trace. %irst, the
analy"er must be preconfigured for the proper metric thresholds to ensure that e!ent alarms will
trigger and show absolute time and areas of occurrence for frame category marking prior to the
error e!ent. Watching the protocol analy"er closely while the capture is occurring will also allow
for marking this type of e!ent.
+fter the capture has been started, the analyst should closely monitor the protocol analy"er. /his
is e$tremely important when performing reacti!e troubleshooting analysis for rapid cause
isolation. 2f an error alarm for a retransmission is triggered on the analy"er statistical screen
when frames are being recei!ed into the analy"er N2C and the analy"er is showing an inbound
frame count of 5,@=5 frames captured, the frame number 5,@=5 can be quickly noted as a
possible frame area in the data trace as associated with the retransmission error.
/he error and the de!ices in!ol!ed with the error should be recorded on a statistical notebook,
along with the frame area within the trace that is inbound. /hus, when the data capture is sa!ed
and the e!ent e$amined, the analyst can swiftly mo!e to frame 5,@=5 for cause isolation.
%igure 5.)5 illustrates the concept of frame marking during a protocol analysis session.
Figure 5.15: Frame marking.
/his is 8ust one e$ample of this type of cross.mapping of an ongoing rapid dynamic process
throughout a network baseline session. +gain, the analyst must be e$tremely in!ol!ed with the
protocol analy"er while the capture is occurring for this technique to be helpful.
+fter the protocol analy"er has been stopped, whether an 0$pert is acti!e or inacti!e, the analyst
can mo!e through the data in a page through the trace process to in!estigate certain data. 2f any
e!ents are located during the li!e capture dynamic session, the cross.mapped technique of
re!iewing the data associated with certain frame numbers or with absolute time occurrence
should be followed. 3otkey filtering should also be used, when possible. /his will allow for
quick use of an 0$pert system or an artificial intelligence statistical screen to quickly key to the
type of error within the data capture.
+fter a problematic frame or packet has been found, certain types of information should be
clearly recorded in a statistical mode by the consultant or analyst performing the network
baseline.
+n analyst should note information related to the following,
+ddress(es*
%ile access and name(s*
/ime frame(s*
%rame structures for field length
Routing information
pecific protocol(s*
Address *ar"ing
When e$amining a trace, it is first important to note the !arious le!els of addressing. /he
physical address should be noted inside any packet that has an error. /he network layer address
should also be noted, along with any transport layer ports that are opened. /his will assist in
identifying any e!ents related to an error frame that could be associated with certain de!ices or
specific network applications.
+n analyst might, at times, capture the trace information and identify a specific area of the trace
that shows the problem. 1epending on the analyst's e$perience and understanding of the
internetwork, howe!er, the analyst may or may not be able to identify the de!ice or application
associated with an error. -y properly marking the information in a log and forwarding it on to an
appropriate 62 person, it is quite possible that specific ser!ers or applications can be pinpointed
as the cause of the problem.
'ile Access and ame *ar"ing
2t is also important that the analyst note any file open and close sequences associated with error
occurrence. +fter the file open and close sequences ha!e been marked, the file being called on in
the application layer protocol, the 3e$ code, or +C22 code that shows the file being opened
should be noted. /his information can then be forwarded to the appropriate 62 personnel who
may be able to identify the application associated with the error. +gain, the analyst may not
always understand which de!ices or applications are in!ol!ed. -y clearly noting the file
sequencing or the file that is opened and closed in an analysis log from a protocol analysis
standpoint, howe!er, other 62 team members may be able to identify the application or area of
the internetwork related to file ser!er location causing the problem.
Time 'rame *ar"ing
+s discussed throughout this chapter, it is important to record the time frame of an error e!ent.
/he absolute time frame of a packet is usually marked within the upper.layer physical header
inside the detail le!el of a packet area. 2t is also possible to turn on the absolute time within the
data.trace summary screen to re!iew the absolute time of any error frame occurrence. 0ach time
an error is noted in a baseline session, the network analyst should always record the time frame
occurrence in a statistical analysis log.
'rame Str%ct%res for 'ield +ength *ar"ing
4ccasionally, a network baseline analyst will encounter a frame structure error. %rame structures
are usually designed for a specifically defined operation. %or e$ample, a typical 0thernet frame is
based on a frame si"e ranging from :F bytes to )5)I bytes. + F6bps /oken Ring frame is
limited to F9;: bytes. +n analyst should always mark the frame si"e associated with any error
frame occurrence captured.
pecifically, if an error frame is detected when e$amining a data trace, the frame si"e and
protocol layer si"es should be noted, as well as the data payload. 0ach packet will always ha!e a
certain ma!imum transmission unit (6/#* si"e and specific amounts of data will be associated
with the protocol layers. 2t is important to mark the payload of data transferred in any frames
where errors occur. /his information should be recorded in the analyst's statistical log.
Ro%ting &nformation *ar"ing
+nother key area to monitor is the Routing 2nformation field. +s discussed earlier in this chapter,
frames contain specific information that indicates to an analyst the route taken or the path hop
count achie!ed. When performing a data.trace analysis session that in!ol!es cause analysis or
standard network baselining for error mapping, the analyst should clearly mark any critical
routing information, such as the route or path taken. 2f routing update sequences are captured
between routers or switches, or other key de!ices on the network such as ser!ers or hosts, the
analyst should also record any routing update sequences when performing error.mapping
analysis.
Specific Protocol *ar"ing
pecific protocol marking is also important. /his book does not discuss certain e!ent
occurrences. /hese are abnormal occurrences that do not fit any specific profiles, such as an
abnormal error from a certain application, or an abnormal type of protocol e!ent that has not
been seen before in a network baseline session. 2f any abnormal e!ent occurs, the analyst should
document as much information as possible about the e!ent. /his would include the absolute time
of occurrence, the de!ices in!ol!ed, and any protocol sequencing taken.
When performing a network baseline session, it is e$tremely important to be in a constant re!iew
mode, which in!ol!es statistical documentation of the occurrences. tatistical documentation
in!ol!es recording and documenting information prior to stopping the data capture. 2t is also
!ital that information be sa!ed to a trace file sa!e mode or a "ommon Separate #alue (CM* file
format when possible so that the information can be re!iewed later in the network baseline
process.
ome of this information will be e$tremely critical to the final data.acquisition decoding and
final reporting process of the network baseline study.
2t should ne!er be assumed that information is not required or is unimportant. +ll information
should be documented in a concise and detailed basis. When performing a large internetwork
baseline in!ol!ing se!eral baseline areas, such as a )9 to )5 segments in an 0thernet
en!ironment, for e$ample, some of the information found in -aseline ession ) may be rele!ant
in -aseline ession E. 2t is important that e!ery network baseline session be consistently
documented through statistical sa!e modes for trace file captures, along with general note.taking
and statistical marking during a trace analysis session.
Top of page
#oncl%sion
2t is e$tremely important that all the techniques discussed throughout this chapter be followed
during a network baseline session. /hese techniques are e$tremely !aluable when ro!ing from
session to session across large internetwork baseline studies. /hey are also !aluable when
performing a simple network baseline study. /hese techniques apply in both proacti!e and
reacti!e analysis sessions.
When performing a network baseline, it is !ital that a clear documented file on the network be
a!ailable for re!iewing topology maps, address assignments, and other key configuration
information. /he following chapter discusses the importance of network documentation during a
baseline session and of cross.mapping the documentation to the results found in a trace analysis
session.
A,o%t the A%thor
(aniel -. assar is the most renowned network analyst and baseline consultant in the global
marketplace. +s president and C04 of 5+N cope, 2nc., an international network baseline
consulting and training firm, he has engineered and performed more than @,999 ma8or industry
network baseline studies on large.scale, critical networks for %ortune )99 companies. 2n addition
to his 5+N cope responsibilities, 1an is president of 0agle 0ye +nalysis, 2nc., a Philadelphia.
based network consulting firm. +t 0agle 0ye, he e!aluates industry products, such as network
analy"ers and new networking de!ices such as switches and routers. 3e pro!ides remote
e!aluation and writing ser!ices direct to industry manufacturers, including documentation design
for industry white paper re!iews, training manual design, and o!erall product assessment. 3is
e$tensi!e e$perience has led 1an to write four pre!ious books, as well as more than )59 articles
and )9 training courses on network performance baselining. 3e has also done more than )99
presentations at ma8or tradeshows and has chaired fi!e ma8or industry tradeshow boards.
Copyright N =999 by 0agle 0ye +nalysis, 2ncorporated
We at 6icrosoft Corporation hope that the information in this work is !aluable to you. Hour use
of the information contained in this work, howe!er, is at your sole risk. +ll information in this
work is pro!ided 7as .is7, without any warranty, whether e$press or implied, of its accuracy,
completeness, fitness for a particular purpose, title or non.infringement, and none of the third.
party products or information mentioned in the work are authored, recommended, supported or
guaranteed by 6icrosoft Corporation. 6icrosoft Corporation shall not be liable for any damages
you may sustain by using this information, whether direct, indirect, special, incidental or
consequential, e!en if it has been ad!ised of the possibility of such damages. +ll prices for
products mentioned in this document are sub8ect to change without notice. 2nternational rights O
0nglish only.
&nternational rights / English only.
Top of page
Topc 3
http://www.networkdocumentaton.com/ndex.php?
opton=com_content&task=vew&d=12&Itemd=2
0ocumenting 1our
Network
User Ratng: / 27
Poor Best
Rate
Wrtten by Bren Posey
Thursday2 , 3eptem4er ..'
Undocumented networks are extremey common. Many tmes ths s reated more to the
dffcuty of keepng the documentaton up to date rather than to the dffcuty of the
documentaton process tsef. Many LAN Admnstrators had bg dreams at one tme of
keepng eaborate drawngs detang every ast aspect of the network. However, networks
tend to change too frequenty for such drawngs to stay current. In spte of the dffcuty,
havng a we documented network can hep you sove probems qucky when they arse
and s vta to the overa securty of your network. In ths artce, we dscuss some aternatve
documentaton methods that are more practca n the ever changng word of networks.
Labe Everythng
Perhaps the most mportant part of a good network documentaton pan s to abe everythng. You shoud
create the abeng scheme wth the dea that the structure of the network w be constanty changng as w
the peope who use the network.
Perhaps the most mportant thng to abe s your network cabes. If youve been networkng for very ong,
youve probaby seen way too many network cosets that contan a massve web of tanged cabe. Usuay a
of ths cabe ooks ake, and ts mpossbe to te whch cabe connects to what wthout some extensve
dagnostc work. Most of the network admnstrators that I know are way too busy to have tme to fsh
through a mon cabes hopng to stumbe upon the correct one every tme that theres a probem.
Because of ths fact, you shoud abe both ends of each cabe as to what the cabe does. Ths abe shoud be
wrtten n such a way that n fve years when youve moved on to another |ob or have totay forgotten a of
the stuff that you dd today that the abes w st make sense.
Athough t may seem way too obvous, ths means makng the cabe egbe. Wrappng the cabes n maskng
tape and wrtng on the tape s a bad dea. These sort of abes tend to fade or crumbe to dust over the
years. We recommend usng a commerca abe maker. |ust make sure that what ever knd of abes you use
have strong enough adhesve that they wont graduay fa off of the cabes. One way of preventng the
abes from fang off s to wrap them around the cabes.
We mentoned that the abes shoud st be usefu severa years down the road. Therefore, the network
abes shoudnt be based on budng ocatons or on peopes names. For exampe, creatng a abe marked
|ohns offce s a bad dea, because |ohn coud qut tomorrow. Lkewse, creatng a abe marked Fnance
Managers Offce s a bad dea. Ths s because fve years down the road, the Marketng Manager coud be
usng the offce, or the offce coud be a conference room nstead of an offce. You shoud aso pan on
network growth. For exampe, a cabe marked Managers Offce coud be mseadng f n a few years there
are ten network cabes n the managers offce.
Snce creatng abes by name or geographc ocaton have drawbacks, you mght be wonderng what w
work. We recommend usng a numerc numberng scheme. For exampe, you mght create a map of the
budng wth a CAD program and document the ocaton of each network outet. You coud then assgn each
network outet a number. Once youve assgned numbers, mark both ends of each gven cabe wth the
number that youve chosen. You shoud then mark the network outet on the map wth the number. As more
network outets are added, smpe add them to the map. The map shoud be posted on the wa n your
network wrng cosets so that at a gance you can te exacty where any gven cabe goes.
Log books
Another ssue to consder n network documentaton s the confguratons of your servers, workstatons, and
users. When t comes to creatng ths sort of documentaton, one massve og |ust doesnt get t. A snge og
tends to get to arge and too dffcut to ocate nformaton very qucky. Instead, we recommend creatng
severa dfferent ogs.
The frst thng that we recommend s havng a og book for each server. Ths og book shoud be kept wth
the server. Any tme that a change s made to the servers confguraton, detaed notes shoud be paced n
the servers og book. For exampe, f you add a servce pack to the server, you mght record the date and
tme of the upgrade, and the servce pack number.
Whe such nformaton may sound trva, keep n mnd that n many envronments more than one person
has admnstratve access to the servers. By keepng a compete hstory of any changes that each person
makes to a server, ts easy to see f one of your coworkers have made a recent change shoud a probem
come aong.
You coud aso keep a og book for each workstaton f you wanted to, but ths s often unnecessary n arge
envronments. In arge envronments, the goa s to make each workstaton as standard as possbe.
Therefore, you mght keep one og book that documents the standard confguraton and any changes that
you mght make to t.
Fnay, you shoud keep a securty og book. The securty og shoud contan a record of every user account
on the system aong wth nformaton such as what groups the account s a part of, and any speca access
permssons that the account mght have. Lkewse, the securty og shoud contan a st of groups aong wth
the groups members and permssons.
The securty og book may sound ke a ot of useess work when you consder that you can easy retreve
such nformaton drecty from the system. However, Ive seen countess stuatons n whch permssons
were damaged durng a server mgraton or other routne mantenance. In such a stuaton, you coud aways
get the permssons back by restorng a backup, but dong so requres tme and reverts users back to oder
fe versons. If your permssons become damaged, ts much qucker and easer to ook them up n a og
book and manuay correct the probem than to dea wth the hasses nvoved n a restore operaton. A
securty og book s aso extremey nce to have around shoud your boss hre a consutng frm to pu a
surprse securty audt.
Obvousy, your securty og book shoudnt be mted to nformaton on permssons. Your og book shoud
contan detaed nformaton about your securty poces n genera, such as how often you force password
changes, and mnmum password engths. You can reay use your magnaton when creatng a securty
book. Athough some admnstrators consder t to be gong too far, Ive seen Admnstrators ncude ega
documents n the securty og book. These documents are sgned by each user before they are gven a
network account and bascay cover such ssues as software pracy and Internet usage.
Topc 4 http://www.-zmbra.com/consutancy/t-audt-documentaton.htm
5T Audit 6 0ocumentation
Geeping a comprehensi!e and accurate set of network documentation is essential for any
business running 2/ systems.
Het despite this, it's not uncommon for i.Pimbra consultants to come across customer sites where
little or no network documentation e$ists.
/his can be a ma8or challenge as a lack of network documentation presents a number of
problems to businesses.
The 5mportance o! &reating Accurate Network 0ocumentation
o, if documentation is so important, why do so many companies neglect this critical area of 2/
managementD /he answer can be one of many reasons but the most common is simply that the
consultancy who implemented the network initially ne!er pro!ided any degree of documentation
and so there wasn't anything to update in the first place.
5esser 2/ consultants sometimes do not appreciate the importance of documentation and in the
worst cases, unscrupulous companies take the !iew that not pro!iding network documentation
plays to their ad!antage as the customer has no option but to call them as only they understand
the network.
3ere at i.Pimbra howe!er, we like to do things differently to much of our competition, as e!ery
network installation we pro!ide comes fully documented. imilarly, the network documentation
for each site we support is always updated as and when we make configuration changes to the
network.
Ris"s of Poor or o et!or" (oc%mentation
2t's undoubtedly bad practice not to pro!ide network documentation but there is also a business
risk to the customer which might cause financial loss through e$tended system downtime in the
e!ent of a hardware failure or problem.
/ypical e$amples of the sort of problems that no documentation causes include,.
Lost passwords, especay after staff changes
Faure to renew msson crtca securty software such as ant vrus
Faure to manage data backup probems when not propery documented
Fnanca rsks through poor software cence management
*ore Pro,lems Associated !ith Poor (oc%mentation
Changes in staff can e$ascerbate the detrimental effects of poor or no network documentation.
%urthermore, poor training can also impact ad!ersely and increase business risk.
Recently, one of i.Pimbra's 2/ consultants was asked to !isit a new client site where the
customer was being prompted to insert a second backup cartridge each morning in order to
complete their daily backup. What we disco!ered was that they were merely pushing in the
e8ected tape and, in so doing, were o!erwriting all but a few files of their daily backup.
3ad the customer in question been trained and pro!ided with network documentation, this
situation could ha!e been a!oided. imilarly, had they employed i.Pimbra sooner to pro!ide
their 2/ upport then as part of our procedures, we would ha!e identified this problem sooner.
0hat to &ncl%de in Essential et!or" (oc%mentation
+s a starting guide, it's considered best practice to include the following items in your network
documentation,
Server Hardware Confguraton & roes
Key user account usernames & passwords
Devce usernames and passwords
IP addressng and subnet mask detas
Detas of procedures
software cencng nformaton
3rd party contact nformaton
B . depending on the structure and si$e of an organisation% it&s usually best practice to keep
passwords securely protected% say in the fire safe where backup tapes are stored'
+lternati!ely, there are a number of software utilities such as GeyPass which can be used for the
storing of passwords. Naturally, i.Pimbra will be happy to ad!ise on which method is deemed
best for your business.
et!or" (iagrams
2deally, a !isual network diagram should be created to demonstrate the logical structure of the
network. /hat said, it should be borne in mind that a network diagram is no substitue for and
only useful in the e!ent of accompanying written information, plus it does present a further layer
to keep up.to.date
%or larger networks, products like Whats#pKold pro!ide a useful tool for network disco!ery and
documentation. +lternati!ely, 6icrosoft Misio has many useful elements for constructing a
detailed and meaningful network diagram.
.
(oc%menting 0ritten Proced%res
Procedures on how to maintain the network technology, including 4perating ystems, security
related ser!ices, backup and disaster reco!ery (business continuity*, and firewall technologies
should e$ist.
Soft!are +icencing (oc%mentation
+dditionally, you should document and secure all 4perating ystem and application licensing. i.
Pimbra can help with auditing your entire software in!entory, using the latest tools to ensure that
unauthorised or unlicenced software is not being used on the network and thereby putting your
business at risk of fine.
/his is something that is !ery often o!erlooked and is imperati!e if you ha!e to reco!er from a
disaster situation in which the rebuild of systems is necessary.
#ontact &nformation for Third Parties
+n oft o!erlooked area is to document all the third party contact information necessary for
pro!iding effecti!e 2/ support. 1ocumenting this key contact information should include details
for web hosting pro!iders,the 2P pro!iding 2nternet access, software support site 21s, username
and telephones etc.
With regard to the web hosting, we often disco!er that the registrate that hosts the 1omain Name
er!ices (1N* is not the same as the hosting company itself. Geeping a record of how to change
1N records is essential for ensuring no interuptions to email ser!ices mailflow and website
a!ailability are e$perienced.
%inally, as with website code itself, if bespoke software is in use then it is necessary to record
contact details for the software author<de!elopers concerned. While i.Pimbra is highly
e$perienced in both these areas and has pre!iously had to 7rescue7 customers who ha!e lost their
websites or whose bespoke software has ceased working.
Topc 5
http://www.techrepubc.com/artce/master-these-network-documentaton-
fundamentas/1058015
(aster these network documentation !undamentals
By Erk "Ecke Network+, MCP+I, MCSE"
February 28, 2003, 8:00am PST
IT documentaton and a set of |umper cabes share a smarty: You don't thnk
much about them unt you need them-but when the need arses, t's crtca to
have them. Athough IT documentaton pays an mportant roe n dsaster recovery
and fndng securty vunerabtes, the tme and resources requred to propery
document a network are often shortchanged.
IT certfcaton provdes the |ustfcaton you need to recommt yoursef to
documentng and anayzng your network. Mcrosoft's Wndows 2000 Network
Securty Desgn test (exam 70-220) tests canddates on ther abty to propery
evauate technca envronments. I recommend that as you prepare for ths exam,
you mpement the best practces for documentaton that the 70-220 test covers.
Begn by takng nventory
You shoud create a record of a the cent systems and servers that exst n your
organzaton. You shoud aso cataog the brands and mode numbers of swtches,
routers, prnters, and other devces and keep a st of whch OS versons and
patches have been apped to each network node. Be sure to coect a the settngs
possbe, ncudng protoco, network address, and adapter and bndng nformaton.
Your censng paperwork shoud get you up to speed on whch operatng systems
are nstaed, as we as the programs, appcatons, and thrd-party uttes your
organzaton has purchased and authorzed specfc empoyees to use. You shoud
ncude servce pack depoyment nformaton as we.
You can empoy Mcrosoft's Systems Management Server to coect ths nformaton,
aong wth detas about the systems and devces n use on your network. Even
thrd-party toos, whch everage the capabtes of Wndows Management
Instrumentaton, are avaabe to hep. Many of them can automate the gatherng of
ths nformaton usng software dscovery mechansms.
Revew your network nfrastructure
When pannng for securty or other upgrades, you must have a sod understandng
of your current network. Usng nformaton coected from your nventory, you
shoud record your network's actua physca structure. Documentng the ocaton of
crtca resources n dfferent stes can prove nvauabe, especay f dsasters occur
or you have to qucky rebud a faed system. For ths reason, t's aso mportant to
note the ocaton of DHCP, DNS, proxy, VPN, and other servers when creatng
physca network dagrams.
In addton to creatng a physca network dagram (usng a too such as Mcrosoft
Vso) that pnponts the ocaton of cents, servers, routers, frewas, and other
devces, you shoud create a ogca network dagram. Whe a physca network
dagram specfes the network address nformaton assocated wth each cent,
server, and devce, a ogca network dagram shoud be broken down by stes and
ncude such data as the number of prmary and backup doman controers at each
ocaton and the number of users that specfc ste supports. WAN nks between
each ste shoud be recorded, aong wth the capacty of each WAN connecton.
Evauate bandwdth ssues
Your network's performance capacty deserves ts own category. It's one thng to
know the types of LAN and WAN nks you have n pace; t's another to know the
oad eve each carres.
Obtanng basene measurements s crtca n documentng a network's bandwdth.
Wthout knowng average utzaton metrcs, t's next to mpossbe to te how new
nstaatons or changes mpact performance. Impementng securty measures
amost aways affects a network, so havng basene measurements becomes that
much more vauabe.
Wndows NT/2000 ncudes severa toos you can use to create these basene
averages. Performance Montor and Network Montor can both coect vauabe
nformaton about the amount and type of traffc traversng your network.
More documentaton assstance
The foowng artces can aso provde vauabe tps and best practces for network
documentaton:
"How to tacke a network documentaton pro|ect"
"Learn how to effectvey document your IT nfrastructure"
"Create effectve Vso dagrams for network documentaton"
"Keep documentaton updated wth change management"
"Use Vso to create at-a-gance documentaton of your server farm"
"Document your network wth hep from the OSI mode"
"Keep documentaton updated wth change management"
"Create your own custom stencs n Mcrosoft Vso"
Topc 7
3erver Fault
Buestions
Tags
$sers
:adges
$nanswered
+sk Buestion
How do you document a network?
It depends on the siAe of the network nu!ber of users nu!ber of nodes -co!puters servers printers
etc.. and the siAe of your IT staff a!ong other things.
It also depends on your goal. +re you docu!enting the network for training and !aintenance purposes
insurance8loss prevention etc1
,ersonally I docu!ent !y networks in such a way that I know I can derive any !issing infor!ation based
on what is docu!ented. Fro! a practical stance there is a point of di!inishing returns when your
docu!entation gets too granular.
+ good rule of thu!b I use is that there should be docu!entation in a known location that is thorough
enough that if I get hit by a bus tonight another ad!inistrator can keep the core network running while
he8she fills in the !issing pieces over the ne*t few days8weeks.
/ere is an overview of what I think is !ost i!portant about one of !y networks. For the record this is a
0indows&only shop with about D?? users and E offices.
+d!inistrator credentials for all servers. Obviously this should be kept secure.
I, +ddresses and )et:IO3 na!es for any node on the network with a static I, address including
servers workstations printers firewalls routers switches etc.
:asic server hardware infor!ation such as 3ervice tags or equivalent total disk capacity total
R+M etc.
Ma5or roles of each server such as %o!ain (ontroller File 3erver ,rint 3erver Ter!inal 3erver
etc.
9ocation of backup tapes8drives.
Infor!ation about the account nu!bers and credentials for services like re!ote office voice and
data providers.
4*ternal %)3 for websites and routing.
If there was anything strange about a setup or workflow that would not be i!!ediately obvious to a new
ad!inistrator I would write a short "brief" about it as well
http://www.ladenterprizes.com/networkdoc.htm
topc 9..
It is not uncommon to find out that an organization has little or no documentation when it
comes to their information technology.
What we do hear is
What is Network 1ocumentationD
Why is It Important?
What should be Included in a Manual?
Where should the Manual be stored?
Who is responsible for the Manual?
2snQt it elf 1ocumentingD
For organizations with limited support and funds, creating and maintaining network
documentation is a daunting task. 0!ery time new software is obtained or changes are made to a
network, documentation needs to be updated. 3owe!er, good documentation saves money and
time.
To begin with it provides the starting point for new information technology initiatives.
2t assists with maintaining an in!entory of the hardware and software assets.
2t pro!ides the ser!ice pro!ider staff with information needed to fi$ a problem. 2nstead of
spending time learning how a network is configured, time can be spent pro!iding a
solution.
5ast, if a disaster occurs or your network is 8ust plain down or sick, the documentation
pro!ides the roadmap so that the network can be rebuilt or reestablished as quickly as
possible.
0hat is et!or" (oc%mentation1
Network documentation is like an organi"ation chart for your network. 2t is the blueprint of how
a network is configured& how the applications and hardware work together.

0hy is et!or" (oc%mentation &mportant1
+lthough network documentation assists with planning and e$panding an information
technology infrastructure, most people think about the need when a problem occurs. Without
ha!ing workable software and hardware there is a good chance your business will not be able to
function efficiently. When your network is down, producti!ity is normally lost and customers
and clients many not be supported.

2f network documentation is a!ailable, when there is a problem that needs to be resol!ed, a
ser!ice pro!ider can quickly obtain an understanding of your network and minimi"e the time to
fi$ the problem resulting is a lower cost to you. 2f your business is too small for a full.time
technical person but you a ha!e a person on staff capable of pro!iding first line support, he<she
may be able to resol!e the problem without contacting a ser!ice pro!ider. /he easiest way to
e$plain why network documentation is important is to pro!ide an e$ample of what happens when
documentation is and is not a!ailable.
0$ample, 1ue to an en!ironmental mishap, a router with an integrated security solution needs
replacement. /he ser!ice pro!ider purchases a replacement, but there is no router configuration
documentation. 2nstead of taking ).5 hours to replace the router, the entire process ends up taking
about = days (): hours* and = weeks in lapse time. 2f you are using an outside ser!ice pro!ider,
Rate Rate
rovider !ourly "ate R)99 R)59
#ost With $ocumentation R)59 R==5
#ost Without $ocumentation R):99 R=F99
#onsideration also needs to be given to the
additional lost productivity costs by staff.
What should be included in Network Documentation Manual?
%very organization&s networ' documentation manual will have some similar items( but each
will also have items that are uni)ue to their organization. *ome basic items that should be
included are+
,isual diagram of the network layout including 2P addresses
!ardware and software inventory(
*erver -s. configuration(
#able mapping and patch panel diagram(
olicies and rocedures -i.e. bac'up. and
,endor contact information.



/dministrative /ccounts and asswords for all devices need to be recorded as well and 'ept
under loc' and 'ey. We recommend the entire manual be stored in a secure( if not loc'ed(
location.

Where Should the Documentation be Stored?
0etwor' documentation is never complete. %very time a new piece of hardware or software
is added to the networ'( the documentation should be updated. In this sense it is a 1living2
document. 3ou may want to store a soft copy of the networ' documentation manual on the
networ' so that it is easy to update. #ertain documents can be scanned -agreements(
invoices( etc.. and added to the manual so that a soft copy is available of all necessary
documents. / copy should be printed for reference and stored for easy access by either you
or a service provider. #onsideration should be given to storing a copy offsite as part your
disaster recovery documentation.

Who is Responsible to Create and Maintain the Documentation?
"easons for lac' of networ' documentation vary. Many businesses do not as' for the
documentation4 others are not willing to pay to have the documentation created or
maintained. Further( many in the technical community claim 1the system is self
documenting.2 This is true only to the e5tent that e)uipment and software can be
accessed. The service provider who designed the networ' may not thin' about providing
documentation( may not want to spend the time creating the documentation -it can be
boring tas'.( or assumes you will always be their customer so there is no need.

#reating and maintaining the documentation is the responsibility of the business as well as
the *ervice rovider.

Conclusion
If you do not have networ' documentation( as' your internal technical support staff or your
service provider to create the necessary documentation. #reate an internal procedure
and6or add to a service provider&s contract a documentation update re)uirement.
$etermine up front how much detail is to be included. 7ne point to be aware of it will cost
money to create and maintain the necessary documentation. If you do nothing at least
create a visual networ' diagram.

The reality is networ's change due to changes in business( periodically networ's have
problems( disasters occur( and technical people leave. The reality also is a business needs
to continue regardless of what happens to the networ' or staff. 8eing proactive and
documenting the networ' provides a much needed insurance policy.
http://searchnetworkng.techtarget.com/tutora/Network-documentaton-and-
audtng
topc 10
Network documentation and auditing
E-ma
Prnt
A
AA
AAA
LnkedIn
Facebook
Twtter
Share Ths
Reprnts
/he first step toward administering a network is to ha!e accurate and complete documentation of
the network. 1ocumenting a network will reduce administration time for issues such as updates,
user problems and disaster reco!ery. /here are four basic parts of a network that should
documented, 5+N oftware, 5+N 3ardware, Network 1iagram and #ser Names (21 numbers*
and network numbers. +ll documents should be kept in a secured location. 6ake sure that you
ha!e a policy in place and a person assigned to the responsibility of keeping all documentation
up to date and accurate.


Documenting your network
1. Obtain or contruct a building diagram/floor plan.
2. Obtain or contruct a p!"ical networ# diagram.
3. Obtain or contruct a logical networ# diagram. $%oftware pac#age can
reearc! and...
Topc 11:- http://searchnetworkngchanne.techtarget.com/feature/Channe-
Checkst-10-steps-for-network-documentaton
&hannel &hecklist: 1. steps !or network documentation
E-ma
Prnt
A
AA
AAA
LnkedIn
Facebook
Twtter
Share Ths
Reprnts
#y #rien 7osey2 &ontri4utor
+lthough network documentation is always a good idea, it's
especially important for ser!ice pro!iders and !alue.added
resellers (M+Rs*. 1ocumenting your customers' networks can
make the troubleshooting process much more efficient when
problems arise. /hese same network documents can also help
you spot areas of your customers' networks that may need to be
upgraded, gi!ing you the possibility of earning e$tra re!enue.
%inally, good network documentation pro!es that you adhere to
industry best practices, and could be your best defense should a
customer e!er file litigation against you for something network.
related.
/here are a number of network documentation products a!ailable that can assist with the
documentation process, and Windows Mista also has mapping capabilities built in. ome of the
more well.known network documentation applications include,
SmartDraw
OonDoc
LAN Surveyor
NetZoom
ConceptDraw
Mcrosoft Vson 2007
Create a network documentation policy
(ore on network
documentation
Check out our top fve
tps on network
documentaton.
+ network documentation policy should detail what aspects of a network need to be documented,
especially each ser!er. + documentation policy also communicates to each administrator e$actly
what is e$pected of them regarding the documentation process.
Create a network topology diagram
2deally, you want this map of the network's topology to include each network segment, the
routers connecting the !arious segments, and the ser!ers, gateways and other ma8or pieces of
networking hardware that are connected to each segment. %or larger networks, you may ha!e to
create a general segment map and make more specific maps of each indi!idual segment.
1ocument ser!er names, roles and 2P addresses
While the information included in a network topology diagram is not necessarily specific, there
is certain information that you should include for each ser!er, e!en if that information has to be
placed in an appendi$. %or each ser!er, list the ser!er's name, its 2P address and the role that the
ser!er is performing (1N, 13CP, mail ser!er, etc.*. Geep in mind that a ser!er may be
assigned multiple 2P addresses or ha!e multiple N2Cs, so you should document that information
too.
Create a change log for each ser!er
When a ser!er fails, the failure can often be traced to a recent change. +s a part of the network
documentation, consider making a log book for each ser!er for documenting changes such as
patch and application installations and modified security settings. Not only will the log help you
troubleshoot future problems, it can help you rebuild the ser!er in the e!ent of a catastrophic
failure.
1ocument software !ersions and proof of licenses
1ocument the applications and their !ersions running on each ser!er. Hou might also include a
copy of the software license or a receipt within this documentation 8ust in case your customer
becomes in!ol!ed in a software audit.
1ocument hardware components
2 ha!e talked about documenting indi!idual ser!ers, but it's equally important to document
switches, routers, gateways and other networking hardware. /he documentation should include
information such as,
How s the devce connected to the network?
How s the devce confgured?
Does a backup of the confguraton exst?
What frmware revson s the devce runnng?
Is the devce confgured to use a password? (Don't ncude the actua
password, but you can ncude a password hnt or a reference to the
password beng wrtten n a notebook that s stored n the safe.)
1ocument the +cti!e 1irectory
2 could probably write a book on +cti!e 1irectory documentation, but here are a few things that
you should consider documenting,
The names of the domans n the forest.
The Actve Drectory ste structure.
Where the varous servers exst wthn the Actve Drectory herarchy.
The ocaton and contents of each group pocy.
Any externa trusts that may exst.
1ocument your backup procedures
-ackup is your customer's best defense against a catastrophe, but it will do little good if nobody
can figure out how to use it. -e sure to document the backup software used and its !ersion (!ery
important*. Hou will also want to document the tape rotation scheme, a general description of
what's included in each backup 8ob and where the backup tapes are stored.
5abel e!erything
2 once had a client ask me to do a consulting pro8ect for them. /hey ga!e me a thorough and
well.written copy of their network documentation to re!iew ahead of time. -ut when 2 got on
site, 2 reali"ed that none of the hardware was labeled. +ll of the ser!ers looked identical and
there was no way to differentiate between them.
Ket a label maker and label all ser!ers, critical hardware components (gateways, routers, etc.*
and the most important cables. /his will make it easy to identify the !arious pieces of hardware
listed in your network document.
0!aluate your documentation
/he last step in the documentation process is to e!aluate your network documentation to make
sure that it's sufficient for you and your customer's needs. /hink of your network documentation
as a critical part of your disaster reco!ery strategy. When the first draft of your documentation is
complete, you must ask yourself if it's good enough to help someone with no prior knowledge of
the setup to rebuild the network from scratch in the e!ent of a catastrophe. 2f the answer is yes,
then you'!e done a good 8ob on the documentation.
http://thecckstarter.com/webste-technca-requrements-smpfed
Technical &e'uirements to (aunch )our Website*
!impli+ied
by %avid F 0eb 3trategy
?
in!hare
This is an article in the 0ebsite (lick3tart7 3i!plifying the 3teps to (reating 'our First 0ebsite series.
This plain 4nglish series is written for regular people -not web progra!!ers or rocket scientists. who
need to create their first business website.
+fter planning your website pages written the content identified signposts and calls to action youGre now
faced with the task of actually putting your website out there on the internet.
This article is going to e*plain what require!ents need to be !et to !ake that happen. These
require!ents are technical but stay with !e# IG! going to si!plify and break it down for you.
There are > !ain require!ents that you need to get your website online. To help us understand these >
require!ents letGs use the -fictional. +:( 0idgets as an e*a!ple.
HD. %o!ain )a!e
+n address to find you
)ow i!agine that you need to buy so!e widgets fro! +:( 0idgets. 'ou will need to pick the! up fro!
their outlet or office so what is the first thing that you do1 'ou look up their address.
For your website the do!ain na!e is your address. The do!ain na!e is the string of te*t that has a
.co! .net .so!ething at the end of it. /ere are so!e e*a!ples of do!ain na!es7
!ybusiness.co!
!yblog.co.uk
!ywebsite.!e
%epending on the goal of your website you should choose a do!ain na!e that reflects your business
-e.g. !ybrand.co!. your website topic -e.g. eco&friendly&tips.co!. or your na!e -e.g. 5ohndoe.co!..
+ll the good do!ains are running out so quickly grab yours today. 4ven if you donGt plan to use it right
away itGs a good idea to reserve it so that no one else can get it. +fter all a .co! do!ain na!e cost only
about ID? per year.
Side note: When you want to visit a website, you can type its address directly into the address bar. Ive
seen people go to Google and type in the address there. Typing the address into the address bar will
save you a click.
H<. 0eb /osting
'our physical location
3o now you have an address but where does it point to1 In the case of +:( 0idgets the address will
lead you to a co!!ercial area where their outlet and office are located.
0eb hosting is like your websiteGs outlet or officeJit is the physical location on the internet where the
website lives. +nother benefit of web hosting is that you can have your own personaliAed e!ail address
e.g. !yna!eK!ybusiness.co!.
There are different types of web hosting. The !ost co!!on are7
!hared hosting. This is where you share a web server with other websites. For +:( 0idgets it would be
like occupying a single unit within the whole co!!ercial area.
,irtual !er%er* or ,!. @,3es are si!ilar to shared hosting but you have !ore space and resources. If
+:( 0idgets had a @,3 for their website it would be like owning an entire floor within an office block.
Dedicated !er%er. 0ith a dedicated server the website takes up D??L of the web server. For +:(
0idgets it would be as if they owned the whole co!!ercial area block.
For !ost of us a shared hosting plan would be !ore than enough. 4ven this website is hosted on a
shared hosting plan. + good shared hosting plan will cost you about IM? J I<?? per year -IN J I<? per
!onth..
F'I !ost people si!ply refer to their web hosting plan as Oweb hostG or Oweb serverG.
0eb ,ages
/TM9 web pages
In real life custo!ers go to the +:( 0idgets outlet to buy widgets. On your website visitors co!e to
view web pages.
3o the final require!ent for your website to be online is to have web pages for your visitors to view. The <
!ain alternatives to do this is7
D. (reate web pages with web design software and upload it to the web server
<. $se a (M3 -content !anage!ent syste!. to create your pages
/owever these < alternatives alone throw up thousands of different options for doing the sa!e thing. For
e*a!ple there are hundreds of web design software you can use like %rea!weaver Frontpage
;o!poPer Rapid0eaver.. and the list goes on.
0hatever you choose there will always be a learning curve so e*pect to spend so!e ti!e learning. +lso
be sure to choose a popular web design software or (M3 so that you can ask others who use it too for
help.
0here do I start1
)ow the proble! is that there are hundreds or even thousands of options of where to get your do!ain
na!e and web hosting. There are probably a !illion !ore options to create your web pages.
To save you the hassle of doing the research here are !y reco!!endations of what has worked for !e
and !y clients before.
D. -luehost is the web host that I refer all !y friends to. Bluehost will give you a ree do!ain na!e so
you can actually kill < birds with D stone. They offer a si!ple plan with everything that you need. 'ou can
also host !ore than D website on your :luehost plan.
<. .o%er is where I register all !y do!ain na!es. In !y e*perience with registering doAens of do!ain
na!es I found that /over is the !ost value for !oney and they donGt nickel and di!e you like others. If
you use this link to buy your do!ain youGll get D?L off J http788hover.co!8clickstarter
>. To publish !y web pages I choose to use a (M3 called Wordress. ItGs free and itGs the !ost popular
(M3 software in the world. This guarantees that there are lots of people who can help !e if I ever need it.
IGve also created a new page on this site that lists different options for you to get started in case you want
to e*plore others than the ones above. I will be constantly updating this page. (lick to view the Resources
I reco!!end.
)e*t +ction
Register your do!ain na!e today. If you are ready to put up your website go to 2usthost to sign up for
both your do!ain and webhosting. If 2usthost doesnGt have the do!ain na!e you want try 6o%addy
instead.
Tip7 0hen buying your do!ain or hosting plan you can safely ignore all the upsells.
http://www.web-source.net/web_ste_desgn9.htm
When you're ready to launch your web site, you'll need to make two !ery important decisions ..
what your domain name will be and where you will host your new site.
0omain Name
+ domain name is used to locate a particular web site on the 2nternet. 2t is a part of the #niform
Resource 5ocator (#R5* and instructs the browser as to where to find a particular web page.
When a web address (http,<<www.domain.com* is typed into the browser, the web ser!er will
look for a page called inde$. /his page may ha!e different e$tensions, such as .htm, .html, or
.shtml and will be displayed when the #R5 is called.
+dditional pages within the site are called by including the #R5 followed by a forward slash and
the page name. http,<<www.domain.com<page.htm
3electing a 8uality 0omain Name
electing a quality domain name is of the utmost of importance. Not only will it tell your
potential customers what your business is all about, but it will also play a role in branding.
+ good domain name is one that will be immediately remembered by your !isitors, as it connects
with something they're interested in.
+ great domain name is one that can be guessed by a potential !isitor looking for something in
particular. %or e$ample, if someone is looking for information on dog grooming, they might type
in, http,<<www.doggrooming.com. + great domain name will enable a potential !isitor to guess
the web address and will contain your most rele!ant keyword phrase.
3ere are some basic guidelines to assist you in selecting a great domain name,
)* elect a domain name that contains your most rele!ant keyword phrase.
=* Hour domain name should be easily remembered.
@* +!oid using abbre!iations or anything that will be difficult for your !isitors to remember.
F* Geep your domain name as short as possible.
5* elect a quality domain name that will grow with your business.
+lthough there are many new domain e$tensions a!ailable, dot.com is still the best choice.
/here are many companies online that will enable you to register a domain name. +lthough
Network olutions is the original domain name registrant, there are now many less e$pensi!e
options a!ailable. Hou may want to do some research to find a registrant that meets your needs.
http,<<www.networksolutions.com
2f you're 8ust starting out, you may want to select a hosting company prior to registering your
domain name, as many hosting companies will register the name for you when you set up your
hosting account.
9e4 :ost
+ Web 3ost is a company that pro!ides you with ser!er space for your web site. /his includes
all of your web pages, graphics, scripts and files.
When your web address is typed into a browser, your web host is being contacted to locate and
display the requested page.
Free %erses 7ro!essional 9e4 :osts
+ll Web 3osts are not created equally. /here are a number of free hosting ser!ices a!ailable on
the 2nternet. 3owe!er, if you're designing a web site for business purposes, you should N0M0R
host your web site with a free host.
2n order to establish credibility, you must be willing to in!est in your own domain name and
professional web hosting. Web sites hosted on free ser!ers are not taken seriously and will suffer
a serious loss of business.
Hour !isitors may feel that if you don't ha!e your own domain, you may not be a credible
company. /hey'll simply take their business elsewhere.
Not only is professional credibility a great reason not to host with a free ser!ice, but many
earch 0ngines won't e!en inde$ a site hosted on a free ser!er.
2f you're serious about your business and you ha!e a sincere desire to succeed, ha!ing your own
domain name and professional hosting is a must.
3electing a 8uality 9e4 :ost
When selecting a professional web host, your first consideration should be the company. Check
out their background. /alk with some of their customers and ask them if they'!e been satisfied
with their ser!ice.
1o some research,
S 3ow many customers do they ser!eD
S What is their uptime percentageD
S 1o they require you to make payments in ad!anceD
S 1o they charge set up feesD
S 3ow is their customer supportD /est them.
S 1o they offer fast connectionsD
S 3ow much daily transfer do they allowD
S Will you be charged additional fees if you e$ceed your daily transferD
S 1o they offer shopping cart software to process your ordersD
S 1o they offer secure ser!ersD
S Will you be pro!ided with your own CK2.binD
S Can you upgrade free of chargeD
Web hosting prices !ary greatly. When selecting a host, make sure you're getting e$actly what
you're paying for. Geep in mind, a lower monthly rate will not benefit you if your site
is down a lot, slow, or customer ser!ice is poor.
electing a professional web host is a !ery important decision. 6ake sure you do your
homework and ensure the host you select offers e$actly what you need.
3ere are some basic features you should look for when selecting a web host,
)* =F<E reliable tech support
=* Hour own domain name (www.yourname.com*
@* +t least )9K- of monthly transfer (traffic*
F* + minimum of =96- . 596- of ser!er space
5* #nlimited true P4P email accounts . nameTyourdomain.com
:* #nlimited email aliases
E* 0mail forwarding
I* #nlimited autoresponders
;* Hour own unrestricted CK2.-in
)9* +ccess to 5 0ncryption for secure transactions
))* 6yU5 1atabase
)=* P3P
)@* Perl
)F* htaccess password protection
)5* er!er ide 2ncludes (2* support
):* 1esign (and upload to* your site using Netscape or other 3/65 editing software
)E* 6icrosoft %rontPage er!er 0$tensions for those utili"ing %rontPage
)I* #nlimited free access to your ser!er !ia %/P</elnet
);* 0asy access to your log files
=9* tatistics on !isits to your site
ome additional features you may want are,
S Web control panel
S Custom error pages
S +bility to run Cron e!ents
S ub.domains
S 6ailing list<newsletter support
S #R5 redirect
S Web mail
S hopping cart
S Referral program
+lthough there are many web hosting companies online, there is only one that 2 can personally
recommend, and that company is 3ostFProfit. Not only do they pro!ide a good hosting package
that includes e!erything you'll need, but their customer support is e$cellent.
http,<<www.web.source.net<cgi.bin<t.cgiDlOhFp
When selecting a domain name and hosting company( ta'e your time and do some research before
ma'ing a decision. It will be well worth your time and effort in the long run.
http://sxrevsons.com/web-deveopment/10-smpe-tps-for-aunchng-a-webste/
1. 3imple Tips !or ;aunching a 9e4site
6ar @ =9)9 by Vacob Kube W := Comments W tumble -ookmark
/he process of launching a website can be a daunting endea!or. /here are many things you want
to do, but not enough time and resources to do them. 3owe!er, e!en though it might seem like a
herculean task, as long as you keep some fundamental things in mind, you can ensure a hassle.
free website launch.
2n this article, 2Qll share with you some tips for launching a website based on the e$perience of
our own launch of 1esign 2nstruct.
(his article is part of esign )nstruct *eek% a weeklong celebration of our newly launched site%
esign )nstruct' (his week on Si! Revisions covers topics that deal with running websites and
design% written by the founders/editors of esign )nstruct and Si! Revisions' Be sure to check out
the esign )nstruct *eek (witter +iveaway% which gives out different pri$es every day of esign
)nstruct *eek'
2. Ha$e scala,le !e, ser$er reso%rces
With todayQs high.a!ailability and cost.effecti!e content distribution solutions such as +ma"on
@, and on.demand instant scalability offerings of hosting pro!iders such as MP.N0/, you can
affordably ha!e web ser!ers that can take a beating from high.burst traffic.
Not only will ha!ing scalable solutions prepare you for the high.traffic that a website launch can
generate, but it also future.proofQs your set.up as your website grows. 3igh.a!ailability, metered
set.ups gi!e you the ability to pay for 8ust the resources you need right now.
%or 1esign 2nstruct, we set up a C1N for distributing static files for our content.hea!y pages,
and scaled up our MP resources temporarily on the day of the site launch because we were
anticipating a huge burst of traffic.
Regardless of how big or small you think the traffic youQll get is, itQs ne!er a bad idea to get a
web hosting solution that will scaleJtheyQre tremendously affordable and you pay only for what
you intend to use.
1onQt risk ha!ing your website crash and your launch day ruined because of a shoddy web
ser!er.
3. Get all of yo%r social media acco%nts ,eforehand
Nowadays, social networking is integral to a website. 1onQt wait the last minute to sign up and
set up your social network accounts on /witter, %acebook, 6ypace, and any other site that
youQre planning to engage in.
/his guarantees that your preferred account name will be a!ailable before you become known
and gi!es your !isitors additional ways to communicate with as soon as they arri!e at your
website.
4n 1esign 2nstruct, our social media accounts were established well before the siteQs launch
date. %or e$ample, we had our /witter account set up close to a month ahead of our site launch.
4. Ha$e content ready to p%,lish for at least a month
/he early stages of a website is filled with many tasks. 4ne timesa!ing deed you can do is to
ha!e content ready to publish so that you can follow up your launch with great content. /his also
frees you up for the many other acti!ities in!ol!ed in this stage of your websiteQs growth.
%or 1esign 2nstruct, we set out to ha!e )9 tutorials ready to go before we launched the site. We
didnQt quite make that goal before our launch date, though we had enough to comfortably go
ahead with the launch. /his enabled us to focus on tasks that needed to be tended to without fear
that we wouldnQt ha!e great content to publish.
5. (rop hints a,o%t the %pcoming la%nch to ,%ild anticipation
5et people know that thereQs an e!ent thatQs going to occur to help create some hype. 2f you want
to keep the details undisclosed to the publicJthatQs fineJyou can still let people know that
something on some date is going to happen.
2n 1esign 2nstructQs case, we wanted to wait until the actual launch before re!ealing what the site
was. /hat didnQt pre!ent us from dropping hints that there was something coming soon. We did it
through inter!iews and on /witter a month ahead of the actual launch date.
/his type of subtle hinting can pique the interests of your long.time supporters and fans. +nd
those are the people that count the most when your website launches.
6. Plan yo%r tas"s for at least a month after the site la%nch
/he worst question to ha!e after a site launch is, 7Now whatD7 Hou need a clear goal and
direction on how you intend to follow through your siteQs launch. 2f youQ!e planned for a big site
launch, donQt let the initial interest fi""le out by not ha!ing a plan. -efore you launch, you should
know e$actly how you want to proceed right after.
%or e$ample, on 1esign 2nstruct, we had a laundry list of things we wanted to work on. 3a!ing
content ready to publish, we were able to focus on growing the site and impro!ing the user
e$perience for our readers.
7. Triple-chec" the technical details ,efore going li$e
6easure twice, cut once. -etter yet, measure thrice. 6aking certain that your early !isitors will
ha!e the best e$perience possible when first arri!ing at your site means that e!erything needs to
be working correctly.
Check to make sure that all hyperlinks work. 6ake ultra.sure that contact forms, email accounts,
commenting systems, and all the other things that your users will interface with, is working
properly.
4ne of the late quick fi$es we had to implement 8ust hours before 1esign 2nstructQs launch had
something to do with category pages.
#sers !isiting a category page from the sidebar links that didnQt ha!e an associated tutorial under
it simply said that the page could not be found. 2t ga!e the impression that there was something
wrong.
We had to re!ise the message to say, 7/here arenQt any posts in this category yet. WeQre working
on it though, so please check back soonX7 to let users know that the pages do work, 8ust that there
arenQt anything in them yet.
8. +a%nch on sched%le
Whether youQ!e announced your launch date or not, you should release your website to the
public when you say youQre going to. /his forces you to stay on point and work towards a goal.
What can cripple and delay a website launch is the attitude of 72tQll be ready when itQs ready.7
When youQre nearing launch day and you think you wonQt ha!e the site fully completed, launch
anyway (as long as itQs presentable and usable*.
Websites arenQt like con!entional consumer productsJyou can update and upgrade them any
time you want.
+t 1esign 2nstruct, we were delayed with some of the site features we wanted to implement,
such as a comment rating system and a post rating system.
We still went ahead with the launch and created a malleable and constantly updated #pcoming
%eatures page that listed the things we wanted to do in the future. We would curate this list by
adding and remo!ing items based on what our users want.
9. #ontact yo%r friends and family a,o%t the site la%nch
/he first thing to do after a site has launched is to contact your friends and family. 5et them
know that youQ!e launched the site so that they can be the first to see it.
4ur friends list is 8ust a bit larger than most people 8ust starting out. 3owe!er, we still sent
personal emails to our friends at mashing 6aga"ine, +bdu"eedo, 0n!ato and others. We
announced the site launch here on i$ Re!isions so that our regular readers would be the first to
know about our new site.
2t doesnQt matter how big your list of friends and family is, they should be the first to know about
your siteQs launch.
:. Pro$ide easy !ays of contacting yo%
When you first launch a site, you ha!e to gi!e !isitors ways to communicate with you easily.
Hour initial !isitors are early adopters, and as such, theyQll be critical and will help you find
things that might be wrong with the site, as well as suggest ways you can impro!e the site for
future users.
%or 1esign 2nstruct, we had se!eral modes of communication a!ailable, email, /witter, the
comments section in the announcement post on i$ Re!isions, and the comments section in the
welcome post on 1esign 2nstruct.
/his enabled us to find out what early adopters thought about the site, and what they wanted to
see in the future.
We were also able to disco!er bugs !ia reports in comments and /witter such as the error in
color profiles in our C sprite and forgetting to set up R auto.disco!ery.
2;. Sho! site $isitors a roadmap of !hat<s to come
Perhaps the most important thing you can do when you launch a site is to show your initial users
that thereQs more to come.
No one gets a site right on the first day. #nless you release your website, anything you think
your users will want and need is 8ust a guess. /he people who will best help you figure out what
works for your users are your users.
o weQ!e set up an #pcoming %eatures page and asked our users to tell us what they want and
what they donQt want.
WeQ!e periodically polled our supporters and fans through /witter to determine what we should
do ne$t.
We also track all of our site changes publicly through our changelog and !ersion history to show
our readers that we are indeed mo!ing forward with their suggestions.
5et your users see that you ha!e more tricks up your slee!e and that they should stay on for the
ride as your website continues to grow.
Share yo%r o!n tips for la%nching a !e,site in the comments.

Potrebbero piacerti anche