The agent is a software function embedded in most networked devices, such as routers, switches, managed hubs, printers, and servers. It is responsible for processing SNMP requests from the manager. It is also responsible for the execution of routines that maintain variables as defined in the various supported MIBs.

Interaction between the manager and the agent is facilitated by the Simple Network Management Protocol (SNMP). The term simple comes from the restricted number of message types that are part of the initial protocol specification. The strategy was designed to make it easier for developers to build management capabilities into network devices. The initial protocol specification is referred to as SNMPv1 (version 1).

There are three types of SNMP messages issued on behalf of an NMS. They are GetRequest, GetNextRequest and SetRequest. All three messages are acknowledged by the agent in the form of a GetResponse message. An agent may issue a Trap message in response to an event that affects the MIB and the underlying resources.

The development of SNMPv2c addressed limitations in SNMPv1. The most noticeable enhancements were the introduction of the GetBulkRequest message type and the addition of 64-bit counters to the MIB. Retrieving information with GetRequest and GetNextRequest was an inefficient method of collecting information. Only one variable at a time could be solicited with SNMPv1. The GetBulkRequest addresses this weakness by receiving more information with a single request. Secondly, the 64-bit counters addressed the issue of counters rolling over too quickly, especially with higher speed links like Gigabit Ethernet.

The management entity is also referred to as the manager or network management station (NMS). It is responsible for soliciting information from the agent. The solicitations are based on very specific requests. The manager processes the retrieved information in a number of ways. The retrieved information can be logged for later analysis, displayed using a graphing utility, or compared with preconfigured values to test if a particular condition has been met.

Not all manager functions are based on data retrieval. There is also the ability to issue changes of a value in the managed device. This feature enables an administrator to configure a managed device using SNMP.

The interaction between the manager and the managed device does introduce traffic to the network. Caution should be taken when introducing managers on to the network. Aggressive monitoring strategies can negatively affect network performance. Bandwidth utilizations will go up, which may be an issue for WAN environments. Also, monitoring has a performance impact on the devices being monitored, since they are required to process the manager requests. This processing should not take precedence over production services.

A general rule is that a minimum amount of information should be polled as infrequently as possible. Determine which devices and links are most critical and what type of data is required.

SNMP uses UDP as a transport protocol. Since UDP is connectionless and unreliable, it is possible for SNMP to lose messages. SNMP itself has no provision for guarantee of delivery, so it is up to the application using SNMP to cope with lost messages.

Each SNMP message contains a cleartext string, called a community string. The community string is used like a password to restrict access to managed devices. SNMPv3 has addressed the security concerns raised by tranmitting the community string in cleartext.

An example of what the SNMPv2c message looks like is illustrated in Figure . A detailed presentation of the protocol can be found in the Internet standard RFC1905.

The fact that the community string is cleartext is no surprise to anyone who has studied the Internet Protocol (IP) protocol suite. All fields specified in the protocol suite are cleartext, except for security authentication and encryption specifications.

The community string was essentially a security placeholder until the SNMPv2 working group could ratify security mechanisms. The efforts were referred to the SNMPv3 working group. All SNMP-based management applications need to be configured to use the appropriate community strings. Some organizations frequently change the community string values to reduce the risk of malicious activity from the unauthorized use of the SNMP service.

In spite of the weakness associated with community-based authentication, management strategies are still based on SNMPv1. Cisco devices do support SNMPv3 message types and the increased security capabilities, but most management software applications do not support SNMPv3.

SNMPv3 supports the concurrent existence of multiple security models.