Network documentation is a very complex and thorough topic - there are many guidelines, theories and even books that can help us with the process of creating and maintaining proper documents describing the network. The concept and execution may vary, but the purpose of the documentation should be unique - to represent the current state and settings of the network and all of the respective components. Let’s skip the document’s life cycle stages, like where to store the documents, how long the information should be stored for, how to track the changes etc., as there is much to cover on this topic. What is most important, is knowing what to document from a networking point of view, and how to represent the data.
Ideally, the network documentation should enable reconstructing the network from scratch. In case a change is being planned, state information is necessary to plan the change correctly. In the event that the active network device goes down due to an unforeseen event, it is crucial that the network can be reverted to its previous state. And if elements of a new network should incorporate elements from the network, being able to accurately document the corresponding detail levels is particularly important.
It goes without saying that the network engineer should be able to understand the documentation corresponding to their network without unnecessary complications. Being able to fetch the device list, understanding how they are interconnected and configured, and being able to verify all of this information is essential. Although the structure of the individual documents may vary, the common approach should be adhered to – describing the network based on the Open Systems Interconnection (OSI) model.
This chapter should cover the device list, including the hardware modules, the software versions, applied patches and other hardware/software details. Documenting the device location, rack plan and physical access details is optional. The core of this section is to document the physical cabling – interface names, transceiver and cable types. IP Fabric provides all information under the Inventory section – Device list, OS versions, List of interfaces with many details.
1 - Device Inventory
The second OSI layer describes the logical rather than physical connections. It means that segmentation can follow the physical cabling but it can extend the connection by using Virtual-LANs (VLANs), the port aggregation (EtherChannel, Port-Channel, Aggregated interfaces), different types of Spanning-Tree (STP) or use proprietary concept like Fabric Path etc. All this information are important to be able to understand how the network is functional from the logical point of view. If desired, it may document the logical settings of the devices like stacks - Virtual Switching System or Stack-Wise Virtual, VDC or vPC. The format of the documented data has to be carefully considered - there are plenty of methods such as network diagrams, tables, lists or configuration snippets.
IP Fabric collects lot of details and all the data are presented in a standardized and comprehensible way. Network diagram (per site) is showing protocol-level connections and technology section provides table overview of L2 specific topics.
2 - Network L1/L2/L3 diagram
Describing the network layer should be the most critical and most extensive aspect of the network documentation, as it should cover the elements such as:
IP addressing is a subject of a separate document and specific IP Address Management (IPAM) tool may be used (free or paid) - it should cover all the network subnets configured within the network. It depends on the capabilities of the IPAM to store all the details, but from the best practice approach it should list the network subnet, the configured IP address, device and interface name. Ideally, IPAM should track the history of the changes to see when and what changes have occurred. However, most of the tools available on the market require manual database maintenance.
Routing can be simplified using few static routes within one flat routing domain, but also can be very complex and structured by using several dynamic routing protocols like EIGRP, OSPF or BGP with complex redistribution on several places within the routing domain. Therefore, it should be documented to an appropriate detail level to in order to provide network behavior insight, and enable the possibility of building the website from network documentation alone.
IP Fabric excels in this area by collecting all the data mentioned above automatically, and more; IP addresses are listed in Managed IP overview and any IP can be verified against the device/interface name, including DNS name or other few additional settings. It can be also used as an initial input to the IPAM tool - just to export all the data to the CSV format and import the values to the IPAM. Collecting the list of IP addresses and IP networks is not the core of the IP addressing management - that’s only a list of values that are being used across the whole network. That said, proper comprehension and routine updates will serve the IPAM as needed.
The fourth layer of OSI model helps securing the traffic. The control plane security means securing the data needed to establish the network functionality - routing protocols, FHRP, device management etc. It should be covered in the appropriate part based on the control protocol, e.g. securing the dynamic routing protocol or FHRP should be covered in the previous chapter, securing the device management in the chapter covering the accessing the device (Telnet, SSH, SNMP) and so on.
Data plane filtering is the core of this section - it refers to the core concept of how the production data (user data) is being filtered, and should be documented first; it can then extend to the details and provide a very detailed view of the individual access-lists statements. Another concern is, how far need you dig into the details? It depends on the complexity of the implementation as well as the corresponding security policies that can limit the amount of information that may be presented.
IP Fabric provides a coherent Access-List (ACL) overview, which also serves the ability to check the A-B path verification for specific traffic. Just enter the source and destination IP address in the network, then the traffic type - Internet Control Message Protocol (ICMP) or TCP/UDP and source/destination port in the second case.
3 - Vieving Access-Lists in the tolopolgy
The application layer is often excluded from the network documentation, but the process is changing and applications are more and more often a focal point of the new network principles and approaches. For this article and this chapter especially, the application layer description should include all the application we need to control, manage and monitor the network. Standard tools for device management are still Telnet/SSH with some corporate identity management (TACACS or Radius), and specific tools based on GUI front-end are more popular nowadays.
The network documentation process should incorporate the previous examples, but not be limited to them. There are many technologies, concepts, and network functions and it is very difficult to maintain an up-to-date overview of all such documents, especially when it comes to vast enterprise networks. Therefore, automating the process of collecting network data and subsequently creating the corresponding documents has proven to be a substantial advantage. IP Fabric eliminates the need for manual low-level design documentation; IP Fabric provides a detailed network overview for each business location, including topology visualization. Automatically generated, always available & up-to-date.
If you’re interested in learning more about how IP Fabric’s platform can help you with analytics or intended network behavior reporting, contact us through our website, request a demo, follow this blog or sign up for our webinars.