Creating Network Documentation for a small City
I am hoping someone on CCNP forum may have dealt with creating documentation before.
--- Repost from CCNA/CCENT forums. ---
This is not a very specific question but I am looking for any input from others that might have had to create network documentation for a new organization.
I want to try to document the network infrastructure for a city IT department (10+ sites). However because of security risks I am not really allowed to use software that might save the data offsite. I will not be allowed to enter security credentials into the program for any network admin access. I can probably install freeware for the project as long as the data is not being collected and sent anywhere else. It might just be information I can collect manually.
So my two main questions are:
1 - Has anyone tackled a project like this before and if so can you give me some ideas of where to start.
2 - Can anyone point me to a good reference for sample documentation or best practices.
Thanks in advance for any tips.
Jon
--- Repost from CCNA/CCENT forums. ---
This is not a very specific question but I am looking for any input from others that might have had to create network documentation for a new organization.
I want to try to document the network infrastructure for a city IT department (10+ sites). However because of security risks I am not really allowed to use software that might save the data offsite. I will not be allowed to enter security credentials into the program for any network admin access. I can probably install freeware for the project as long as the data is not being collected and sent anywhere else. It might just be information I can collect manually.
So my two main questions are:
1 - Has anyone tackled a project like this before and if so can you give me some ideas of where to start.
2 - Can anyone point me to a good reference for sample documentation or best practices.
Thanks in advance for any tips.
Jon
Comments
-
OfWolfAndMan Member Posts: 923 ■■■■□□□□□□The best program for creating a clean looking topology (And I assume an industry standard) is Microsoft Visio. You'll need custom icons for the network topology. Here's a start: Network Topology Icons - Doing Business With Cisco - Cisco Systems:study:Reading: Lab Books, Ansible Documentation, Python Cookbook 2018 Goals: More Ansible/Python work for Automation, IPSpace Automation Course [X], Build Jenkins Framework for Network Automation []
-
Jon_Cisco Member Posts: 1,772 ■■■■■■■■□□thank you. I will take a look at that link and see if I can get access to Visio. I downloaded the pdf file for all the reference images.
Have you worked on any network documentation projects in the past. It seems like a very important job function but when I do searches I don't come up with very many resources. Several people have pointed me to spiceworks for network mapping but I don't believe I will be allowed to run it on the network.
I assume I am either searching for the wrong information or there is a lack of resources for how to document networks. I am taking on this project as an informal internship and would like to produce professional results. It might be that the task seems to big so I am over thinking it. -
Jon_Cisco Member Posts: 1,772 ■■■■■■■■□□So in thinking about this a little more I think my first priority is collecting the data. Once I have data I can determine how to present it.
I have seen programs like angry ip scanner and fling that search the network for connections. Would this be a reasonable starting point.
My current though is:
1 - learn the locations
2 - learn the connections
3 - learn the address scheme
4 - determine the hosts
5 - possibly document the hosts (I am not sure how reasonable this is or if it is expected)
Again any feedback from members who have started a task like this from scratch would be greatly appreciated.
Jon -
Iristheangel Mod Posts: 4,133 ModI haven't documented for a small city by any means but at my previous job, I walked into the place and there was no existing documentation at all. Over the course of two years, I documented most of the network. I don't know if I did it by any industry standard way but I took a little of what I learned from the previous infrastructure architect and some of what I found online to merge it into my own documentation. I was very heavy on the Visio usage at that job
Depending on the site, I would create several diagrams:
-Physical diagram - Basically showed how every piece of network equipment was interconnected. Think of it as a layer 1 diagram. I would diagram the actual equipment models and how they were interconnected (port-to-port). I would also include a very basic description of how each port was configured on the links between devices. I'd usually squeeze a basic port matrix in there. They diagrams were usually the most helpful for the techs onsite installing the equipment.
-Tier 2/3 diagram - This was a high level diagram. It would show where each switch and router was located, how the IDFs were physically interconnected, the DNS name and IP address of the switches, switch models, which APs/cameras were connected to which IDF, where the IDFs were located, the IP scheme, DNS scheme, etc. This was most helpful for network administrators and network engineers troubleshooting when a site or part of a site went down.
-CCTV/WAP diagram - Usually built on floorplans. It would show the locations of the WAPS and CCTV Cameras and which IDFs they were connected back to. Pretty simple stuff. This was usually helpful when a camera or AP went down.
When I was done diagramming, I would create a sitepak. This was sort of my comprehensive documentation that would help any network admins or the service desk do basic troubleshooting. It would include the following:
-Address of the site
-Contacts for people onsite
-Physical layout of the location
-Network design
-IDF/MDF locations
-Site Inventory including serial numbers, model numbers, Smartnet contract numbers, etc
-Circuit types, speeds, LEC and circuit IDs, handoff type, media converters (if any), etc
-VLAN numbers and descriptions
- Security enhancements used
- Number of APs, SSIDs, model numbers, etc
- Any additional appliances or servers onsite and their uses
- Identified single points of failure, MTTR, risk, remediation
- Vendor list (wire vendors, appliance vendors, tech support, SPs, etc)
- Router and switch configs at the time of install - This part would usually change and I set everything up on Solarwinds to automatically back up the configs in NCM but I wanted to document the configuration before anyone touched anything.
At one point, I did try to look at various network topology mappers but I found they produced crappy diagrams and maps. I think they can be useful for scanning a subnet and coming back with a basic map and inventory but I'm yet to use one to build my diagrams completely off of.
Anyways, that's how I do it. I don't know if it's right or wrong but it certainly helped myself and others troubleshoot after the fact. -
Asif Dasl Member Posts: 2,116 ■■■■■■■■□□Great post by IrisTheAngel... My only advice regarding creating documentation is to use an A3 printer, it's MUCH better to get everything to fit and also keep things still readable..
-
Priston Member Posts: 999 ■■■■□□□□□□+1 for Visio, depending on how many devices you have in your network it might be hard to fit everything together on one drawing, you may have to have a drawing for each site and another drawing showing how all the sites connect. You can also be as detailed as you want and you can include port numbers, port channels, vlans, connection speeds/types using color coding.
Also instead of using just a generic router stencil, I might get the stencil of the actual model routerA.A.S. in Networking Technologies
A+, Network+, CCNA -
OfWolfAndMan Member Posts: 923 ■■■■□□□□□□Iristheangel has an excellent post. I'm not sure if this is exclusively the routing/switching side of the design or are you using IPTV/CCTV/WAPs/IP cameras? How does the hierarchy of your network look like? Where is your core layer, distribution and access layers? Are you using specially allocated subnets for certain things such as printers, VoIP phones, servers or any other special network devices? Where is your backup paths located, and what speed are they? GigE or TenGigE? How is your VLAN design looking? On your L3 switches, are you using L2 links or L3 links (Or maybe you're migrating a completely new design and require L2/L3 hybrid links?) Where is your edge located and are what type of BGP implementation (If any) are you using? Stub or multi-homed? Don't answer these questions obviously, but figure out them for your documentation. Not everything but just naming a few
Also, as Iris said, this will be a HUGE one in getting that physical hands on the equipment for inventory/on-site purposes. Get a POC for building custodians. It will realllllllllly help I promise.:study:Reading: Lab Books, Ansible Documentation, Python Cookbook 2018 Goals: More Ansible/Python work for Automation, IPSpace Automation Course [X], Build Jenkins Framework for Network Automation [] -
xnx Member Posts: 464 ■■■□□□□□□□Iristheangel wrote: »I haven't documented for a small city by any means but at my previous job, I walked into the place and there was no existing documentation at all. Over the course of two years, I documented most of the network. I don't know if I did it by any industry standard way but I took a little of what I learned from the previous infrastructure architect and some of what I found online to merge it into my own documentation. I was very heavy on the Visio usage at that job
Depending on the site, I would create several diagrams:
-Physical diagram - Basically showed how every piece of network equipment was interconnected. Think of it as a layer 1 diagram. I would diagram the actual equipment models and how they were interconnected (port-to-port). I would also include a very basic description of how each port was configured on the links between devices. I'd usually squeeze a basic port matrix in there. They diagrams were usually the most helpful for the techs onsite installing the equipment.
-Tier 2/3 diagram - This was a high level diagram. It would show where each switch and router was located, how the IDFs were physically interconnected, the DNS name and IP address of the switches, switch models, which APs/cameras were connected to which IDF, where the IDFs were located, the IP scheme, DNS scheme, etc. This was most helpful for network administrators and network engineers troubleshooting when a site or part of a site went down.
-CCTV/WAP diagram - Usually built on floorplans. It would show the locations of the WAPS and CCTV Cameras and which IDFs they were connected back to. Pretty simple stuff. This was usually helpful when a camera or AP went down.
When I was done diagramming, I would create a sitepak. This was sort of my comprehensive documentation that would help any network admins or the service desk do basic troubleshooting. It would include the following:
-Address of the site
-Contacts for people onsite
-Physical layout of the location
-Network design
-IDF/MDF locations
-Site Inventory including serial numbers, model numbers, Smartnet contract numbers, etc
-Circuit types, speeds, LEC and circuit IDs, handoff type, media converters (if any), etc
-VLAN numbers and descriptions
- Security enhancements used
- Number of APs, SSIDs, model numbers, etc
- Any additional appliances or servers onsite and their uses
- Identified single points of failure, MTTR, risk, remediation
- Vendor list (wire vendors, appliance vendors, tech support, SPs, etc)
- Router and switch configs at the time of install - This part would usually change and I set everything up on Solarwinds to automatically back up the configs in NCM but I wanted to document the configuration before anyone touched anything.
At one point, I did try to look at various network topology mappers but I found they produced crappy diagrams and maps. I think they can be useful for scanning a subnet and coming back with a basic map and inventory but I'm yet to use one to build my diagrams completely off of.
Anyways, that's how I do it. I don't know if it's right or wrong but it certainly helped myself and others troubleshoot after the fact.Getting There ...
Lab Equipment: Using Cisco CSRs and 4 Switches currently -
Iristheangel Mod Posts: 4,133 ModSurprisingly, the job was fun. Documenting isn't the fun part of the job but I definitely recommend hard wiring yourself to believe it's a necessity. If you speak to engineers working at VARs and ask them how many customers they see without documentation, it's going to be in the high numbers (75% or above in my experience). You can't enforce a standard or hand off a job you do effectively if you don't document it and I don't believe in gaining job security by keeping things to myself - that's a bad way to keep yourself relevant. Plus you have no way to prove you did it right or planned it right when you deployed it if you don't have the documentation to back it up.
-
Jon_Cisco Member Posts: 1,772 ■■■■■■■■□□Thank you for all of the responses. I am definitely going to print this post and use it as my starting point. I have a couple months to work on it so if I do a little a week it should slowly start to take shape. Visio is highly recommended so I will make sure I get access to it this year. I'm not sure it they have a copy onsite but I would bet they do.
My first step will be determining the number of locations and the connections between them.