Using the Rudimentary Management System


The sample program can, if required, be run on the same host as the SNMP agent, as illustrated in Figure 7-3.

Figure 7-3. Processes and hosts in the rudimentary management system.

graphics/07fig03.gif

Alternatively, the program can be run using an SNMP agent on a remote machine.

Please Note For Running The Visual C++ Program

  1. We use just a single SNMP community string called public. Normally, you can expect to see at least two community strings ”one for gets, called public, and one for sets, called private. We omitted this to reduce the complexity. Changing the batch files for this would be a good exercise because it would also be required to create the private community string in the agent configuration and to assign read-write capability.

  2. Only one change is required ”the user must supply the IP address or DNS name for the SNMP agent host in each of the supplied batch files. For example, in the batch file Get.bat (see Figure 7-5), replace the word myHostPC with the IP address or DNS name of your SNMP agent host.

  3. The required platform for running the program is either Windows 2000 or NT.

MIB Table Used in the Examples

The MIB-II system table is used in our examples and is illustrated in Figure 7-4.

Figure 7-4. The MIB-II system table.

graphics/07fig04.gif

Figure 7-4 can be consulted during the following sections. The syntax for specifying MIB objects in the Microsoft SNMP API is to prefix each leaf with a period, starting with .iso . This is seen in the next section.

An SNMP GET

Double-clicking the batch file Get.bat (or running it from a command line) should result in a display similar to that shown in Figure 7-5.

Figure 7-5 GET operation on system.sysContact.0 .
 Debug\snmpmgr.exe GET myHostPC public  .iso.org.dod.internet.mgmt.mib-2.system.sysContact.0 < SNMP Operation Type GET > < MIB Object Instance = system.sysContact.0 > < Type and Value = String StephenM > 

Figure 7-5 illustrates a GET operation on a specific instance (zero in this case) of a columnar object from the standard system table ”in this case, system.sysContact . We must specify the instance explicitly by appending a zero. The value of the returned object is illustrated as StephenM .

An SNMP GETNEXT

Double-clicking the batch file GetNext.bat (or running it from a command line) should result in a display similar to that shown in Figure 7-6.

Figure 7-6 GETNEXT operation on system.sysContact.0 .
[View full width]
 Debug\snmpmgr.exe GETNEXT myHostPC public .iso.org.dod.internet.mgmt.mib-2.system. graphics/ccc.gif sysContact.0 < SNMP Operation Type GETNEXT > < MIB Object Instance = system.sysName.0 > < Type and Value = String myHostPC > 

Figure 7-6 illustrates a GETNEXT operation on the sysContact object . Instead of returning StephenM , as in the last example, we receive the host system name. This is the lexical successor to the sysContact object, as can be seen from Figure 7-4.

An SNMP SET

We now move to a different category of SNMP operation, that of setRequest . This pushes data into the MIB of the remote agent. Interestingly, providing a set capability like this is often considered controversial because of security fears. These fears are generally well-founded, but we present sets here only in order to describe the principles, leaving aside any political issues. In this example, we set the value of the sysContact name to be StephenMorris . Recall from the GET example above that the value of this object is currently StephenM . Double-clicking the batch file Set.bat (or running it from a command line) should result in a display similar to that shown in Figure 7-7. We can verify that the operation succeeded by simply running Get.bat again.

Figure 7-7 SET operation on the system.sysContact.0 .
[View full width]
 Debug\snmpmgr.exe SET myHostPC public .iso.org.dod.internet.mgmt.mib-2.system.sysContact. graphics/ccc.gif 0 StephenMorris < SNMP Operation Type SET > < MIB Object Instance = system.sysContact.0 > < Type and Value = String StephenMorris > 

Figure 7-7 illustrates a SET operation on the system.sysContact.0 object.

Walking a MIB Table

Suppose we want to get an idea of the MIB objects supported by a given agent, starting at a specific point in the tree. An SNMP walk provides this capability by traversing the MIB tree leaf objects until the end of that branch is reached. This is useful for retrieving tables (of unknown extent). Double-clicking the batch file Walk.bat (or running it from a command line) should result in a display similar to that shown in Figure 7-8. This is achieved by a dialog between the manager and the agent in which the former keeps sending GETNEXT messages until the end of the MIB table is reached.

Figure 7-8 A MIB WALK on the system table.
 Debug\snmpmgr.exe WALK myHostPC public .iso.org.dod.internet.mgmt.mib-2.system < Variable = system.sysDescr.0 > < Value    = String Hardware: x86 Family 6 Model 8 > < Variable = system.sysObjectID.0 > < Value    = ObjectID 1.3.6.1.4.1.311.1.1.3.1.1 > < Variable = system.sysUpTime.0 > < Value    = TimeTicks 1889968 >  < Variable = system.sysContact.0 > < Value    = String StephenMorris > < Variable = system.sysName.0 > < Value    = String myHostPC > < Variable = system.sysLocation.0 > < Value    = String Europe > < Variable = system.sysServices.0 > < Value    = Integer32 76 > < End of MIB subtree. > 

Figure 7-8 illustrates a WALK of the system table. Referring to Figure 7-4, it can be seen that all the columns in this table are retrieved up to and including the last object, sysServices .

An SNMP TRAP

