What are the most important things to include in your network documentation and reporting?

From a security perspective, if we don’t have an accurate inventory, we cannot possibly have good security! In addition to physical and logical mappings, include data flows and business logic/processes. Also: identify the components that support mission critical apps and services

In my opinion, Inventory is one of best starting points for continuing a project or starting a new one. Depending of your situation, you must prepare for thinking in build, maintain, troubleshoot and feed others systems in your company. And it depends how you build your items. Structure your data and defining names with acronyms could be a good practice for a proper data normalization and exploration. It could be the root for many initiatives such as automation, monitoring, compliance and much more uses cases.

The document includes the Network inventory for troubleshooting or maintenance, Disaster recovery plan, SLA (vendor or service provider), and user documentation.

I have found it very helpful to have a diagram of the network along with links to ip schemas, traffic flows, configuration files, port matrix and a RACI chart of owners of the specific portions of the network. These items lend themselves to supporting an accurate inventory. Also, any documentation is not static. It is a living document.

Keeping a network inventory is imperative when it comes to maintaining your network. It's also a must for you to properly budget and project future network device refreshes. We use Cisco Prime and SolarWinds for our inventory tracking.

In my opinion, the network topologies are the must have document whether you are building a new connectivity or troubleshooting an exist network. Unless the engineer is not able to visualize the end-to-end traffic flow , it is very difficult to troubleshoot and isolate the issue. During the deployment, the network topologies come handy to identify which firewalls or load balancers also do need an update. During a hardware failure , the topologies save the day an Frye work to trace the cables.

In my experience I have found that including a network topology is beyond helpful when it comes time to things like understanding how devices are connected and/or how traffic for a network segment egresses said network. It's also very helpful to have a visual representation of how the network is connected to help save time come troubleshooting.

Although network topology diagram varies according to the targeted audience however it should encompass network resources, both available and utilized, so it visualizes how scalable the network is, where there's possible network congestion due to lack of resources and where upgrades need to be implemented.

One thing I've found helpful is understanding your network performance and usage. This is good to know for if/when you receive reports of slow connectivity for users because it could be caused by a single user or service taking up all the bandwidth during regular hours when something like backups or updates are occurring at the "wrong" times. SolarWinds has some great tools to help monitor these metrics.

Keeping track of network issues and resolutions is very helpful in the long run when you face the same issue more than once because it can help find possible historical trends. We use Service Now for our ticketing system which helps us dissect the history of a site, device and/or potentially tending issue. Work smarter not harder. No sense in reinventing the wheel. Instead review your records and see if they point to the issue. If not, it could point you in the right direction of where to start investigating.

Keeping a knowledge base of common problems and solutions is a valuable tool. Be sure these get reviewed and updated over time for accuracy and effectiveness

Documenting changes done in the network is a vital process that every network engineers should consider. Especially in some org structures where operations and projects are segregated. A common repository of these documented changes helps the operations easily identify is an outage is caused by someone implementing a project. It can also serve as a tool for collaboration between these parties. In addition, proper communication between operation and project teams is also fairly important to avoid conflicts.

Leveraging a configuration management database (CMDB) can link the change management process, enable automations, enable better troubleshooting, and compliance!

1. There should be low-level design (LLD) documemt created that can provide complete details about the network. IP Schema, VLAN ID details, excluded IP addresses range, DHCP pool details, ACLs, network security policies created on firewalls, site to site vpn details, remote access vpn details should be documented. 2. We can use network monitoring system such as solarwinds, Cisco Prime Infrastructure, Manage Engine that can report any network anomalies.

Apart from the as-built, having a consistent version control and up to date info reflected in the doco is crucial. Outdated diagrams, incorrect IPAM database vs doco are commonly seen in a lot of environments that posed difficulties for troubleshooting.

One thing I am sure is missing which is network security. What are security measures, network security polices must be included in documentation.

All of these seem to be in terms of understanding what the state of the network is. I think listing what goals you are trying to achieve (in terms of security and performance mostly), how well they are being achieved, and a plan to continue maintaining those invariants (or a remediation plan if they aren't currently being achieved) would be more useful to transmit to management.

in my experience, the network design should be documented in Hight high-level Document What is HLD document consists of data flows, flowcharts, and data structures to help developers and Engineers understand and implement how the current system is being designed intentionally to function. - Secondly, Low-level Design Document LLD, which is detail describes the design in a technical way of all the deployed protocols in networking LLD has enough detail to guide the technical engineers through the network configuration and coding phase without ambiguity.