If you've been in network administration for any length of time, you've no doubt seen a disaster or two like these:


Luis Guevera submitted this to our What's Hiding in Your Closet contest.

Daniel Parmelee submitted this to our What's Hiding in Your Closet contest.


The desire to have a neatly ordered network closet is known and shared widely. But effective network organization is more than just neat stacks and tightly bundled cables in physical space. Is there a logic to your network structure? Even if you are just adding devices as you need them or are allowed to buy them, you need to impose some sort of order on your network.


Get your Network Organized

Getting your network organized is especially important as you start to consider trying to determine what is happening on your network. That's right, network organization is part of effective network monitoring. Of course it is.


Here at SolarWinds, we approach logical network organization with three basic concepts: custom properties, groups, and dependencies.


Custom Properties

Custom properties are simply properties that you define and use in accordance with your own specific needs, such as country, building, asset tag, or serial number. These properties are not necessarily available in the MIB, so they are not updated via SNMP polling. In physical space, you can think of custom properties as informative labels you can directly stick to your network devices. With a Network Management Software (NMS) that uses a database, like SolarWinds NPM, custom properties are simply additional fields in your database that then allow you to sort and report as you need.


For example, if it is your IT practice to label each network device with a company ID, you would want to think of that company ID as a custom property for searching, sorting, and reporting with your NMS.


Groups are a logical extension of custom properties in that they give you that ability to logically organize individual network objects into groups that you can then manipulate as larger monitored network objects, regardless of device type or location. You already, naturally, think of your network in terms of groups of devices.


You might want to push a particular update out to all users of a particular OS. If you've defined a group based on OS, you could simply select the group and push your update to all users in the defined group. It's obviously a lot easier to select a single group object to update than it would be to select all the individual members of that group.



Dependencies allow you to more faithfully represent what can actually be known about your network. In any network, there are some devices that are functionally dependent on other devices. Accounting for the functional dependencies that exist on your network will improve both the effectiveness and the efficiency of your network monitoring over the long haul.


As an example, if your network is set up in such a way that packets leaving a wireless router "W" cannot reach the server hosting your NMS without passing through switch "S", you will only ever know the status of wireless router "W" if switch "S" is operationally up. The problem is that wireless router "W" will appear operationally down if switch "S" is actually down, simply because, if switch "S" is down, it's impossible for packets to get from wireless router "W" to your NMS. The link at switch "S" is broken. It's likely that you'd have an alert configured to fire on all down objects. In this situation, you'd get a false positive down alert on wireless router "W" simply because your NMS wouldn't know any better. Documenting dependencies, and using them to better configure your network monitoring profile can eliminate a lot of false positive alert triggers and give you more accurate insight into the state of your network.


For more information about custom properties in SolarWinds NPM, see the chapter, "Creating Custom Properties", in the SolarWinds Orion NPM Administrator Guide. For more information about groups and dependencies in SolarWinds NPM network monitor, see the Solarwinds technical reference, "Using Orion Groups and Dependencies".