Management by delegation involves an upper-layer management system delegating certain tasks to lower-layer systems—in some cases, the managed systems themselves. This is a very common theme that can be found across the various management functional areas. In many cases, tasks suitable for delegating are routine tasks that do not require interaction with a management operator or administrator. They involve a relatively low level of intelligence but often require sifting through a large amount of management data. Therefore, delegation of such tasks significantly offloads upper-layer systems. Here are some examples:
■ Logging of events—Two tasks are delegated to subordinate systems: the task of persisting events and the task of filtering out events that are of no interest to the application. The latter can take the shape of the subordinate system offering an event-subscription service. This service allows upper-layer systems to subscribe only to those events that they are interested in as defined by a set of criteria. Examples include events of a certain type, alarms of a certain severity, events affecting a certain system, and events that meet some combination of those criteria. The subordinate system inspects incoming events and forwards only those events that meet the criteria.
■ Deduplication of events—The task of identifying event messages that are being sent redundantly and suppressing the duplicates is delegated to the subordinate system. This can be particularly useful if events are deduplicated across multiple systems. Compare this to an accident on a highway, which could trigger many people to make 911 calls, putting additional load on the system. Deduplication ensures that only one 911 call is put through, which, in turn, ensures maximum responsiveness and dedication of resources to that one call.
■ Correlation of events—Beyond deduplication, this involves delegating the task of correlating events in general, to reduce as much as possible the amount of "noise" that the upper-layer system needs to deal with.
■ Netflow collection and aggregation—The task of collecting and logging Netflow records is typically delegated to a system known as a Netflow collector. This is a special-purpose system designed for this particular task. In addition, it might be useful to delegate additional tasks to the collector, such as aggregating data across Netflow records.
■ Polling of devices for statistics—A management application might be interested in receiving snapshots of current statistical parameters at certain points in time, such as the current CPU utilization, to plot performance graphs and perform offline trend analysis. Polling imposes a substantial load on management applications, particularly if they have to poll many devices across the network. This is a task that can be easily delegated.
■ Preprocessing of statistical information—Converting counters that aggregate data over a long period of time into discrete values to indicate the current rate is another example of a simple task that can easily be delegated and performed in conjunction with polling devices for statistics. For example, a counter that counts the packets received on an interface since the system was first started up can be converted into values that indicate how many packets were received in each time interval. The number of packets is determined by subtracting the value at the beginning of the interval from the value at the end of the interval to record by how much the counter was incremented during the time interval. Note that this provides a rough estimate only because the points in time at which a sample is taken might not always be evenly spaced. This is because of fluctuations in the time that it takes a request for statistical information to be processed by the device, as was explained earlier.
■ Correlation of call detail records across the network—This is an example taken from telephony. Phone calls made across the network result in so-called call detail records (CDRs) that are generated during the call. A CDR includes information such as when the call was started, when it ended, how much data was transmitted, and so on—much like flow data in Netflow or IPFIX. This data is the basis for billing users. Because several systems that are involved in a call can generate a CDR, CDRs that relate to the same call need to be eliminated to avoid double counting. This occurs by matching CDRs that contain the same call identifier, meaning that they relate to the same call that was made. This is another task that is simple enough yet requires a good deal of number crunching—a prime candidate for delegation to a subordinate system.
■ Autoconfiguration backups—A subordinate system might be tasked with taking periodic snapshots of device configurations and backing them up, in case corruption occurs and they need to be restored.
■ Value-added configuration management functions—These could include scoping configuration retrieval across the network. Here, a superior system would really like to be provided with a convenience function that allows it (for example) to retrieve configuration information across a group of devices or an entire network domain through a single request. The task of dividing this into individual requests and collecting the responses is delegated to the subordinate system.
■ Distribution of software patches across the network—In this example, an image upgrade might need to be distributed across the network. This task can be delegated to a subordinate server to which devices inside the network are pointed to retrieve their new image. Alternatively to this "pull" model of devices pulling their own images, the server might also realize a "push" model, uploading the new images to the devices.
Some tasks that can be delegated to a subordinate system are not suited for delegation to the network elements themselves. This concerns particularly tasks that involve coordinating multiple devices, such as the CDR correlation across the network or the scoped configuration retrieval. However, many tasks can be delegated either to a dedicated subordinate system or to a network element. In some cases, some network elements offer a function, whereas others do not. In those cases, subordinate systems can act as "equalizers," providing external "intelligent" agents for devices that are otherwise more limited in their functionality, as shown in Figure 9-7. In those cases, the subordinate system acts de facto as a management gateway, offering a set of higher-level functionality at the interface that it exposes in its agent role and mapping this to more primitive capabilities offered by the managed system below. We get back to the subject of management gateways in the next section.
Figure 9-7 A Subordinate Management Helper System as Equalizer
Figure 9-7 A Subordinate Management Helper System as Equalizer
Functions such as those just described are offered in many forms. Sometimes they come as their own full-fledged products. Sometimes they simply come as a feature or embedded capability of the managed device. One well-known technology that implements management by delegation is called RMON, for remote monitoring MIB. RMON is basically a special SNMP MIB that enables managers to delegate certain management tasks to so-called RMON probes. The probe can be a system in its own right, such as a management appliance, or it can simply reside on the device (see Figure 9-8).
The types of tasks that can be delegated to an RMON probe include collecting statistics (taking snapshots of MIB variables at certain intervals in time), subscribing to certain types of notifications, and generating threshold-crossing alerts. (This last capability is also a prime example of a function to enable management by exception, explained later in this section.) Tasks are delegated by configuring the MIB accordingly. Over time, several MIBs related to RMON have been introduced to expand the functionality that was originally defined.
Figure 9-8 Management Using RMON Probes
RMON probe (SNMP agent)
RMON probe (SNMP agent)
RMON other MIR MIRs
Finally, it should be mentioned that ultimately it might be desirable to have management by delegation occur by allowing an upper-layer management system to delegate tasks "on the fly"— for example, to generate management scripts for execution by lower-layer applications when needed. Although this is potentially very powerful, such concepts have not really moved past the research stage. The concept is promising, but it raises many issues that need to be addressed. For example, from a security standpoint, it needs to be ensured that the delegated task indeed originates from an authorized system. Also, because the behavior of the network with regard to management can be altered on the fly, extra care needs to be taken that the delegated tasks have the intended effect and don't spin out of control and wreak havoc on the network. Debugging and troubleshooting a network can become significantly more complicated.
Was this article helpful?