Hello, what is content of network documentation? I read many documents
but there is nothing like most common check list for content of that
documentation, and specialy I am interested how to document
Telecommunication rack, should I use table or some another way. I have
to document new network wich is just lay down ( horisontal and
vertical cabling) and i don t have anything.

Thx

In article <8a57d405-b770-4dce-a398-c60700d4556e@w24g2000prd.googlegroups.com>,
explorer  <skondro@gmail.com> wrote:
>Hello, what is content of network documentation? I read many documents
>but there is nothing like most common check list for content of that
>documentation, and specialy I am interested how to document
>Telecommunication rack, should I use table or some another way. I have
>to document new network wich is just lay down ( horisontal and
>vertical cabling) and i don t have anything.

In broad terms (to match your broad question) it contains a
description (and perhaps a design rational) of your network so that
the next person who needs to maintain it (which could be you) has a
decent chance of maintaining it without screwing it up.

-- 
					-- Rod --
rodd(at)polylogics(dot)com

On Dec 14, 6:43=A0pm, r...@panix.com (Rod Dorman) wrote:
> In article <8a57d405-b770-4dce-a398-c60700d45...@w24g2000prd.googlegroups=
..com>,
>
> explorer =A0<skon...@gmail.com> wrote:
> >Hello, what is content of network documentation? I read many documents
> >but there is nothing like most common check list for content of that
> >documentation, and specialy I am interested how to document
> >Telecommunication rack, should I use table or some another way. I have
> >to document new network wich is just lay down ( horisontal and
> >vertical cabling) and i don t have anything.
>
> In broad terms (to match your broad question) it contains a
> description (and perhaps a design rational) of your network so that
> the next person who needs to maintain it (which could be you) has a
> decent chance of maintaining it without screwing it up.
>
> --
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 -- Rod --
> rodd(at)polylogics(dot)com

I am familiar with ANSI/TIA/EIA 568-B.1, ANSI/TIA/EIA 568-A, ANSI/TIA/
EIA 568-B.2-1 and so on, but is there some list of required
documentation in order to have standard network documentation. Or I
choose and decide what document to put in documentation.

You can look at IT management methodologies like ITIL, Cobit, and the 
like, however, they don't really spell out *how* to go about specific 
documentation.

Check out this link:

http://searchnetworkingchannel.techtarget.com/topics/0,295493,sid100_tax304690,00.html

This should get you started. As for specific standards, I don't believe 
there are any formal standards defined. It's kind of like the color of 
UTP cable. You'll find some guidelines or recommendations about riser 
color, station color, patch panel, etc., but no specifics. It's pretty 
much whatever "standard" your team implements. As a start for your 
network documentation try starting with:

1.)	Physical layout - L1 stuff such as floor plans and rack/cabinet layouts
2.)	Logical layout - interfaces, IP addresses, subnets, VoIP dial-plan, 
other L2+ entities
3.)	Configuration management - A content versioning system is helpful 
for things like router and switch configs.
4.)	Policies - network access, security, end-user, etc.
5.)	Staff  - contact information, after-hours support (vendor), 
up-to-date job descriptions, business-unit contacts (liaison for 
business impacting changes)
6.)	Troubleshooting - save packet traces, narratives, and any other 
information into a folder specific for the project or task
7.)	Implement a centralized logging solution and some sort of AAA system 
for infrastructure devices.
8.)	Develop a toolkit (PERL, Pancho, etc.) to automate the archiving of 
router/switch configs nightly.
9.)	Take the time to baseline your network. Start at the edge and work 
your way to the core or other functional block. Grab the current config 
of the appropriate device. Grab a packet trace of the known applications 
on your network. Save these traces for future reference when those 
application break or new apps are introduced.
10.)	Turn on things like Netflow in your routers and send the data to a 
Netflow collector. There are a number of opensource tools out there. 
Take a look at Ntop...this will get you a quick and dirty collector up 
and running. It's pretty useful for traffic flow analysis.
11.)	Take a look at tools like Cisco NMIS, Nagios, Pancho, iperf, LFT, 
and such. They are all free and extremely useful for ongoing maintenance 
of your network.

Documentation is an ongoing, living thing. Try to use as many tools as 
possible and don't do things manually if you can help it. :-) Drawings 
are a challenge, but there's not much you can do about that. Visio is 
really the de-facto tool for drawings, but take a look at Network 
Notepad. It's free and can get you started with the basics.

I guess that's about it. Good luck and believe me when I say that if 
your doing at least some of these things, you'll be SO happy you did. 
Your auditors (if you deal with compliance) will be appreciative, too. ;-)




explorer wrote:
> Hello, what is content of network documentation? I read many documents
> but there is nothing like most common check list for content of that
> documentation, and specialy I am interested how to document
> Telecommunication rack, should I use table or some another way. I have
> to document new network wich is just lay down ( horisontal and
> vertical cabling) and i don t have anything.
> 
> Thx

