To be managed, a network element must offer a management interface through which a managing system can communicate with the network element for management purposes. For example, the management interface allows the managing system to send a request to the network element. This could be, for example, a request to configure a subinterface, to retrieve statistical data about the utilization of a port, or to obtain information about the status of a connection. Likewise, the network element can send information to the managing system, such as a response to a request, but also unsolicited information, such as when an unexpected event (for example, the failure of a fan or a buffer overflow) has occurred. Accordingly, during network management, management communication occurs.
Management communication is inherently asymmetrical: A managing application plays the role of a "manager" in charge of the management, and the network element plays the role of the "agent" that supports the manager by responding to its requests and notifying it proactively of unexpected events (see Figure 3-2).
Figure 3-2 Manager-Agent Communication
Managing — System
Manager and agent are important terms in network management parlance; they refer to the systems that manage (manager) and the systems that are managed (agent). Client/server is another well-known asymmetric communication relationship that the reader might already be familiar with; therefore, a few words on the relationship between manager/agent and client/server are in order. As shown in Figure 3-2, the agent corresponds to a server, and the manager to a client. Of course, client/server-based systems typically imply that a small number of servers must service a large number of clients. For example, one bank transaction system (server) must serve thousands of ATMs and bank terminals (clients), as well as hundreds of thousands of online users. In network management, the situation is reversed, as depicted in Figure 3-3; typically, large numbers (perhaps tens of thousands) of servers—that is, agents—serve a small number of clients—that is, managers.
Figure 3-3 Manager/Agent Versus Client/Server
Network elements must provide a piece of software that implements the management interface. This software effectively provides the intermediary between external manager and managed device. We refer to this software generally as the management agent. In fact, this means that we are slightly overloading the term agent. Agent is used to refer both to the agent role that a network element plays in network management and to the software component, called the management agent, that allows the network element to play that role, that provides the management interface, and that represents the managed device to the manager. In general, the meaning of the term should be clear from the context in which it is used. For the remainder of this section, the term agent refers to the management agent, not the agent role.
The management agent conceptually consists of three main parts: a management interface, a Management Information Base, and the core agent logic. All three are explained here:
■ The management interface handles management communication.
The management interface supports a management protocol that defines the "rules of conversation" for communication between the managed network element, as represented by the management agent, and the managing application. It allows the managing application to open (and tear down) a management session with the network element. It also allows managing applications to make management requests to the network element and receive responses. Many types of management requests are conceivable—for example, requests to retrieve a piece of statistical information such as the network element's current utilization, or requests to change a configuration setting, such as the size of a buffer allocated to a particular port. Through the management interface, the management agent can also send unsolicited event messages that the managing application can receive. Event messages enable the manager to be alerted of certain occurrences at the network element, such as the unexpected loss of communication with another network element.
■ The Management Information Base (MIB) is a conceptual data store that contains a management view of the device being managed. The conceptual data contained in this data store constitutes the management information.
Management operations are directed against this conceptual view. For example, the network ports of a network element could be represented as a table in an imaginary database, with each port having a corresponding entry in the table. Columns in the table contain conceptual attributes that refer to actual properties of the port. Examples of such attributes are the type of communication protocol supported by the port and the number of packets that have been transmitted.
The MIB should not be confused with a real database. It is a way to view the device itself, not a database in which information about the device is stored. This view is a proxy for the network element that is being managed, which is an actual device that is a part of the real world. For example, when a managing application modifies an entry in the conceptual table, in reality, the actual configuration of the network element is changed and the communication behavior of the network element is impacted.
Management information in a MIB does not necessarily always have to resemble a conceptual table. Alternative representations include Extended Markup Language (XML) documents or even simply a set of command-line parameters. It all depends on the management agent.
■ The core agent logic translates between the operation of the management interface, the MIB, and the actual device. For example, it translates the request to "retrieve a counter" into an internal operation that reads out a device hardware register that contains the desired information. In fact, many counters of the same type might exist inside the network element— for example, one per communications interface. Therefore, the agent logic must be capable of mapping the name by which the counter is referred to in the MIB to the actual register whose contents are being requested.
In addition to those core functions, agent logic can include added management functions that offload the processing required by management applications. In marketing jargon, those functions are often referred to as "embedded management intelligence." A typical example is the capability to pre-correlate raw events before they are sent out so that the management application does not need to sift through a large volume of events that turn out to be irrelevant because they are all symptoms related to the same root cause. Another example is a function that allows an application to schedule a periodic test function to validate proper functioning of the device instead of needing to send a new test request each time.
Figure 3-4 illustrates the components of a management agent and how the management agent interacts with the managing system and the underlying device that it represents.
Figure 3-4 Anatomy of a Management Agent
Managing System "Manager"
Managing System "Manager"
Although a network element plays only one agent role, it can actually contain several management agents, each with its own management interface. Just as different views can be defined on the same underlying database, each management agent can offer its own MIB that is its own abstraction of the underlying network element. A network element can provide different management agents for a number of reasons. One common reason is to give management applications a choice of management interfaces. Another reason is that the different management agents might each serve different functions. For example, one management agent might be dedicated to reporting performance statistics through a special interface that is tuned for that particular purpose, whereas another management agent might be dedicated to configuring a device, offering a different kind of interface for that purpose.
We talk extensively about management interfaces and the details of management communications in Chapters 7, "Management Communication Patterns: Rules of Conversation," and 8, "Common Management Protocols: Languages of Management." For now, let us continue by focusing on the aspect of management information.
Was this article helpful?