SNMP Commands: Get, GetNext, Set, Trap, GetBulk, and Inform

As part of the configuration of a managed device, you can also identify whether it should be configured for read access, write access, or both. If configured for read access, an NMS like HP OpenView can gather information about the device. If configured for write access, an NMS can also configure the device using SNMP commands. The choice will depend upon whether you want to use the NMS strictly for gathering information or for configuration purposes also.

The “simple” part in the Simple Network Management Protocol relates to the fact that the interactions between managed devices and an NMS aren’t terribly complex. In the original version of SNMP (SNMPv1), only four operations are possible between an NMS and a managed device. There are outlined below:

  • Get. The Get operation is used by an NMS to obtain a single piece of information from a managed device. For example, the NMS may be requesting the device’s configured name. “Get” is a read operation.
  • GetNext. The GetNext operation is issued by an NMS in order to obtain more than one piece of information from a managed device. For example, the NMS may wish to obtain both the name and system uptime of a particular device. In SNMPv1, when an NMS wants to obtain multiple pieces of information from a managed device, its only option is to issue Get and GetNext commands. “GetNext” is also a read operation.
  • Set. The Set command is used by an NMS to configure a managed device with a particular value. For example, maybe the NMS wants to configure or “set” a threshold on a managed device that tells it to alert the NMS if its CPU utilization hits 70% for a defined period of time. “Set” is a write operation.
  • Trap. A Trap operation is different that those described above, because it is initiated from a managed device. A trap message is used to alert an NMS to the fact that a threshold defined by the NMS (with the set command) has been reached, or that an error/event of some type has occurred. For example, a router may have been configured to set a trap message to an NMS when its average CPU utilization is over 70% for a period of one minute. Trap messages are said to be asynchronous, in that a managed device sends them without a request from an NMS.

SNMPv2 introduced two additional SNMP commands:

  • GetBulk. The GetBulk operation was implemented to allow NMSs to obtain multiple pieces of information from a managed device in a single request. It’s important to note that this command is not supported on devices using SNMPv1. “GetBulk” is a read command.
  • Inform. The Inform operation allows an NMS to forward trap information to other NMSs.

As mentioned earlier, SNMP was designed to use UDP as its transport protocol. This is part of what helps make SNMP “lightweight”, since the session establishment overhead associated with TCP is avoided. When an NMS wants to configure a managed device or gather information from it, it will make a request to that device, destined for UDP port 161. As with most exchanges in the world of TCP/IP, the source port will usually be chosen dynamically.

Perhaps the most important feature of SNMP from a monitoring perspective is the ability of a managed device to send trap messages to an NMS asynchronously. In other words, when an error occurs on a device, or when one of the thresholds previously “set” by the NMS is reached, the managed device will automatically send a trap message to its configured NMS. Trap messages from a managed device are sent to UDP port 162 on the NMS.

SNMP Versions

Three versions of SNMP have been standardized – SNMPv1, SNMPv2, and SNMPv3. While the versions all work in a similar manner, they are not directly compatible. Some of the differences between the versions include:

  • SNMPv2 and SNMPv3 include additional commands not available in SNMPv1.
  • In SNMPv1 and SNMPv2, security is based on a very simple administrative grouping known as a community. SNMPv3 is the most secure of the versions, including features that provide message integrity, authentication, and encryption.

Having said that, many vendors (including Cisco) have made their devices “multilingual”, meaning that they are capable of using SNMPv1, SNMPv2, SNMPv3, or even different versions concurrently. Along the same lines, most SNMP NMSs are also “multilingual”.

The Simple Network Management Protocol

The Simple Network Management Protocol (SNMP) is an application-layer communication protocol that provides a standardized method for managing network devices. The protocol is part of the TCP/IP protocol suite and uses UDP as its transport protocol.
In order to better appreciate how SNMP works, let’s begin by taking a look at the different components of an SNMP-based system – managed devices, agents, and network management systems.

  • Managed Devices. A managed device is any piece of equipment that includes the ability to be managed via the SNMP protocol. Common examples include hubs, switches, routers, printers, and servers.
  • Agents. A managed device includes a software module known as an agent. An agent implements the SNMP protocol on a device, allowing information about the device to be stored and retrieved. The terms “agent” and “managed device” are often used interchangeably when discussing SNMP.
  • Network Management System. An SNMP Network Management System (NMS) is an application capable of monitoring and configuring SNMP managed devices. Examples of common NMSs include HP OpenView, SunNet Manager, and TNG Unicenter. These applications act as the focal point on an SNMP-managed network, where data is collected and configuration is carried out. In order to use SNMP to manage a network, at least one NMS must be present. NMSs are also sometimes referred to as consoles.

