network documentation

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.


Reply to
Loading thread data ...

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.

Reply to
Rod Dorman

=A0 =A0 -- Rod --

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.

Reply to

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:

formatting link
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:

Reply to

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.

Reply to

Thank you for you time, and great advice.

Reply to
explorer Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.