Amazon.co.uk Review
Because it's orientated towards SNMP as a tool, much of the coverage in this book has to do with software that uses SNMP to provide network monitoring and control services. After a strengths-and-weaknesses overview of a number of SNMP packages, the authors use mainly HP OpenView, Castle Rock SNMPc, and Net-SNMP (the last in combination with Perl scripting) to demonstrate how SNMP works and how to take advantage of it. It's the scripting that really distinguishes this book from other SNMP books, by the way. It's integral to the authors' presentation, and the latter half of this book is packed with shell and Perl listings. --David Wall
Topics covered: Simple Network Management Protocol (SNMP) and its applicability as a network management tool. Details like Object Identifiers (OIDs), Management Information Bases (MIBs), traps, and community strings are defined and explained. The configuration of SNMP agents is detailed for several software packages and operating systems, and the integration of SNMP and scripts (in shell languages and in Perl) is covered nicely.
Review
Jeffrey Taylor, ERCB, July 2002
Product Description
The Simple Network Management Protocol (SNMP) is an Internet-standard protocol for managing hosts on an IP network. Devices that typically support SNMP include routers, switches, servers, workstations, printers, modem racks, UPSs, and more.
Essential SNMP is a practical introduction to SNMP for network and system administrators. It starts with the basics of SNMP and how it works, along with the technical background to use it effectively. The book covers OIDs, MIBs, community strings, traps, and other technical elements. But the main focus is on practical network administration: how to configure SNMP agents and network management stations, how to use SNMP to retrieve and modify variables on network devices, how to configure management software to react to traps sent by managed devices.
Essential SNMP explores both commercial and open source packages, including HP's OpenView, Castle Rock's SNMPc, the Net-SNMP tools, Simon Leinen's Perl SNMP support, and MRTG. Administrators will come away with ideas for writing scripts to help them manage their networks, create managed objects, and extend the operation of SNMP agents. In addition to SNMPv1 and v2, the book covers SNMPv3, which has just started to appear in commercial products as of this printing.
From the Publisher
About the Author
Douglas R. Mauro lives outside of Rochester, New York, with his wife Amy, daughter Kari, and cat Megabyte (a.k.a. Meg). He received a bachelor's degree at the University of Albany, New York, and worked as a system administrator for several years before becoming a project engineer with Sun Microsystems, Inc. In addition to his consulting duties with Sun, he authors their internal OneStop Sun Management Center page and has published several InfoDocs with them. Computers are not just a way of life for Douglas, but a profound passion. He feels extremely fortunate to be working in a field he truly loves.
Kevin J. Schmidt lives in Decatur, Georgia. He shares a home with his significant other, Callie, their loving cats, Chester and Twiggy, two Peruvian guinea pigs, two Litoria species White's tree frogs, and several poison dart frogs. Originally from Pensacola, Florida, Kevin spent several years studying computer science at the University of West Florida. In late 1996 he was recruited by MindSpring Enterprises (now known as Earthlink, Inc.), a national ISP based in Atlanta, and subsequently left school to pursue his career. He spent four years in network management and was the senior network management architect for Earthlink. He left Earthlink to work at Netrail, a tier-1 Internet backbone provider. While at Netrail, Kevin was in charge of the company's network management architecture. These days Kevin works as a software engineer for Guarded.Net, a network security start-up in Atlanta. Kevin's first computer was a Commodore 64. He began running Bulletin Board Systems (BBSs) at age 11 and later became interested in computer networking in general. His other computing interests include Linux, MySQL, and programming in C, Java, Perl, and PHP. Kevin will soon have his private pilot's license and plans to become instrument and multiengine rated soon thereafter. He recently discovered the LEGO® MINDSTORMS™ Robotics Invention System, where he uses Dave Baum's Not Quite C (NQC) for Linux to control his robotic creations.
Excerpted from Essential SNMP by Douglas R. Mauro, Kevin J. Schmidt. Copyright © 2001. Reprinted by permission. All rights reserved.
In this chapter, we start to look at SNMP in detail. By the time you finish this chapter, you should understand how SNMP sends and receives information, what exactly SNMP communities are, and how to read MIB files. We'll also look in more detail at the three MIBs that were introduced in Chapter 1, namely MIB-II, Host Resources, and RMON.
SNMP and UDP
SNMP uses the User Datagram Protocol (UDP) as the transport protocol for passing data between managers and agents. UDP, defined in RFC 768, was chosen over the Transmission Control Protocol (TCP) because it is connectionless; that is, no end-to-end connection is made between the agent and the NMS when datagrams (packets) are sent back and forth. This aspect of UDP makes it unreliable, since there is no acknowledgment of lost datagrams at the protocol level. It's up to the SNMP application to determine if datagrams are lost and retransmit them if it so desires. This is typically accomplished with a simple timeout. The NMS sends a UDP request to an agent and waits for a response. The length of time the NMS waits depends on how it's configured. If the timeout is reached and the NMS has not heard back from the agent, it assumes the packet was lost and retransmits the request. The number of times the NMS retransmits packets is also configurable.
At least as far as regular information requests are concerned, the unreliable nature of UDP isn't a real problem. At worst, the management station issues a request and never receives a response. For traps, the situation is somewhat different. If an agent sends a trap and the trap never arrives, the NMS has no way of knowing that it was ever sent. The agent doesn't even know that it needs to resend the trap, because the NMS is not required to send a response back to the agent acknowledging receipt of the trap.
The upside to the unreliable nature of UDP is that it requires low overhead, so the impact on your network's performance is reduced. SNMP has been implemented over TCP, but this is more for special-case situations in which someone is developing an agent for a proprietary piece of equipment. In a heavily congested and managed network, SNMP over TCP is a bad idea. It's also worth realizing that TCP isn't magic, and that SNMP is designed for working with networks that are in trouble--if your network never failed, you wouldn't need to monitor it. When a network is failing, a protocol that tries to get the data through but gives up if it can't is almost certainly a better design choice than a protocol that will flood the network with retransmissions in its attempt to achieve reliability.
SNMP uses the UDP port 161 for sending and receiving requests, and port 162 for receiving traps from managed devices. Every device that implements SNMP must use these port numbers as the defaults, but some vendors allow you to change the default ports in the agent's configuration. If these defaults are changed, the NMS must be made aware of the changes so it can query the device on the correct ports.
Figure 2-1 shows the TCP/IP protocol suite, which is the basis for all TCP/IP communication. Today, any device that wishes to communicate on the Internet (e.g., Windows NT systems, Unix servers, Cisco routers, etc.) must use this protocol suite. This model is often referred to as a protocol stack, since each layer uses the information from the layer directly below it and provides a service to the layer directly above it.
When either an NMS or an agent wishes to perform an SNMP function (e.g., a request or trap), the following events occur in the protocol stack:
Application
First, the actual SNMP application (NMS or agent) decides what it's going to do. For example, it can send an SNMP request to an agent, send a response to an SNMP request (this would be sent from the agent), or send a trap to an NMS. The application layer provides services to an end user, such as an operator requesting status information for a port on an Ethernet switch.
UDP
The next layer, UDP, allows two hosts to communicate with one another. The UDP header contains, among other things, the destination port of the device to which it's sending the request or trap. The destination port will either be 161 (query) or 162 (trap).
IP
The IP layer tries to deliver the SNMP packet to its intended destination, as specified by its IP address.
Medium Access Control (MAC)
The final event that must occur for an SNMP packet to reach its destination is for it to be handed off to the physical network, where it can be routed to its final destination. The MAC layer is comprised of the actual hardware and device drivers that put your data onto a physical piece of wire, such as an Ethernet card. The MAC layer also is responsible for receiving packets from the physical network and sending them back up the protocol stack so they can be processed by the application layer (SNMP, in this case).
