Documenting a Network 101

by | Jun 18, 2018 | Infrastructure | 0 comments

Everything is a learning process … for those who have time

If you’re like a lot of network admins these days, finding time to document a network can be difficult.  There are number of automated network diagramming tools out on the market today, but they can be fairly expensive and the cost might not be in your budget.  That leaves the next best thing: you!  I would argue that documenting your own network by hand is generally the better way to go.  There’s no better way to learn a network (and find surprising things you didn’t know about) than to do it yourself.

Tools right at your fingertips

There are a number of protocols to help you with your discovery of your network.  Some of these may need to be turned on or configured, since they might not be enabled right out of the box.  Examples include: Cisco Discovery Protocol (CDP), Link Layer Discovery Protocol (LLDP), and Simple Network Management Protocol (SNMP).  SNMP is good for finding devices via ping sweep tools like Solarwinds IP Address tracker, but it requires community strings to be configured, etc.  Others are already there for you to peruse at your leisure since they are required for normal network operations, such as routing protocols, ARP and MAC address tables.

Generally speaking, on Cisco switches, CDP is enabled by default, but you have to turn LLDP on via the “LLDP run” global command.  HP switches will receive CDP updates but they will not transmit them.  LLDP is also turned on by default.  These layer 2 discovery protocols will exchange messages between directly connected devices to let each build a table of what is directly attached.  LLDP is even a requirement for PoE+ devices.  You can use the data that the switches discover to help you paint a picture of how your network is interconnected.  The information that is revealed in the CDP or LLDP table will tell you about network device: names, management IPs, ports involved, system information, etc.

DISCLAIMER – I generally recommend disabling these protocols on perimeter facing equipment due to the security implications.  Internally, SNMP should be secured with ACLs allowing only your management station the ability to access.

Routing protocols, static routes, and ARP / MAC tables will allow you to dig further into the network, and getting information about non-LLDP/CDP devices.  Using a combination of ARP and MAC tables on a layer 3 switch, can help you track down where devices are plugged into, or even assist in figuring out if an IP is just not responding to ICMP messages from a ping sweep tool.  This is really useful for finding out where perimeter firewalls are plugged into; simply find the ARP entry of the next hop IP on the default route (likely your firewall), and compare that to the MAC address table.  This will tell you the switchport that the firewall plugs into, or at least the next switch to check if it is another switch hop away.

CoreSwitch#sh ip route


Gateway of last resort is to network

S* [1/0] via

CoreSwitch#sh arp | i

Internet            0   aaaa.bbbb.cccc  ARPA   Vlan1

CoreSwitch#sh mac address-table address aaaa.bbbb.cccc

Unicast Entries

vlan     mac address     type        protocols               port


1      aaaa.bbbb.cccc   dynamic ip,ipx,assigned,other Port-channel1

Putting it all together

When you are finally done gathering information, you can take all of your network notations (or in my case chicken scratch from my trusty notepad) and use a program like Microsoft Visio or one of the many other diagramming alternatives, to put it all into electronic format.  I like to put information about various components in multiple tabs so as to keep information separation logical.  For example, perimeter types of devices like external facing switches, routers and firewalls would go in one tab, and internal switches, routers, APs and firewalls in another.  Whatever information you want to include in these diagrams can vary over time and complexity.  When you first start diagramming your network, you might not include port numbers, or model #s, but only hostnames and IP addresses and add other information at a later time.  It’s completely up to you as any documentation is better than no documentation.

Throughout the whole process, you will gain a better understanding of your network and you might even see some bottlenecks or other items to be improved upon.  At the very least, it will assist you in troubleshooting any problems and will give you another tool for use in day to day operations.

If you need assistance with documenting your existing network or improving your network design, Peters & Associates can help!  Email to find out more.