PDF

Documenting Your Network

A description of how your network is actually put together — topology, addressing, grouping and dependencies — assembled by the monitoring rather than maintained by hand.

Network documentation has a habit of being accurate on the day it is written and slowly false afterwards. The diagram lives in one place, the address plan in another, and the person who knew why a link was there has moved on.

NetCrunch approaches this from the other end. To monitor a network it has to discover how that network is arranged, and that understanding is kept, drawn and updated as a side effect of monitoring. What you get is a description of the network as it is now, not as someone last recorded it.

This is the companion to NetCrunch as an Inventory Database. Inventory answers what each thing is — hardware, software, versions. This answers how the things are arranged — what connects to what, what sits where, and what depends on what.

nd-topology

The Map Draws Itself

Two layers of topology are discovered and maintained without anyone drawing them:

Routing maps
The logical picture — which IP networks exist and which routers join them.
Physical connection maps
The layer 2 picture — which device is plugged into which switch port, with a per-switch view showing the traffic on each port.

Both are covered in Network Topology Maps, including how to enable physical segment monitoring and what to do when a device is missing from a map.

nd-organization

The Organization Is Discovered Too

Beyond the wiring, the atlas records how the estate is divided up — and most of those divisions maintain themselves from monitored data rather than from a list somebody edits:

  • Device Groups and Server Types — printers, switches, wireless, Linux, Windows Server
  • Locations — from SNMP location data or entered by hand
  • VLANs and Windows Domains
  • Organizations, for estates serving more than one
  • Virtual Machine Hosts, with their guests beneath them

These are dynamic views: a node that changes role moves group on its own. See Network Atlas Views.

Where the Same Address Means Two Different Places

Estates that run the same private range in more than one location are exactly where hand-kept documentation falls apart. NetCrunch handles it with network sites — separate address spaces, so 192.168.1.10 in one branch is not confused with 192.168.1.10 in another. The site is part of how a node is identified rather than an annotation on it.

nd-dependencies

What Depends on What

The most useful thing about a network description is usually not the list of parts — it is knowing what goes dark when one of them fails.

NetCrunch records dependencies from what it already knows: the route to a node, the virtualization host underneath it, and the layer 2 connections it discovered. That is what lets it report the failed router rather than the two hundred nodes behind it.

Where the dependency is a business one rather than a network one, you describe it yourself with a composite status, and NetCrunch draws the result. See Composite Status and Business Service Views.

nd-your-knowledge

The Part Only You Know

Discovery cannot find who owns a server, which contract covers it, or why a link exists. Two features hold that:

Custom fields
Number, text, date, time or pick list, added to the node record. Because views can filter on them, "everything owned by Finance" becomes a view that maintains itself. See Managing Node Custom Data.
Notes
Free text against a node, for the reasoning that does not fit a field.

Device classification sits between the two — mostly discovered, correctable by hand, and worth correcting because so much else follows from it. See Device Identification Manager.

nd-boundaries

What This Does Not Cover

  • It documents what it monitors. Anything NetCrunch has never seen is not described, so coverage of the documentation is coverage of the monitoring.
  • It records what is, not what was intended. The maps show the network as discovered. A link that should not be there is drawn exactly like one that should.
  • It is not a design tool. There is no planned-state diagram to compare the discovered one against.

address spaceas-builtcustom fieldsdependenciesdevice typedocumentationdynamic viewsinfrastructurelayer 2network documentationnetwork sitesnotesphysical connectionsrouting maptopology