In our previous blog “So You Think Your Network Is Standardized?”, we illustrated that merely establishing a Standard does not guarantee the network as truly standardized. In fact, we believe that many people have misinterpreted what a true Network Standard should be. In order to explain, we first need to define what a device’s Standard should include.

Do you think that a Standard is about only checking the Software’s version and Configuration? Many people or so-called Standard auditing tools do. However, there are at least two oversights here.

First, many people only check the main Software version, but there are many other components in a system that have their own firmware or hardware version and software patches that also need to be checked. For example, in a chassis based router there are supervisor modules, network modules, power modules, fan modules, etc. that all have their own firmware and hardware versions. Just like the main software, they all affect the reliability of your network and should be standardized and consistent throughout your network.

“They all affect the reliability of your network and should be standardized and consistent throughout your network.”

Second, we believe that a device’s Standard is anything you expect of how the device’s functions. Therefore, it should include more than just a Software version and Configuration, it should include Operation, Health, and Security. For example, if you have configured Network Time Protocol for clock synchronization, you would expect that the clock is synchronized with the NTP server. If you expect little packet drops in an interface, then you should check if it falls within the expectation. And if you expect that the file “/etc/passwd” permission to be read-only, then you should include it as part of your Standards. If you expect that the device can ping or traceroute to the syslog server via some particular path, it should be called out in the Standards. Basically, however you expect the device to behave should be put in your Standards.

As a side note, since a Standard cannot just check for some main software version, or whether some command in a configuration does or does not exist, most conventional configuration auditing tools are inadequate in handling a true Standard audit.

“…most conventional configuration auditing tools are inadequate in handling a true Standard audit.”

Let us elaborate, many times the Standard will ask for cross-referencing. For example, in a router you may need to compare if the BGP Router-ID is the same as the Loopback IP. Sometimes it will ask for cross-referencing between different devices, such as checking if both devices have the correct IP subnet configured on their shared link. Sometimes it will need a check something you only have partial information. For example, the Standard may demand that all of the OSPF interfaces have MD5 security enabled. However, you don’t even know how many or what the interface numbers are ahead of time. This particular case will require two steps, to first find out all the OSPF interface numbers, then check if MD5 is configured in each of them. Because of these sophisticated and dynamic requirements in a Standard, many conventional auditing tools cannot meet the job requirement.

In conclusion, a true Network Standard should include Software/Firmware/Hardware Versions of all components, Configuration, Operation, and Deep Health. This is essentially a checklist of how you expect the device to setup and function in a normal and healthy situation. Unfortunately the industry may be lacking a product family that is dedicated to true and thorough Network Standard and Quality Control.

Next we will broaden the scope to see what a true Network Standard requires in a Data Center.