The manager program can also be configured to listen for SNMP traps. This is illustrated by running the batch file GetTraps.bat . This puts the manager into listening mode, as can be seen in Figure 7-9. Next, we must simulate a trap. This can be done by simply stopping and starting the SNMP service, which results in the agent sending three traps, as illustrated in the bottom half of Figure 7-9.

Figure 7-9 Listening for and receiving SNMP traps.
 Debug\snmpmgr.exe TRAP < snmputil: listening for traps. > ***** THE PROGRAM IS NOW AWAITING THE ARRIVAL OF TRAPS ***** ***** WE NOW STOP AND THEN START THE SNMP SERVICE ***** snmputil: trap generic=0 specific=0  from -> 127.0.0.1  *** TRAP 1 snmputil: trap generic=3 specific=0  from -> 127.0.0.1  *** TRAP 2 Variable = interfaces.ifTable.ifEntry.ifIndex.1 Value    = Integer32 1 snmputil: trap generic=3 specific=0  from -> 127.0.0.1  *** TRAP 3 Variable = interfaces.ifTable.ifEntry.ifIndex.16777219 Value    = Integer32 16777219 

Let's take a closer look at what's going on in Figure 7-9. Trap 1 has both generic and specific code values of zero, indicating that this is a coldStart , that is, the agent has restarted. This is a direct response to stopping and starting the SNMP service. The origin of this trap is the loopback IP address (127.0.0.1), indicating that the agent is located on the same host as the manager. Traps 2 and 3, respectively, have generic and specific codes of three and zero, indicating linkUp events. These relate to entries in the host system interfaces MIB table ( ifTable ). Two interfaces are present on the host machine (indicated by the MIB object ifNumber , which has the value 2 and is not shown); one is the software loopback interface (127.0.0.1), and the other is an Ethernet interface (16777219). When these interfaces go into the up state, the agent detects it and emits traps 2 and 3.

Combining the Batch Files

It is easy enough to chain these batch files together (or write entirely new ones) to carry out multiple operations in sequence ”for example, to execute a SET followed by a GET . A real NMS tends to use a rich mix of all types of SNMP operations, for example, manipulating a range of scalar and tabular objects on a number of agents (as we'll see in Chapter 8).

A Security Violation

Security is increasingly important in network management. We now acknowledge this with a specific example of a simple security violation by using the wrong community name. This is equivalent to entering the wrong password during a login procedure. Modifying the community name in one of the batch files achieves the desired result. The remote agent should do two things:

  • Discard the message so that no reply should occur ”this gives no clue to a hacker that he or she has supplied an incorrect community name.

  • Emit an authenticationFailure(4) trap ”this informs the NMS operator that an intruder alert has occurred.

In a real network with stronger security (such as SNMPv3), the intruder might be attempting more sophisticated actions, such as replaying a captured message into an agent. In this case, the security system in the agent would rely on more advanced protection facilities, such as message timeliness checking. However, we illustrate the simple (wrong community string) case just to give a flavor of what might occur in a real network.

To see this, we must configure one session of the program to listen for traps and another to issue an improper SNMP Get. Figure 7-10 illustrates the GET with a modified (and invalid) community string of public1 (instead of public ).

Figure 7-10 Security failure and associated actions.
 Debug\snmpmgr.exe GET myHostPC public1 .iso.org.dod.internet.mgmt.mib-2.system.sysContact.0 < error on SnmpMgrRequest 8 > < SNMP Operation Type GET > < MIB Object Instance = system.sysContact.0 > < Type and Value = Null value > 

In Figure 7-10, we see a Microsoft Visual C++ SNMP API error value of 8, indicating a problem with the submitted message.

If we initiate another instance of the program in trap mode (before running the Get in Figure 7-10), we see an interesting sequence of events, as illustrated in Figure 7-11. Four traps are received from the loopback address. So, what's happening here, and why do we see four traps?

Figure 7-11 Security violations and retries.
 Debug\snmpmgr.exe TRAP < snmputil: listening for traps... > < snmputil: trap generic=4 specific=0 from -> 127.0.0.1 > < snmputil: trap generic=4 specific=0 from -> 127.0.0.1 > < snmputil: trap generic=4 specific=0 from -> 127.0.0.1 > < snmputil: trap generic=4 specific=0 from -> 127.0.0.1 > 

Recall from Figure 7-2 that the program implements a retry mechanism (the RETRIES symbolic constant in snmpdefs.h ). A maximum of three retries is allowed. So, the first GetRequest is sent to the agent. This message has an invalid community string and is discarded. The agent also issues a trap with a generic code of 4 (indicating an authenticationFailure ). This explains the first trap. Our manager code is not very sophisticated and fails to correlate the authentication failure trap with the bad GetRequest message. Having failed to get the expected response, the manager then transparently (via the SNMP library code) retries the operation a total of three more times; this results in three more traps before the manager code finally gives up. This explains the sequence of four traps in Figure 7-11. One final point about Figure 7-11 is that the timeout mechanism is also initiated as a result of the (attempted) security breaches. Again from Figure 7-2, we note that there is a timeout defined as 6,000 milliseconds or 6 seconds. This is the time between retries and explains the small delays between the occurrence of the traps in Figure 7-11.



Network Management, MIBs and MPLS
Network Management, MIBs and MPLS: Principles, Design and Implementation
ISBN: 0131011138
EAN: 2147483647
Year: 2003
Pages: 150

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net