ISO Network Management Processes

The International Organization for Standardization has developed a framework for the management of networks in their Structure of Management Information (SMI) standard. The framework divides network management processes into 5 main functional areas – Fault, Configuration, Accounting, Performance, and Security management. Commonly referred to by the acronym FCAPS, each area relates to a high-level IT management process.

Fault Management

Fault management is concerned with detecting network faults, logging this information, contacting the appropriate person, and ultimately fixing a problem. A common fault management technique is to implement an SNMP-based network management system – such as HP OpenView or Sun Solstice (formerly Net Manager) – to collect information about network devices. In turn, the management station can be configured to make a network administrator aware of problems (by email, paging, or on-screen messages), allowing appropriate action to be taken. SNMP and its functions will be looked at in more detail shortly.

Configuration Management

Configuration management is concerned with monitoring system configuration information, and any changes that take place. This area is especially important, since many network issues arise as a direct result of changes made to configuration files, updated software versions, or changes to system hardware. A proper configuration management strategy involves tracking all changes made to network hardware and software. Examples include altering the running configuration of a device, updating the IOS version of a router or switch, or adding a new modular interface card. While it is possible to track these changes manually, a more common approach is to gather this information using configuration management software, such as CiscoWorks 2000. CiscoWorks 2000 will be looked at in more detail later in the chapter.

Accounting Management

Accounting management is concerned with tracking network utilization information, such that individual users, departments, or business units can be appropriately billed or charged for accounting purposes. While this may not be applicable to all companies, in many larger organizations the IT department is considered a cost center that accrues revenues according to resource utilization by individual departments or business units.

Performance Management

Performance management is focused on ensuring that network performance remains at acceptable levels. This area is concerned with gathering regular network performance data such as network response times, packet loss rates, link utilization, and so forth. This information is usually gathered through the implementation of an SNMP management system, either actively monitored, or configured to alert administrators when performance move above or below predefined thresholds. Actively monitoring current network performance is an important step in identifying problems before they occur, as part of a proactive network management strategy.

Security Management

Security management is not only concerned with ensuring that a network environment is secure, but also that gathered security-related information is analyzed regularly. Security management functions include managing network authentication, authorization, and auditing, such that both internal and external users only have access to appropriate network resources. Other common tasks include the configuration and management of network firewalls, intrusion detection systems, and security policies such as access lists.

Proactive Network Management

A more effective strategy, and one that tends to be much more cost-effective over the long term, is focused on proactively monitoring and managing a network. Instead of sitting back and hoping for the best, a company that engages in a proactive network management strategy will focus on actively trying to determine potential problem areas regularly, before they lead to more serious issues. In order to do this, companies need to gather network information in real-time (or at regular intervals), usually through the use of network management protocols and applications.
Implementing a proactive network management strategy is easier said than done. While certain protocols and applications may be capable of providing reams of information, a company must first create a baseline that outlines what they consider to be “normal” (or expected) network performance. This information can be used comparatively to help identify potential problem areas. The steps involved in moving towards a proactive network management strategy include:

  • Determining network goals and then identifying appropriate metrics that will show whether these goals are being met. For example, a customer might require utilization on all Ethernet segments to be below a certain percentage, or that WAN response times fall into a certain range. Over time, these metrics will need to be adjusted to compensate for changes to the network infrastructure.
  • Defining how network data will be collected and managed. For example, will the customer telnet into routers to view utilization statistics, or will they rely on SNMP and a network management system?
  • Defining a strategy for storing and analyzing collected data. For example, will the data be monitored in real-time, or be evaluated regularly using daily or weekly reports?
  • Identifying potential network bottlenecks and problem areas, and then defining a strategy for improvement. By engaging in trend analysis, increases in resource utilization should become apparent, allowing for network “focus areas” to be identified.
  • Fully documenting all network changes. This information can later be used for troubleshooting purposes, or to assess the impact that changes have had on the network.
  • As the company network grows, implementing a proactive network strategy should become the primary goal. This will help to ensure that potential problem areas are identified and acted upon, before they reach more critical stages.

Reactive Network Management

In the real world, companies tend to follow one of two network management strategies. The first strategy involves working on solving problems after they occur, dealing with issues reactively. The second strategy is a more proactive approach, actively attempting to identify potential problem areas before they can seriously impact the network.