The point of "Network documentation" is to assist in troubleshooting and for 
engineering new connections.  The most helpful documentation is simple.  For 
racks, make sure all the equipment in the rack has a label on it with the 
hostname, simple but very effective.  In our data center, each rack is also 
labeled with a name, so if you know that router "balti00R01" is in rack 
"Chas-X10", you know exactly where it is.  Logical diagrams that show how 
everything is connected together is best.  We have documention that shows 
how the "core" network is connected together, a WAN diagram that shows all 
the major WAN connections, and then a diagram of the each of the WAN 
networks based on carrier. We also have "representation" diagrams for our 
branches.  Each one is pretty much the same, so there is no point in 
creating one for each location.  Too much detail that doesn't provide any 
real value is bad because documentation is only good if it is accurate.  If 
you add too much detail that needs to change often, it is worthless because 
it is soon out of date.

Documenting the contents of a rack or where cables are run is not much help
"explorer" <skondro@gmail.com> wrote in message 
news:8a57d405-b770-4dce-a398-c60700d4556e@w24g2000prd.googlegroups.com...
> Hello, what is content of network documentation? I read many documents
> but there is nothing like most common check list for content of that
> documentation, and specialy I am interested how to document
> Telecommunication rack, should I use table or some another way. I have
> to document new network wich is just lay down ( horisontal and
> vertical cabling) and i don t have anything.
>
> Thx 

On Dec 15, 12:05=A0am, fugettaboutit <n...@mas.com> wrote:
> You can look at IT management methodologies like ITIL, Cobit, and the
> like, however, they don't really spell out *how* to go about specific
> documentation.
>
> Check out this link:
>
> http://searchnetworkingchannel.techtarget.com/topics/0,295493,sid100_...
>
> This should get you started. As for specific standards, I don't believe
> there are any formal standards defined. It's kind of like the color of
> UTP cable. You'll find some guidelines or recommendations about riser
> color, station color, patch panel, etc., but no specifics. It's pretty
> much whatever "standard" your team implements. As a start for your
> network documentation try starting with:
>
> 1.) =A0 =A0 Physical layout - L1 stuff such as floor plans and rack/cabin=
et layouts
> 2.) =A0 =A0 Logical layout - interfaces, IP addresses, subnets, VoIP dial=
-plan,
> other L2+ entities
> 3.) =A0 =A0 Configuration management - A content versioning system is hel=
pful
> for things like router and switch configs.
> 4.) =A0 =A0 Policies - network access, security, end-user, etc.
> 5.) =A0 =A0 Staff =A0- contact information, after-hours support (vendor),
> up-to-date job descriptions, business-unit contacts (liaison for
> business impacting changes)
> 6.) =A0 =A0 Troubleshooting - save packet traces, narratives, and any oth=
er
> information into a folder specific for the project or task
> 7.) =A0 =A0 Implement a centralized logging solution and some sort of AAA=
 system
> for infrastructure devices.
> 8.) =A0 =A0 Develop a toolkit (PERL, Pancho, etc.) to automate the archiv=
ing of
> router/switch configs nightly.
> 9.) =A0 =A0 Take the time to baseline your network. Start at the edge and=
 work
> your way to the core or other functional block. Grab the current config
> of the appropriate device. Grab a packet trace of the known applications
> on your network. Save these traces for future reference when those
> application break or new apps are introduced.
> 10.) =A0 =A0Turn on things like Netflow in your routers and send the data=
 to a
> Netflow collector. There are a number of opensource tools out there.
> Take a look at Ntop...this will get you a quick and dirty collector up
> and running. It's pretty useful for traffic flow analysis.
> 11.) =A0 =A0Take a look at tools like Cisco NMIS, Nagios, Pancho, iperf, =
LFT,
> and such. They are all free and extremely useful for ongoing maintenance
> of your network.
>
> Documentation is an ongoing, living thing. Try to use as many tools as
> possible and don't do things manually if you can help it. :-) Drawings
> are a challenge, but there's not much you can do about that. Visio is
> really the de-facto tool for drawings, but take a look at Network
> Notepad. It's free and can get you started with the basics.
>
> I guess that's about it. Good luck and believe me when I say that if
> your doing at least some of these things, you'll be SO happy you did.
> Your auditors (if you deal with compliance) will be appreciative, too. ;-=
)
>
> explorer wrote:
> > Hello, what is content of network documentation? I read many documents
> > but there is nothing like most common check list for content of that
> > documentation, and specialy I am interested how to document
> > Telecommunication rack, should I use table or some another way. I have
> > to document new network wich is just lay down ( horisontal and
> > vertical cabling) and i don t have anything.
>
> > Thx

Thank you for you time, and great advice.