It's confusing and sometimes overwhelming. Learn about common misconceptions about network and system management software and the distortions that software vendors promote when it comes to marketing their product's features.
Top Ten Network Management Lies and Deceptions A free vendor-agnostic whitepaper courtesy of PerformanceIT, Inc.
#1 Simple Network Management Protocol (SNMP) is Simple This ranks as the number one deception in the industry. SNMP is by no means simple for even a seasoned network engineer. In theory, it is a simple protocol that governs how management data is retrieved and processed from network devices by a Network Management System (NMS) and how network devices send management information back to an NMS. Getting useful and meaningful data for your NMS via SNMP is the real challenge and is where most vendors distort their capabilities and deceive their potential clients. Most network management vendors claim to be SNMP-capable. What they don't tell you is that what they really offer is simple SNMP GET requests which ask a network device to return the current value of a specific object identifier (OID) such as "packets IN." This simplistic polling yields data such as "packets in = 5,992." What can you do with this information? Not much, of course. A true NMS assembles appropriate OID values into meaningful statistics such as "Bandwidth Utilization." Most vendors won't be honest and explain their SNMP limitations accurately. The statistic Bandwidth Utilization is not a single OID object, as many vendors will have you believe. The actual statistic is created by using the formula: ((IN pkts in Octets + OUT pkts in Octets) * 8) /1024. There are two OIDs with appropriate mathematics built-in. Many vendors will say they can provide statistics like Bandwidth Utilization, but in truth, they leave it up to you to figure out which OIDs you need, and then how to perform the appropriate mathematics. Be sure to see this functionality demonstrated. Further, ask your vendor to provide vendor-specific statistics that are important in your infrastructure. If you don't know what is important, it may be that you never implement this powerful monitoring capability. Unless you are a programmer or SNMP expert, be sure to look for an NMS that has the statistics you are looking for built-in. The difference between SNMP polling and SNMP monitoring is as follows: SNMP polling means that a network management station (NMS) polls (sends SNMP GET requests) to the remote device. In other words, it asks the device for information and the device responds with a value. SNMP monitoring means that the network device is configured to send SNMP traps (messages) to an NMS without a specific request. Again, the problem is, as with most network monitoring information, there may be many, many trap messages and they are usually cryptic in raw form. Example Raw SNMP Trap: "9/13/2002 9:39:8 : grtse38;grtse38;enterprises.16.1.1.200;6;.9002; enterprises.16.1.1.200.1001.0 = 0 enterprises.16.1.1.200.1003.0 = 0 enterprises.16.1.1.200.1004.0 = 1 enterprises.16.1.1.200.1005.0 = "ONLINE" enterprises.16.1.1.200.1006.0 = "FAILED" This message, by itself, does not produce the useful information that is actionable by the network administrator. The network management product must accept this message, simultaneously link its contents to a Management Information Base (MIB) definition file, then convert it to a useful message such as "Server1 PowerSupply 1 FAILED." To say that you can monitor SNMP traps without doing MIB lookups and message conversion wouldn't qualify as a feature for most users. Further, you may also desire specific integration with some of the most common and useful SNMP trap producers such as Compaq (HP) Insight Manager, Dell OpenManage, and IBM Director.
Top Ten Network Management Lies, Copyright 2003, PerformanceIT, Inc #2 Root Cause Analysis This "feature" means different things to different vendors and places #2 on our list. Delivering true root cause analysis means that your NMS can filter through hundreds (or thousands) of events and point you directly to the root cause of either an outage or performance degrading event, a very tall order. To separate fact from fiction in this area, we generally like to separate monitoring capabilities into three categories: Component Monitoring, Transaction Monitoring, and Event Correlation. True Component Monitoring means that your NMS is capable of three distinct capabilities: 1. Monitoring all of the individual components ("moving parts") of your application across all of the devices and software on which it depends; 2. Be able to understand and group t... [download for more]