Calling reactive management a “strategy” is stretching the truth to some degree. Since many companies are already stretched thin when it comes to day-to-day network and system administration tasks, there is often little time left to head off problems before they occur. As such, these companies react to problems, trying to deal with them as quickly as possible. Obviously this is not optimal. Network failures will usually have a marked impact on the productivity of all users, leading to additional costs. These costs are often much higher than those associated with taking a proactive approach to network monitoring and analysis.

Managing Cisco Networks

An important part of any network design process involves a serious look at network management. As a customer’s network changes or grows, the need for a network management solution that provides control over network performance, troubleshooting, security, and configuration becomes more acute. When all is said and done, a network is still only a vehicle used to enable a customer’s business. Ensuring that it performs as required and expected must be a primary consideration of any network design project.
Network management is comprised of many elements including processes, protocols, and applications. Whether it’s monitoring a network for potential trouble spots, or looking for a way to ease the burden of change and configuration management, Cisco provides access to protocols and applications that can be used to help manage both the largest and the smallest of networks. The network management concepts that we’ll cover in this series of articles include:

  • Network management strategies
  • The five ISO network management processes
  • Simple Network Management Protocol (SNMP)
  • Remote Monitoring (RMON)
  • Network management applications and tools

On even the best-designed networks, problems will eventually occur. A keen eye towards network management helps to ensure that performance requirements are met today, and that potential problem areas are identified and dealt with before they become serious issues.

Kerberos Authentication

Kerberos is another network authentication protocol supported by the Cisco IOS. Kerberos was originally developed by MIT, and is standardized in RFC 1510. Unlike TACACS+ and RADIUS, Kerberos only supports authentication, and not authorization or accounting.

Kerberos authentication works according to a three-headed model, which has proven to be a very secure method of providing authentication services. This model is made up of three main elements – clients, services, and Key Distribution Centers (KDCs). When a Kerberos client attempts to log on, a request is passed to the KDC. The KDC will encrypt what is known as a ticket-granting ticket (TGT), and pass it back to the client. The client’s supplied password is used to decrypt the ticket, thus validating them. Next, when the user attempts to gain access to a service (which could be telnet on a Cisco router), the client passes their TGT (which shows they are authenticated) back to the KDC, asking for a ticket to that service. Once the ticket is supplied by the KDC, the client can then access the service in question. In this way, the KDC acts as a trusted third-party, providing authentication services between clients and network services.

Remote Authentication Dial In User Service (RADIUS) Authentication

Remote Authentication Dial In User Service (RADIUS) is another popular authentication mechanism used in network environments, and is standardized in RFC 2138. RADIUS does not explicitly follow the AAA model – instead, it combines both authentication and authorization functions. However, a RADIUS implementation is also made up of clients and servers. When a RADIUS client (such as a switch, router, or VPN server) receives an authentication request, it passes that request to its configured RADIUS server for validation. While similar in function to TACACS+, the two authentication mechanisms are completely separate and are not compatible. One major difference between the two is that TACACS+ use TCP as its transport, while RADIUS uses UDP.

The Cisco Secure ACS product can also function as a RADIUS server. A variety of third-party RADIUS server solutions also exist. It has become increasingly common for vendors to build RADIUS client functionaility into their network equipment, making it a great choice for authentication, authorization, and accounting functions in heterogeneous network environments.

Terminal Access Controller Access Control System (TACACS) Authentication

Terminal Access Controller Access Control System (TACACS) was originally defined in RFC 1492 as a system to allow users connecting to a remote access server to be centrally authenticated. TACACS was originally implemented in the Cisco IOS in 1989, and was later extended to include additional features in what is known as XTACACS (Extended TACACS). While client support for both versions can still be found in the Cisco IOS, they are currently considered End-of-Maintenance (EoM) protocols. Cisco currently supports a completely new (and incompatible) version on its equipment known as TACACS+.

TACACS+ provides what are known as AAA services – Authentication, Authorization, and Accounting. Authentication services are used to identify users, usually via a username and password combination. Authorization services are used to control what a user has access to, once they have been authenticated. For example, a user could be given access to only certain router commands with TACACS+. Accounting services track user sessions, such that the amount of time that a user spends connected to a system can be logged for security or billing purposes. All three of components are considered central to the security of networking services.

In TACACS lingo, a client would be a device like a switch or router. A server would be a centralized server configured with a user database of some sort, where authentication (as well as authorization and accounting) requests would be validated. For example, if a router were configured to use TACACS+ authentication, it would not authenticate connected users locally, but would rather pass the request on to a TACACS+ server. This would allow a single user account to be defined for an administrator, who could then log on to equipment for which they had been authorized. Cisco provides a TACACS+ server in its Cisco Secure Access Control Server (ACS) product, but freeware TACACS+ servers that run on UNIX/Linux are also available.