Section 6.3. Agent Configuration Walkthroughs
6.3. Agent Configuration WalkthroughsIn the following sections, we will walk through the configurations of some typical SNMP agents. We have chosen devices that are found on almost every modern network (PCs, Unix servers, routers, UPSs, etc.). The point of this discussion isn't to show you how your particular agent is configuredthat would not be practical, given the hundreds of devices and vendors out there. Our intent is to give you a feel for what the common options are, and what steps you'll typically go through to configure an agent. 6.3.1. Windows Agents (Net-SNMP)Microsoft makes an SNMP agent for its operating systems. Unfortunately, it's not exactly the most feature-rich agent in the world. In this section, we'll install the Net-SNMP agent on Windows. The nice thing about this agent is that it's free. For those of you who need the support of a commercial product, take a look at Concord's SNMP agent; it's covered later in this chapter. The Net-SNMP agent is available from http://net-snmp.sourceforge.net. We discuss the Net-SNMP agent for Windows in this section, and the nice thing about this is that both environments share the same configuration settings. Review the section about the Unix agent later in this chapter for details on advanced configurations. We should point out some differences between the Windows version and the Unix version of the agent. If we wait until the end of this section, they might not catch your attention as easily:
Go to the Net-SNMP site and download the prebuilt binary for Windows. Once it's downloaded, double-click the icon to display a setup screen as in Figure 6-1. Click Next, which brings up a window like the one in Figure 6-2. Select "I accept the terms in the License Agreement" (after you have actually read it) and click Next to display Figure 6-3. The Base Components option will install command-line tools and other things. This is actually a good idea, because then you can use the same Net-SNMP command-line tools we use throughout the book; the options are the same. The next two options install the SNMP agent and a trap receiver. The fourth option installs the Net-SNMP Perl modules. If you are interested in using Perl, you will need to install a Perl interpreter. You can get a very good Windows interpreter from http://www.activestate.com. Figure 6-4 appears when you click Next. You are selecting the location where you want to install the package. The default, C:\usr, is a bit odd for Windows, but we suggest leaving it as is mainly because all the Unix examples in this book use that base directory. Figure 6-1. Net-SNMP initial install screen Figure 6-2. Net-SNMP license agreement Figure 6-3. Net-SNMP component selection Figure 6-4. Net-SNMP install location Once the package is installed, you need to register the agent as a service so that it will start upon reboot. This also gives you greater control over the agent. Here is the command sequence, assuming you installed the package in C:\usr. C:\Documents and Settings\kschmidt\Desktop>cd c:\usr C:\usr>registeragent.bat Registering snmpd as a service using the following additional options: . -Lf "C:/usr/log/snmpd.log" . . For information on running snmpd.exe and snmptrapd.exe as a Windows service, see 'How to Register the Net-SNMP Agent and Trap Daemon as Windows services' in README.win32. . Press any key to continue . . . C:\usr> Once this is done, you need to start the agent. Go to the Control Panel and bring up the Administrative Tools. Once this loads, double-click the Services icon. Scroll through the list of services until you find the Net-SNMP service. It should not be running, as shown in the status column in Figure 6-5. Figure 6-5. Windows Services Click on "Start the service" and it should start running, as shown in Figure 6-6. Figure 6-6. The running Net-SNMP agent You can now stop, pause, and restart the agent. Start it and then try to access the agent. You can use the SNMP tools installed on the machine to do this, using the following commands: C:\usr>snmpwalk -v2c -c public localhost Timeout: No Response from localhost C:\usr> We get a timeout because we haven't configured the agent to respond to any SNMP queries. To do this, use your favorite editor to create a file called c:\usr\etc\snmp\snmpd.conf and add this line to it: rwcommunity public This sets up a read-write community string of public. Please note that this example is just for demonstration purposes. You should choose a more robust community string. For the changes to take effect, you need to go to the Services panel and click Restart.
Once you have done that, try the same command again, and the agent responds to our SNMP query: C:\usr>snmpwalk -v2c -c public localhost SNMPv2-MIB::sysDescr.0 = STRING: Windows loanera22p 5.1.2600 Service Pack 1 XP P rofessional x86 Family 6 Model 8 Stepping 10 SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.13 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (4540) 0:00:45.40 SNMPv2-MIB::sysContact.0 = STRING: USER SNMPv2-MIB::sysName.0 = STRING: loanera22p SNMPv2-MIB::sysLocation.0 = STRING: unknown SNMPv2-MIB::sysORLastChange.0 = Timeticks: (5) 0:00:00.05 SNMPv2-MIB::sysORID.1 = OID: IF-MIB::ifMIB SNMPv2-MIB::sysORID.2 = OID: TCP-MIB::tcpMIB SNMPv2-MIB::sysORID.3 = OID: IP-MIB::ip SNMPv2-MIB::sysORID.4 = OID: UDP-MIB::udpMIB SNMPv2-MIB::sysORID.5 = OID: SNMPv2-MIB::snmpMIB SNMPv2-MIB::sysORID.6 = OID: SNMP-VIEW-BASED-ACM-MIB::vacmBasicGroup SNMPv2-MIB::sysORID.7 = OID: SNMP-FRAMEWORK-MIB::snmpFrameworkMIBCompliance SNMPv2-MIB::sysORID.8 = OID: SNMP-MPD-MIB::snmpMPDCompliance SNMPv2-MIB::sysORID.9 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance Now, if you don't want to run the agent as a service, you can run it from the command line. The command is simply snmpd: C:\usr>snmpd No log handling enabled - turning on stderr logging NET-SNMP version 5.2.1 The Net-SNMP folks have done a really nice job of putting the Windows distribution together. It may seem like quite a few steps are involved, but believe me you would not even be done installing the Microsoft agent at this point. If you want to know more about configuring the agent, read the section about the Unix version later in this chapter. The snmpconf Perl script that comes with the Unix version also comes with the Windows version, so you can use it to create configuration files. 6.3.2. HP OpenView Agent for HP-UX and SolarisOne text configuration file controls the parameters for the OpenView agent; the file is typically named /etc/SnmpAgent.d/snmpd.conf, or /etc/snmpd.conf on older systems. You don't need to edit this file for the agent to function normally. If you do edit it, you must stop and restart the master agent by executing the SnmpMaster script, first with a stop and then a start : $ /sbin/init.d/SnmpMaster stop $ /sbin/init.d/SnmpMaster start 6.3.2.1. Simple configurationThe following configuration file configures the agent to respond to get requests using the community name public and set requests using the community name private. There are no restrictions on which MIBs can be queried, or which hosts can make the queries. This configuration has no security, since the community strings are set to commonly used defaults and are widely known. The OpenView agent sends authentication-failure traps by default, so you don't have to enable these traps in the configuration file. get-community-name: public set-community-name: private trap-dest: 127.0.0.1 contact: B.Gates location: 12 Pyramid - Egypt The simplest configuration is to edit the file and place more reasonable community names in the first two lines. We can't say it too much: community names are essentially passwords. Use the same rules for picking community names that you would for choosing the root password. You should always set the destination trap host (TRap-dest) to the IP address of the host that will receive the trap. The next example configures several different community names: get-community-name: public get-community-name: media set-community-name: hushed set-community-name: veryprivate set-community-name: shhhh We have created two get (read-only) communities and three set (read-write) communities. These communities can be used as you see fit. (In real life, we would have chosen more obscure names.) For example, you might give your operations group in New York public community access and your operations group in Atlanta media community access. The remaining set communities can further be subdivided among various administrators and other staff who need read-write access. 6.3.2.2. Advanced configurationSetting up multiple community strings doesn't sound very useful, and by itself, it isn't. But you can take the concept a step further and create different communities, each consisting of a few particular hosts and able to access only some of the objects SNMP manages. The next example allows the host 10.123.56.25 to issue gets using the community name comname and sets using the community name private. The host 10.123.46.101 can issue gets using only the community name comname. You cannot use hostnames after the IP: directive; you must use IP addresses. get-community-name comname IP: 10.123.56.25 10.123.46.101 set-community-name private IP: 10.123.56.25 You can also configure the agent to restrict access to MIB subtrees based on IP addresses. The next example allows any host to get any object under iso.org.dod.internet.mgmt.mib-2, except for objects in the interfaces subtree. The minus sign (-) in front of interfaces instructs the agent to disallow access to this subtree. get-community-name public VIEW: mib-2 -interfaces The final example sets up multiple community names for both sets and gets. An administrator who is located at host 10.123.46.25 and knows the admin community string has read access to the entire MIB tree; with the adminset community string, he has write access to the entire tree. Someone with the operator community string can sit anywhere and access everything in mib-2 except for the interfaces subtree, but must be sitting at his desk (10.123.56.101) to issue sets and is not allowed to set anything in the mib-2 subtree. get-community-name operator VIEW: mib-2 -interfaces get-community-name admin IP: 10.123.56.25 set-community-name operset IP: 10.123.46.101 VIEW: -mib-2 set-community-name adminset IP: 10.123.56.25 6.3.3. Net-SNMP for UnixNet-SNMP is an open source agent that is freely available from http://net-snmp.sourceforge.net. We will focus on Net-SNMP Version 5.2.1, which is the most recent as of this publication. Once you have downloaded and unpacked the distribution, cd into the directory in which you unpacked Net-SNMP and read the README and INSTALL files. These files provide general information on installing the agent and don't require much explanation here. Net-SNMP uses a configure script to make sure your environment has some key utilities and libraries installed, so it can be compiled successfully. Many configuration options are settable when you run this script. To see a list of them, run the following command: net-snmp-5.2.1/> ./configure --help One common option is - -prefix=PATH. This specifies an alternate installation directory. By default, Net-SNMP will install in /usr/local/bin, /usr/local/man, etc. We'll be running configure without any options, which means our Net-SNMP build will have default values assigned for various options. For example, the agent binary will be placed in /usr/local/sbin. Run the following command to begin the configuration process: net-snmp-5.2.1/> ./configure Note that by default, Net-SNMP does not compile in the Host Resources MIB. You will want to add this to the configure line if you want to access things like CPU statistics, memory and disk information, etc. Run configure like so: net-snmp-5.2.1/> ./configure -with-mib-modules=host You will see various messages about what features configure is looking for and whether they're found. After running for a while, configure will ask for some basic SNMP information: ************** Configuration Section ************** You are about to be prompted by a series of questions. Answer them carefully, as they determine how the snmp agent and related applications are to function. After the configure script finishes, you can browse the newly created config.h file for further - less important - parameters to modify. Be careful if you re-run configure though since config.h will be over written. -Press return to continue- When you press Return, you'll be prompted for the particular version of SNMP you wish to use: disabling above prompt for future runs... yes checking System Contact Information... *** Default SNMP Version: Starting with Net-SNMP 5.0, you can choose the default version of the SNMP protocol to use when no version is given explicitly on the command line, or via an 'snmp.conf' file. In the past this was set to SNMPv1, but you can use this to switch to SNMPv3 if desired. SNMPv3 will provide a more secure management environment (and thus you're encouraged to switch to SNMPv3), but may break existing scripts that rely on the old behaviour. (Though such scripts will probably need to be changed to use the '-c' community flag anyway, as the SNMPv1 command line usage has changed as well.). At this prompt you can select "1", "2" (for SNMPv2c), or "3" as the default version for the command tools (snmpget, ...) to use. This can always be overridden at runtime using the -v flag to the tools, or by using the "defVersion" token in your snmp.conf file. Providing the --with-default-snmp-version="x" parameter to ./configure will avoid this prompt. Default version of SNMP to use (3): 3 setting Default version of SNMP to use to... 3 We've decided to select version 3 as our default. Since it's now a full IETF standard, there is no reason to not use it. As noted in the text before the prompt, you can always override the version for the command-line tools with the -v switch. Next we are asked to configure the system contact: checking System Contact Information... *** System Contact Information: Describes who should be contacted about the host the agent is running on. This information is available in the MIB-II tree. This can also be over-ridden using the "syscontact" syntax in the agent's configuration files. Providing the --with-sys-contact="contact" parameter to ./configure will avoid this prompt. System Contact Information (kjs@): snmpadmin@oreilly.com setting System Contact Information to... snmpadmin@ora.com We've decided to set our contact information to something useful, but we could have left it blank. The next item you're asked to configure is system location. We've chosen an informative value, but again we could have left it blank: checking System Location... *** System Location: Describes the location of the system. This information is available in the MIB-II tree. this can also be over-ridden using the "syslocation" syntax in the agent's configuration files. Providing the --with-sys-location="location" parameter to ./configure will avoid this prompt. System Location (Unknown): FTP Server #1, O'Reilly Data Center setting System Location to... FTP Server #1, O'Reilly Data Center The final options you need to configure are the locations of snmpd's logfile and its persistent storage. In both cases, you simply press Enter to accept the default locations. checking Location to write logfile... *** Logfile location: Enter the default location for the snmpd agent to dump information & errors to. If not defined (enter the keyword "none" at the prompt below) the agent will use stdout and stderr instead. (Note: This value can be over-ridden using command line options.) Providing the --with-logfile="path" parameter to ./configure will avoid this prompt. Location to write logfile (/var/log/snmpd.log): <Enter> setting Location to write logfile to... /var/log/snmpd.log checking Location to write persistent information... *** snmpd persistent storage location: Enter a directory for the SNMP library to store persistent data in the form of a configuration file. This default location is different than the old default location (which was for ucd-snmp). If you stay with the new path, I'll ask you in a second if you wish to copy your files over to the new location (once only). If you pick some other path than the default, you'll have to copy them yourself. There is nothing wrong with picking the old path (/var/ucd-snmp) if you'd rather. Providing the --with-persistent-directory="path" parameter to ./configure will avoid this prompt. Location to write persistent information (/var/net-snmp): <Enter> setting Location to write persistent information to... /var/net-snmp configure: creating ./config.status config.status: creating Makefile config.status: creating snmplib/Makefile config.status: creating apps/Makefile config.status: creating apps/snmpnetstat/Makefile config.status: creating agent/Makefile config.status: creating agent/helpers/Makefile config.status: creating agent/mibgroup/Makefile config.status: creating local/Makefile config.status: creating testing/Makefile config.status: creating man/Makefile config.status: creating mibs/Makefile config.status: creating net-snmp-config config.status: creating include/net-snmp/net-snmp-config.h config.status: executing default commands --------------------------------------------------------- Net-SNMP configuration summary: --------------------------------------------------------- SNMP Versions Supported: 1 2c 3 Net-SNMP Version: 5.2.1 Building for: linux Network transport support: Callback Unix TCP UDP SNMPv3 Security Modules: usm Agent MIB code: mibII ucd_snmp snmpv3mibs notification target agent_mibs agentx utilities host SNMP Perl modules: disabled Embedded perl support: disabled Authentication support: MD5 SHA1 Encryption support: DES AES --------------------------------------------------------- You can now compile your new package with the make command. The compilation process displays many messages, most of which you can ignore. In short, if it completes, you've succeeded and can proceed to installation. If not, you will see errors and should investigate what went wrong. Install your new package with the command make install. By default, this command installs various executables in /usr/local/bin and other important information in /usr/local/share/snmp. At this point, you can configure the agent further by using one of two approaches:
6.3.3.1. Running the configuration scriptThe configuration script is rather long and complex. Here are a few pointers:
6.3.3.2. Creating a configuration by handIf you don't want to use SNMPv3, creating your own configuration file is easy. Here's a very simple configuration file: syslocation "O'Reilly Data Center" syscontact snmpadmin@oreilly.com rwcommunity private rocommunity public authtrapenable 1 trapcommunity trapsRus trapsink nmshost.oreilly.com trap2sink nmshost.oreilly.com The configuration items should be familiar: we're setting up the system location; the system contact; the read-write, read-only, and trap community strings; and the destination to which traps should be sent. We're also enabling authentication traps. Note that we configured destinations for both SNMP Version 1 and Version 2 traps. The trap destination lines (trapsink and trap2sink) can also have a trap community string, if the NMS at the given host requires a different community name. The rwcommunity and rocommunity lines allow us to be a bit more sophisticated than the example indicates. We're allowed to specify the network or subnet to which the community strings apply, and an object ID that restricts queries to MIB objects that are underneath that OID. For example, if you want to restrict read-write access to management stations on the subnetwork 10.0.15.0/24, you could use the line: rwcommunity private 10.0.15.0 If you take this route, you should certainly look at the EXAMPLE.conf file in the directory in which you built Net-SNMP . You can modify this file and install it in the appropriate location (either ~/.snmp/snmpd.conf or /usr/local/share/snmp/snmpd.conf ), or you can take ideas from it and use them in your own configuration. It includes some particularly clever tricks that we'll discuss in Chapter 10 (they are well beyond the simple configuration we're discussing here). Finally, let's look at configuring Net-SNMP to use SNMPv3 . We'll also discuss a few utility commands that can help make managing the various security options much easier. Keep in mind that because of its security features, SNMPv3 is user based. Even though you may not want to use authentication or privacy , you may still need to provide a username, even if it is blank.
To create a user named kschmidt who has read-write access to the system subtree, add the following line to your snmpd.conf file: rwuser kschmidt auth system To create a user with read-only access, use the command rouser instead of rwuser. The auth keyword requests secure authentication, but not privacy: the SNMP packets themselves aren't encrypted. The other possibilities are noauth (no authentication and no privacy) and priv (authentication and privacy). Now add the following line to /usr/local/share/snmp/snmpd.conf: createUser kschmidt MD5 mysecretpass This creates an MD5 password for the user kschmidt. The password assigned to kschmidt is mysecretpass. To create a user with a DES passphrase in addition to an MD5 password, add the following line to /usr/local/share/snmp/snmpd.conf: createUser kschmidt MD5 mysecretpass DES mypassphrase If you omit mypassphrase, Net-SNMP sets the DES passphrase to be the same as the MD5 password. The RFCs for SNMPv3 recommend that passwords and passphrases be at least eight characters long; Net-SNMP enforces this recommendation and won't accept shorter passwords. When the agent is started, it reads the configuration file and computes secret keys for the users you have added. Now we can perform an snmpwalk using Version 3 authentication. The following command specifies Version 3, with the username kschmidt, requesting authentication without privacy using the MD5 algorithm . The password is mysecretpass: $ snmpwalk -v 3 -u kschmidt -l authNoPriv -a MD5 -A mysecretpass \ server.ora.com system.sysDescr.0 = Linux server 2.2.14-VA.2.1 #1 Mon Jul 31 21:58:22 PDT 2000 i686 system.sysObjectID.0 = OID: enterprises.ucdavis.ucdSnmpAgent.linux system.sysUpTime.0 = Timeticks: (1360) 0:00:13.60 system.sysContact.0 = "Ora Network Admin" system.sysName.0 = server system.sysLocation.0 = "Atlanta, Ga" system.sysServices.0 = 0 system.sysORLastChange.0 = Timeticks: (0) 0:00:00.00 system.sysORTable.sysOREntry.sysORID.1 = OID: ifMIB ... UDP-MIB::udpOutDatagrams.0 = No more variables left in this MIB View (It is past the end of the MIB tree) Note that we see only objects from the system subtree, even though the command tries to walk the entire tree. This limitation occurs because we have given kschmidt access only to the system subtree. If kschmidt tries to query a subtree he is not allowed to access, he gets the following result: $ snmpwalk -v 3 -u kschmidt -l authNoPriv -a MD5 -A mysecretpass \ server.ora.com interfaces IF-MIB::interfaces = No Such Object available on this agent at this OID If you want privacy in addition to authentication, use a command like this: $ snmpwalk -v 3 -u kschmidt -l authPriv -a MD5 -A mysecretpass -x DES -X \ mypassphrase server.ora.com 6.3.3.3. Using snmpusm to manage usersThe Net-SNMP utility snmpusm is used to maintain SNMPv3 users. This utility can be very useful when it comes to managing and creating users on the fly.
The following command creates the user kjs by cloning the kschmidt user: $ snmpusm -v 3 -u kschmidt -l authNoPriv -a MD5 -A mysecretpass localhost create \ kjs kschmidt Since kjs was cloned from kschmidt, the two users now have the same authorization, password, and passphrase. It's obviously essential to change kjs's password. To do so, use snmpusm with the -Ca option. Similarly, to change the privacy passphrase, use -Cx. The following two commands change the password and passphrase for the new user kjs: $ snmpusm -v 3 -l authNoPriv -u kschmidt -a MD5 -A mysecretpass localhost -Ca passwd mysecretpass mynewpass kjs $ snmpusm -v 3 -l authPriv -u kschmidt -a MD5 -A mysecretpass localhost -Cx passwd mypassphrase mynewphrase kjs There are many things to note about this seemingly simple operation:
For the user to be written to the persistent snmpd.conf file, you must either stop and restart the agent or send a HUP signal to the snmpd process. This forces the agent to write the current state of the user table to disk, so the agent can reread it upon startup. Note that using kill -9 does not produce the desired result. The snmpusm command exists primarily to allow end users to manage their own passwords and passphrases. As the administrator, you may want to change your users' passwords and passphrases periodically. This is possible only if you keep a master list of users and their passwords and passphrases. If the engine ID changes, you will have to regenerate all the usernames, passwords, and passphrases. (Remember that the engine ID depends in part on the host's IP address and therefore changes if you have to change the address.) To do this, stop the agent and edit the /var/net-snmp/snmpd.conf file. Remove all the persistent usmUser enTRies and add new createUser commands (as described previously) for your users. A usmUser enTRy looks something like this: usmUser 1 3 0x80001f8880389a8f7c2f5ba342 0x6b6a7300 0x6b6a7300 NULL .1.3.6.1.6.3.10.1.1.2 0x0ecdaf0c88993c416bd8f0a555a11a3a .1.3.6.1.6.3.10.1.2.2 0xf64fee1207d9a959e53c47398e05e872 "" 6.3.4. Concord SystemEDGE Agent for Unix and WindowsConcord SystemEDGE is a commercial product that can be used as a subagent to the standard Windows agent. On Unix systems, this agent can be used either as a standalone agent or side by side with an existing agent. It runs on Linux, Solaris, and other operating systems. The CD on which the product is shipped includes agents for all the platforms SystemEDGE supports. Whenever possible, SystemEDGE uses the platform's native package manager to make installation easier. Each architecture-dependent version of the agent comes with an easy-to-follow README file for installation. See Chapter 10 for a discussion of this agent's capabilities. 6.3.4.1. Simple configurationThe SystemEDGE configuration file is located in /etc/sysedge.cf. Use your editor of choice to make changes to this file. You must stop and restart SystemEDGE for your changes to take effect. The configuration file format is the same for all the versions of SystemEDGE . For a typical SNMP configuration, sysedge.cf looks like this: community public read-only community veryprivate read-write 127.0.0.1 10.123.56.25 community traps 127.0.0.1 Comment lines begin with a # character. The first parameter sets the read-only community to public. The read-write community is defined to be veryprivate. The two IP addresses following the read-write community string are an access list that tells the agent to allow set operations from localhost (127.0.0.1) and 10.123.56.25 only. Always use an access list if possible; without this security feature, any host can execute set operations. Note that there is a space between the two addresses, not a Tab character. The third option tells the agent where to send traps; in this case, to localhost (127.0.0.1). The agent sends authentication-failure traps by default, and we strongly recommend using them. If you don't want authentication-failure traps, include the following line in your configuration file: no_authen_traps 6.3.4.2. Advanced configurationSystemEDGE provides some powerful self-monitoring capabilities . These extensions (found only in Concord's Empire private enterprise MIB) are similar to the RMON MIB, which is discussed in Chapter 8. Empire's extensions can reduce network load by allowing the agent, rather than an NMS, to perform monitoring (polling) of important system objects. For example, the agent can be instructed to make sure the free space available in the root filesystem stays above some predefined threshold. When this threshold is crossed, the agent sends a trap to the NMS so that the condition can be dealt with appropriately. The following line shows how you can monitor and restart sendmail if it dies: watch process procAlive 'sendmail' 1 0x100 60 'Watch Sendmail' '/etc/init.d/sendmail start' This monitor sends a trap to the NMS, defined earlier as community traps 127.0.0.1, when the sendmail process dies. The agent then executes /etc/init.d/sendmail start to restart the process. The general form of this command is: watch process procAlive 'procname' index flags interv 'description' 'action' The procname parameter is a regular expression that SystemEDGE uses to select the processes that it is monitoring; in this case, we're watching processes with the name sendmail. Each entry in the process-monitoring table must have a unique index; in this example, we used the value 1. We could have picked any integer, as long as that integer was not already in use in the table. The flag parameter is a hexadecimal[*] flag that changes the behavior of the monitor. We specified a flag of 0x100, which tells the monitor that the process it's watching spawns child processes; this flag ensures that SystemEDGE will take action only when the parent sendmail process dies, not when any of the children die. The use of process-monitor flags is beyond the scope of this chapter; see the manual that comes with SystemEDGE for more information. The interv parameter specifies how often (in seconds) the agent checks the process's status. We have set the interval to 60 seconds. The description parameter contains information about the process being monitored; it can be up to 128 characters in length. It is a good idea to use a description that indicates what is being monitored, since the agent stores this value in the monitor table for retrieval by an NMS and includes it in the variable bindings when a trap is sent. The final parameter is the action the monitor will take when the process dies; we chose to restart the daemon.
SystemEDGE can be extended by using plug-ins . These plug-ins manage and monitor applications such as Apache (web server), Exchange (Microsoft mail), and Oracle (database), to name a few. A "top processes" plug-in named topprocs comes with every distribution. The following statement tells SystemEDGE to load this plug-in for 64-bit Solaris (this statement is similar for other Unix platforms, and for Windows): sysedge_plugin /opt/EMPsysedge/plugins/topprocs/topprocs-sol64bit.so The folks at Concord have taken great care to add useful comments to the sysedge.cf file. The comments are often all you need to configure the agent. 6.3.5. Cisco DevicesCisco Systems produces a wide range of routers, switches, and other networking equipment. The configuration process is virtually the same on all Cisco devices , because they share the IOS operating system.[
To configure the SNMP parameters, you must be in enable mode. You can use the following commands to see what traps are available: router> enable Password: mypassword router# config terminal router(config)# snmp-server enable traps ? bgp Enable BGP state change traps envmon Enable SNMP environmental monitor traps frame-relay Enable SNMP frame-relay traps isdn Enable SNMP isdn traps <cr> The question mark tells the router to respond with the possible completions for the command you're typing. You can use this feature throughout the entire command-line interface. If the part of the command you have already typed has a syntax error, the router will give you the "Unrecognized command" message when you type the question mark. <cr> tells you that you can exit without configuring the command (snmp-server enable traps in this case) by pressing Return. 6.3.5.1. Simple configurationHere's a simple configuration that lets you start using the SNMP agent: router(config)# snmp-server community private RW router(config)# snmp-server community public RO router(config)# snmp-server trap-authentication router(config)# snmp-server location Delta Building - 1st Floor router(config)# snmp-server contact J Jones router(config)# snmp-server host 10.123.135.25 public Most of these commands set parameters with which you should be familiar by now. We define two communities, public and private, with read-only (RO) and read-write (RW) permissions, respectively. snmp-server trap-authentication turns on authentication-failure traps. The command snmp-server host 10.123.135.25 public configures the destination to which traps should be sent. The IP address is set to the address of our NMS. The community string public will be included in the traps. 6.3.5.2. Advanced configurationThe following configuration item tells the device what interface it should use when sending out SNMP traps: router(config)# snmp-server trap-source VLAN1 Configuring the trap source is useful because routers, by definition, have multiple interfaces. This command allows you to send all your traps out through a particular interface. There may be times when you want to send only certain traps to your NMS. The next item sends only environmental monitor traps to the specified host, 172.16.52.25 (the envmon option is not available on all Cisco devices ): router(config)# snmp-server host 172.16.52.25 public envmon One of the most frightening SNMP sets is the Cisco shutdown, which lets you shut down the router from the NMS. The good news is that you have to include a switch in the configuration before the router will respond to shutdown commands. Issuing the following command disables shutdowns: router(config)# no snmp-server system-shutdown To receive traps about authentication failures (something trying to poll your device with the wrong community name), add the following line: router(config)# snmp-server trap-authentication The final advanced configuration parameter is an access list. The first line sets up access list 15. It states that the IP address 10.123.56.25 is permitted to access the agent. The second line says that anyone that passes access list 15 (i.e., a host with IP address 10.123.56.25) and gives the community name notsopublic has read-only (RO) access to the agent. Access lists are a very powerful tool for controlling access to your network. They're beyond the scope of this book, but if you're not familiar with them, you should be. router(config)# access-list 15 permit 10.123.56.25 router(config)# snmp-server community notsopublic RO 15 6.3.5.3. Configuring SNMPv3The first task in configuring SNMPv3 is to define a view. To simplify things, we'll create a view that allows access to the entire internet subtree: router(config)# snmp-server view readview internet included This command creates a view called readview. If you want to limit the view to the system tree, for example, replace internet with system. The included keyword states that the specified tree should be included in the view; use excluded if you want to exclude a certain subtree. Next, create a group that uses the new view. The following command creates a group called readonly; v3 means that SNMPv3 should be used. The auth keyword specifies that the entity should authenticate packets without encrypting them; read readview says that the view named readview should be used whenever members of the readonly group access the router. router(config)# snmp-server group readonly v3 auth read readview Now let's create a user. The following command creates a user called kschmidt, who belongs to the readonly group. auth md5 specifies that the router should use MD5 to authenticate the user (the other possibility is sha). The final item on the command line is the user's password or passphrase, which cannot exceed 64 characters. router(config)# snmp-server user kschmidt readonly v3 auth md5 mysecretpass This configuration uses encryption only to prevent passwords from being transferred in the clear. The SNMP packets themselves, which may contain information that you don't want available to the public, are sent without encryption and can therefore be read by anyone who has a packet sniffer and access to your network. If you want to go a step further and encrypt the packets themselves, use a command like this: router(config)# snmp-server user kschmidt readonly v3 auth md5 mysecretpass \ priv des56 passphrase The additional keywords on this command specify privacy (i.e., encryption for all SNMP packets), use of DES 56-bit encryption, and a passphrase to use when encrypting packets. The encrypted passwords and passphrases depend on the engine ID, so if the engine ID changes, you'll need to delete any users you have defined (with the familiar IOS no command), and re-create them (with snmp-server user commands). Why would the engine ID change? It's possible to set the engine ID on the IOS command line. You should never need to set the engine ID explicitly, but if you do, you'll have to delete and re-create your users. This has been the briefest of introductions to configuring SNMPv3 on a Cisco router. For more details, see Cisco's documentation, which is available at http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t3/snmp3.htm. That's it! You now have a working SNMP configuration for your Cisco router. 6.3.6. APC SymetraAPC's uninterruptible power supplies (UPSs ) are typical of a large class of products that aren't usually considered network devices, but that have incorporated a network interface for the purpose of management. To configure an APC UPS, you can use its management port (a familiar serial port to which you can connect a console terminal) or, assuming that you've performed basic network configuration, telnet to the UPS's IP address. SNMP configuration is the same regardless of the method you use. Either way, you get a Text User Interface (TUI) that presents you with rather old-fashioned menusyou type your menu selection (usually a number) followed by Enter to navigate through the menus. We'll assume that you've already performed basic network configuration, such as assigning an IP address for the UPS. To configure SNMP, go to the Network menu and select 5 to go into the SNMP submenu. You should get a menu like this: ------- SNMP ------------------------------------------------------------ 1- Access Control 1 2- Access Control 2 3- Access Control 3 4- Access Control 4 5- Trap Receiver 1 6- Trap Receiver 2 7- Trap Receiver 3 8- Trap Receiver 4 9- System 10- Summary ?- Help <ENTER> Redisplay Menu <ESC> Return To Previous Menu > You need to configure three distinct sections: Access Control, Trap Receiver, and System. To see a summary of the current SNMP settings, use the Summary submenu. This particular device allows us to specify four IP addresses for access control and four IP addresses to receive traps. The access control items allow you to configure the IP addresses of your management stationsthis is similar to the access lists we've seen in other devices, and is obviously basic to security. The UPS will reply only to queries from the IP addresses you have listed. Configuration is a bit awkwardyou need to go to a separate menu to configure each IP address. Here's what you'll see when configuring the Access Control 1 submenu: ------- Access Control 1 ------------------------------------------------ Access Control Summary # Community Access NMS IP ----------------------------------------------------------------- 1 public Read 10.123.56.25 2 private Write 10.123.56.25 3 public2 Disabled 0.0.0.0 4 private2 Disabled 0.0.0.0 1- Community : public 2- Access Type : Read 3- NMS IP Address : 10.123.56.25 4- Accept Changes : ?- Help <ENTER> Redisplay Menu <ESC> Return To Previous Menu > The first part of the menu summarizes the state of access control. On this menu, we can change only the first item on the list. The special address 0.0.0.0 is a wildcardit means that the UPS will respond to queries from any IP address. Although addresses 3 and 4 are set to 0.0.0.0, these addresses are currently disabled, and that's how we want to keep them. We want the UPS to respond only to the management stations we explicitly list. On this menu, we've configured items 1 (the community string), 2 (the access type), and 3 (the IP address). We've set the community string to public (not a choice you'd want in a real configuration), the access type to Read (allowing various SNMP get operations, but no set operations), and the NMS IP address to 10.123.56.25. The net effect is that the UPS's SNMP agent will accept get requests from IP address 10.123.56.25 with the community name public. When you are satisfied with the configuration, enter a 4 to accept your changes. To configure the second access control item, press Esc to return to the previous menu; then select 2. As you can see, we allow 10.123.56.25 to perform set operations. We don't have any other management stations, so we've left items 3 and 4 disabled. Once the Access Control section is complete, you can start configuring traps. The Trap Receivers section is simply a list of NMSs that receive traps. As with Access Control, four trap receivers can be configured. To get to the first trap receiver, return to the SNMP menu and select menu 5. A typical trap receiver setup looks like this: ------- Trap Receiver 1 ------------------------------------------------- Trap Receiver Summary # Community Generation Authentication Receiver NMS IP ----------------------------------------------------------------------- 1 public Enabled Enabled 10.123.56.25 2 public Enabled Enabled 0.0.0.0 3 public Enabled Enabled 0.0.0.0 4 public Enabled Enabled 0.0.0.0 1- Trap Community Name : public 2- Trap Generation : Enabled 3- Authentication Traps: Enabled 4- Receiver NMS IP : 10.123.56.25 5- Accept Changes : ?- Help <ENTER> Redisplay Menu <ESC> Return To Previous Menu > Once again, the first part of the menu is a summary of the trap receiver configuration. We've already set the first trap receiver to the address of our NMS, enabled trap generation, and enabled the generation of authentication trapsas always, a good idea. The traps we generate will include the community string public. Note that trap receivers 2, 3, and 4 are set to 0.0.0.0. On this menu, 0.0.0.0 is not a wildcard; it's just an invalid address that means you haven't yet configured the trap receiver's IP address. It's basically the same as leaving the entry disabled. The final configuration items that should be set are on the System submenu, found under the SNMP main menu: ------- System ---------------------------------------------------------- 1- sysName : ups1.ora.com 2- sysContact : Douglas Mauro 3- sysLocation : Apache Hilo Deck 4- Accept Changes : ?- Help <ENTER> Redisplay Menu <ESC> Return To Previous Menu > After you have finished configuring all your SNMP parameters, use the Summary submenu for a quick look at what you have done. A typical setup will look something like this: ------------------------------------------------------------------------- SNMP Configuration Summary sysName : ups1.ora.com sysLocation : Apache Hilo Deck sysContact : Douglas Mauro Access Control Summary # Community Access NMS IP ----------------------------------------------------------------- 1 public Read 10.123.56.25 2 private Write 10.123.56.25 3 public2 Disabled 0.0.0.0 4 private2 Disabled 0.0.0.0 Trap Receiver Summary # Community Generation Authentication Receiver NMS IP -------------------------------------------------------- 1 public Enabled Enabled 10.123.56.25 2 public Enabled Enabled 0.0.0.0 3 public Enabled Enabled 0.0.0.0 4 public Enabled Enabled 0.0.0.0 Press <ENTER> to continue... Upon completion and verification, use the Esc key to take you all the way out to the Logout menu. |
] There are some minor differences in the parameters that can be configured on every device; these generally have to do with the capabilities of the device, rather than the SNMP implementation.
] There are some exceptions to this rule, such as the PIX firewalls . These exceptions usually mean that the product is made by a company that Cisco acquired.
EAN: 2147483647
Pages: 165