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. --This text refers to an out of print or unavailable edition of this title.
Review
Jeffrey Taylor, ERCB, July 2002
Product Description
Simple Network Management Protocol (SNMP) provides a "simple" set of operations that allows you to more easily monitor and manage network devices like routers, switches, servers, printers, and more. The information you can monitor with SNMP is wide-ranging--from standard items, like the amount of traffic flowing into an interface, to far more esoteric items, like the air temperature inside a router. In spite of its name, though, SNMP is not especially simple to learn.
O'Reilly has answered the call for help with a practical introduction that shows how to install, configure, and manage SNMP. Written for network and system administrators, the book introduces the basics of SNMP and then offers a technical background on how to use it effectively. Essential SNMP explores both commercial and open source packages, and elements like OIDs, MIBs, community strings, and traps are covered in depth. The book contains five new chapters and various updates throughout. Other new topics include:
- Expanded coverage of SNMPv1, SNMPv2, and SNMPv3
- Expanded coverage of SNMPc
- The concepts behind network management and change management
- RRDTool and Cricket
- The use of scripts for a variety of tasks
- How Java can be used to create SNMP applications
- Net-SNMP's Perl module
The bulk of the book is devoted to discussing, with real examples, how to use SNMP for system and network administration tasks. 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.
Once demystified, SNMP is much more accessible. If you're looking for a way to more easily manage your network, look no further than Essential SNMP, 2nd Edition.
From the Publisher
About the Author
Douglas Mauro 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.
Kevin J. Schmidt currently lives in Lilburn, Georgia. He is a senior software developer at SecureWorks, Inc. (http://www.secureworks.com), where he is lead developer for the comapny's SIM platform. He also leading the development of the company's log analysis service line. Prior to SecureWorks, Kevin was a senior Java/C developer at Reflex Security (http://www.reflexsecurity.com). And prior to Reflex, Kevin spent four years at GuardedNet, Inc. (http://www.micromuse.com/sols/dom_man/sec_man.html) as a senior software developer and team lead.
Kevin's experience with network management began in 1995 while working at a regional ISP in Pensacola, Florida. In 1996 he moved to Atlanta, Georgia to work for MindSpring Enterprises (now known as Earthlink), a national ISP. 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.
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). --This text refers to an out of print or unavailable edition of this title.
