|Novel Approaches to the Monitoring of Computer Networks|
|Prev||Chapter 2. Overview Of Network Monitoring||Next|
Although widely used, SNMP is not without its limitations [CMU, 2000]. The most widely implemented version of SNMP is SNMPv1, which lacks any form of authentication, relying instead on "security by obscurity". This limitation has caused many vendors to omit parts of the SNMP specification from their implementations in order to prevent access to critical network devices.
Wellens points out that SNMP is not particularly suited to the problem of fault management, but rather to that of performance monitoring — "Nearly 100% of network management occurs when networks are not failing." [Wellens, 1996] The article goes on to say that the value of SNMP as a tool for fault finding is somewhat below that of traceroute(8), ping(8), and nslookup(8). Unfortunately, there are very few, if any, network monitoring tools that utilise these simple building blocks.
Wellens also explains that the MIB definitions that have been produced for SNMP are SNMP's most valuable legacy [Wellens, 1996]. They comprise the collective thoughts of many experts on what exactly constitutes valuable data for network monitoring. These MIBs, however, are not without their own limitations, as shall be seen in Section 2.3.2.
SNMP is a polled system. It requires than monitoring stations actively poll devices for information. This can result in significantly increased network traffic if the polling frequency is not carefully monitored. Since SNMPv1 provides no inherent security, this can be difficult to achieve.
RMON was originally developed to overcome some of the limitations in SNMP, most notably the fact that SNMP agents can only store very limited amounts of information. This ability to store information reduces the necessary polling frequency which in turn should reduce the network load.
Since RMON is largely based on SNMP, it too will suffer from some of the limitations that have already discussed. RMON is not without limitations of its own though; not all RMON agents implement all parts of the protocol, so it is not always possible to retrieve the information one requires from a device using RMON. Using RMON requires a good knowledge of the network topology in order to place agents at the best possible positions to gather information.
Being able to successfully use methods such as SNMP and RMON requires that one has a good network monitoring package. These packages are usually produced by network vendors and are designed specifically to meet the needs of their devices. This problem of vendor-specific solutions is discussed in Section 2.3.2.
Network monitoring is of little use without accurate, up-to-date reports that allow network managers to make correct decisions. Unfortunately, fault reporting seems to be one of the field's weakest areas. Traditionally, fault reports are limited to the symptomatic reporting of the problem, with the network manager being left to interpret these symptoms — much like a doctor diagnoses ailments from a list of symptoms. This method works very well in a large number of cases, but breaks down in loosely structured organisations where the realm of responsibility is not delegated to one body. For example, being told that the departmental mail server has stopped working is not particularly useful if the underlying ailment is a faulty DNS server managed by a different organisational division. In cases like these, network monitoring software should be able differentiate between faults that are within the divisional realm of responsibility, and those that fall beyond it. This is something that symptomatic reporting does not cater for very well.
Modern computer networks require that thousands of different devices from hundreds of different manufacturers successfully communicate with each other. For this reason, standards have been developed to ensure that products from different manufacturers interoperate successfully. In the network monitoring world, standards such as MIB-II have been designed to provide an easy way for network management products to interoperate with the plethora of devices on the market. Unfortunately, technology often evolves faster than the standards that cater for it.
The SNMP MIB-II caters for this eventuality by providing the enterprises object identifier, where manufacturers can create their own, device specific, MIB trees. As technology advances, the gap between the standardised MIBs and the requirements of the technology increases. This results in more and more information about a device being stored under the enterprises OID, to the point where, when dealing with modern technologies such as Rate Adaptive Digital Subscriber Lines (RADSL), a vast majority of the management information about the device is only available through the enterprises OID.
Since the enterprises OID is not, by necessity, standardised, one ends up with a situation where products in the same class of device (e.g. router) from different manufacturers, either by coincidence or by choice, use different OIDs to represent the same information.
Network management tools using these enterprises MIBs are, in general, limited to working with devices from one vendor. The effect of this limitation is that, in order to fully manage a network using these tools, organisations are required to implement a homogeneous network — that is, a network where all network infrastructure and monitoring tools are sourced from a single vendor.
Unfortunately this is not always desirable or possible. Networks tend to grow in an ad-hoc fashion, depending on the demands of the users of that network. This is especially true of small organisations that do not have the resources to implement long term strategic plans. The result is usually a hetrogeneous collection of devices from different manufacturers.
Management of multi-vendor networks using SNMP has historically always been problematic. This divergence was the reason that MIB-II was initially standardised [RFC 1213]. The problem can only get worse as network technologies diverge more and more from the "norms" that underly MIB-II.
This problem is compounded by the use of proprietary protocols as already described in Section 2.2.5.