# Compaq TCP/IP Services for OpenVMS
SNMP Programming and Reference

Previous | Contents | Index

The `-i` , `-r` , and `-s` flags apply to individual queries. If you specify the `-l` or `-t` flags also, the values for the `-i` , `-r` , and `-s` flags are applied to each iteration.

## 4.1.3 MIB Browser Data Types

The `snmp_request` and `snmp_trapsnd` commands support the data types listed in Table 4-3. These values apply to `Set` requests only.

Table 4-3 Data Types for the snmp_request and snmp_trapsnd Commands
Data Type | Value
--- | ---
Counter | `-c`
Counter64 1 | `-l`
Display string | `-D`
Gauge | `-g`
Integer | `-i`
IP address | `-a`
NULL | `-N`
Object identifier | `-d`
Octet | `-o`
Opaque string | `-q`
Time ticks | `-t`

1For support of trap sender program (TCPIP$SNMP_TRAPSND.EXE) only. Properly defined, MIB variables of type Counter64 are not writable.

Note Except for `-l` (Counter64), the data types are case sensitive. To preserve uppercase for display strings and NULL, enclose the value in double quotation marks. For example, "-- `D` " or "-- `N` ".

On OpenVMS Alpha systems, you must specify the value of the `-l` data type as a 64-bit integer. For example:

    $ snmp_trapsnd 0.0 mynode 6 33 100 -h mynode -v2c -
    _$ 1.3.6.1.2.1.1.4.0 "l" 1311768467294899695

On OpenVMS VAX systems, you must specify the value of the `-l` data type as a 16-digit hexadecimal value. For example:

    $ snmp_trapsnd 0.0 mynode 6 33 100 -h mynode -v2c -
    _$ 1.3.6.1.2.1.1.4.0 "l" 0x1234567890ABCDEF

Note that alphabetic characters are not case sensitive when used with the `-l` data type.

For more information about the data types, see RFCs 1155 and 1902.

## 4.1.4 Command Examples for snmp_request

This section presents several examples of using the `snmp_request` utility. In the following `snmp_request` command examples:

- The valid host name is `marley.dec.com` .
- The `"public"` community is type Read, address 0.0.0.0.
- The `"address_list"` community is type Read and Write, with write access for the host on which the `snmp_request` program is running.
- The `location` has been specified as shown in the following command:

      TCPIP> SET CONFIGURATION SNMP -
      _TCPIP> /LOCATION=(FIRST="Falcon Building",SECOND="Los Angeles, CA")

- The command responses have been edited for readability.

Examples

1. The following example shows how to retrieve the value of the MIB II variable `sysDescr.0 (1.3.6.1.2.1.1.1.0)` . The request is successful because the OID ( `variable_name` ) provided in the command line exists and is readable. This OID is returned by the subagent code that resides in the master agent.

       $ snmp_request marley.dec.com "public" get 1.3.6.1.2.1.1.1.0

       1.3.6.1.2.1.1.1.0 = marley.dec.com AlphaServer 2100 4/200 OpenVMS
           V7.1 Digital TCP/IP Services for OpenVMS

2. The following example shows how to retrieve two MIB II variables. This example is identical to the previous example, except that two OID values are input and two returned: instance 1 of `ifDescr` and `hrSystemUptime` . Note that the first value comes from the MIB II subagent (TCPIP$OS_MIBS) and the second comes from the Host Resources MIB subagent (TCPIP$HR_MIB).

       $ snmp_request marley.dec.com "public" get 1.3.6.1.2.1.2.2.1.2.1 -
       _$ 1.3.6.1.2.1.25.1.1.0

       1.3.6.1.2.1.2.2.1.2.1 = LO IP Interface: LO0, OpenVMS Adapter: <none>,
             Loopback Port
       1.3.6.1.2.1.25.1.1.0 = 6024942 = 0 d 16:44:9

3. The following example shows how to retrieve the next MIB II variable. This is similar to the command in example 1, except that a `GetNext` request is issued and `sysObjectID.0` (1.3.6.1.2.1.1.2.0) is returned.

       $ snmp_request marley.dec.com "public" getnext 1.3.6.1.2.1.1.1.0

       1.3.6.1.2.1.1.2.0 = 1.3.6.1.4.1.36.2.15.13.7.1

4. The following example shows how to use the SNMP Version 2 `GetBulk` request to retrieve the MIB II variables `sysUpTime.0` (1.3.6.1.2.1.1.1.0) and `sysDescr.0` (1.3.6.1.2.1.1.2.0), and for the first three interfaces, the values of `ifDescr` (OIDs with the prefix 1.3.6.1.2.1.2.2.1.2) and `ifType` (OIDs with the prefix 1.3.6.1.2.1.2.2.1.3).

       $ snmp_request marley.dec.com "public" getbulk -n 2 -m 3 -
       _$ 1.3.6.1.2.1.1.1 1.3.6.1.2.1.1.2 -
       _$ 1.3.6.1.2.1.2.2.1.1 1.3.6.1.2.1.2.2.1.2 1.3.6.1.2.1.2.2.1.3

       Warning: using version SNMPv2 for getbulk command.
       1.3.6.1.2.1.1.1.0 = marley.dec.com AlphaStation 255/300
           OpenVMS V7.1 Digital TCP/IP Services for OpenVMS
       1.3.6.1.2.1.1.2.0 = 1.3.6.1.4.1.36.2.15.13.7.1
       1.3.6.1.2.1.2.2.1.1.1 = 1
       1.3.6.1.2.1.2.2.1.2.1 = LO IP Interface: LO0, OpenVMS Adapter: <none>,
           Loopback Port
       1.3.6.1.2.1.2.2.1.3.1 = 24
       1.3.6.1.2.1.2.2.1.1.3 = 3
       1.3.6.1.2.1.2.2.1.2.3 = WE IP Interface: WE0, OpenVMS Adapter: EWA0:,
           PCI bus Ethernet Adapter
       1.3.6.1.2.1.2.2.1.3.3 = 6
       1.3.6.1.2.1.2.2.1.1.4 = 4
       1.3.6.1.2.1.2.2.1.2.4 = WF IP Interface: WF0, OpenVMS Adapter: FWA0:,
           DEFPA PCI bus FDDI Adapter
       1.3.6.1.2.1.2.2.1.3.4 = 15

5. The following example shows how to use the `GetNext` request with the `-l` (loop) flag to retrieve all OIDs starting at the first instance after the OID input and finishing at the end of the MIB view. Note that if an SNMP Version 2 agent is the server, the results using `getbulk` are identical (in general, SNMP Version 1 agents do not support `getbulk` requests).

       $ snmp_request marley.dec.com "public" getnext -l 1.3.6.1.2.1.1.1.0

       1.3.6.1.2.1.1.2.0 = 1.3.6.1.4.1.36.2.15.13.7.1
       1.3.6.1.2.1.1.3.0 = 1280260 = 0 d 3:33:22
       1.3.6.1.2.1.1.4.0 = Sam Spade
       1.3.6.1.2.1.1.5.0 = marley.dec.com
       1.3.6.1.2.1.1.6.0 = Falcon BuildingLos Angeles, CA
       1.3.6.1.2.1.1.7.0 = 72
       1.3.6.1.2.1.1.8.0 = 0 = 0 d 0:0:0
       .
       .
       .
       1.3.6.1.2.1.25.5.1.1.2.294 = 560
       1.3.6.1.2.1.25.5.1.1.2.295 = 472
       1.3.6.1.6.3.1.1.6.1.0 = 1296505215
       - no such name - returned for variable 1

6. The following example uses the same command as in example 5, but it specifies the `-t` flag instead of the `-l` flag. Only OIDs with the prefix matching the input OID are returned. Note that as with other `getnext` request examples, the value for the input OID is not returned. If an SNMP Version 2 agent is the server, the results using `getbulk` are identical.

       $ snmp_request marley.dec.com "public" getnext -t 1.3.6.1.2.1.1

       1.3.6.1.2.1.1.2.0 = 1.3.6.1.4.1.36.2.15.13.7.1
       1.3.6.1.2.1.1.3.0 = 1302232 = 0 d 3:37:2
       1.3.6.1.2.1.1.4.0 = Sam Spade
       1.3.6.1.2.1.1.5.0 = marley.dec.com
       1.3.6.1.2.1.1.6.0 = Falcon BuildingLos Angeles, CA
       1.3.6.1.2.1.1.7.0 = 72
       1.3.6.1.2.1.1.8.0 = 0 = 0 d 0:0:0
       1.3.6.1.2.1.1.9.1.2.1 = 1.3.6.1.4.1.36.15.3.3.1.1
       1.3.6.1.2.1.1.9.1.2.2 = 1.3.6.1.4.1.36.15.3.3.1.2
       1.3.6.1.2.1.1.9.1.3.1 = Base o/s agent (OS_MIBS) capabilities
       1.3.6.1.2.1.1.9.1.3.2 = Base o/s agent (HR_MIB) capabilities
       1.3.6.1.2.1.1.9.1.4.1 = 0 = 0 d 0:0:0
       1.3.6.1.2.1.1.9.1.4.2 = 0 = 0 d 0:0:0

7. The following example shows how to send a `Set` request. The request succeeds because the command line specifies the correct type for the variable, and all the conditions for enabling `Set` requests are met on the server.

       $ snmp_request marley.dec.com "address_list" -
       _$ set 1.3.6.1.2.1.1.4.0 "D" "Richard Blaine"

       1.3.6.1.2.1.1.4.0 = Richard Blaine

8. The following example shows how to display the contents of packets that are sent and received. Note that only the SNMP-specific portion of the UDP packets is displayed.

       $ snmp_request marley.dec.com "public" get -d 1.3.6.1.2.1.1.4.0

       Sent:

        3082002D 02010004 06707562 6C6963A0   0..-.....public.
        2002047B E9C1BD02 01000201 00308200    ..{.........0..
        10308200 0C06082B 06010201 01040005   .0.....+........
        00                                    .

       Received:

        3082003B 02010004 06707562 6C6963A2   0..;.....public.
        2E02047B E9C1BD02 01000201 00308200   ...{.........0..
        1E308200 1A06082B 06010201 01040004   .0.....+........
        0E526963 68617264 20426C61 696E65     .Richard Blaine
       1.3.6.1.2.1.1.4.0 = Richard Blaine

# 4.2 Using the Trap Sender and Trap Receiver Programs

TCP/IP Services provides the following programs that allow you to set up a simple client on your system to send and receive trap messages:

- `snmp_trapsnd` (TCPIP$SNMP_TRAPSND.EXE)
  Sends SNMP Version 1 and SNMP Version 2 trap messages. Use only for testing or to send significant state changes that occur on the managed node.
- `snmp_traprcv` (TCPIP$SNMP_TRAPRCV.EXE)
  Listens for SNMP trap messages and displays any it receives.

By default, these programs use UDP port 162. However, you can specify another port with the `-p` flag or set up an SNMP-trap service that specifies the port you want to use. Note, however, that the use of UDP port 162 is coded into standard MIBs.

Both programs support the use of the UDP (default) and TCP transports. However, the standard TCP/IP subagents and the Chess example use UDP only. Therefore, if you specify the `-tcp` flag when you enter the `snmp_traprcv` command, the program uses TCP to process traps only from the trap sender program or from a user application written to use TCP.

The following sections explain how to enter commands for both programs. Because flags and data types are case sensitive, you should always enter them in the case that is specified. If a letter or value is specified as uppercase, you must enclose it in quotation marks. In general, if you use uppercase letters where lowercase is specified, the results are unpredictable. For example, flag `"-v2C"` functions correctly but flag `"-V2c"` does not, because the flag character ( `v` ) must be lowercase.

## 4.2.1 Entering Commands for the Trap Sender Program

The trap sender program lets you send SNMP Version 1 and SNMP Version 2 trap messages. You should use this program only when you want to test the client or when significant state changes occur on the managed node.

The trap sender program encodes an SNMP Version 1 trap PDU (see RFCs 1155, 1156, 1157, and 1215) or an SNMP Version 2 trap PDU (see RFCs 1905 and 1908) into an SNMP message and sends it to the specified hosts. You use parameters and flags to specify the data fields in the trap PDU.

Traps are uniquely identified in the PDU:

- SNMP Version 1 is identified by a combination of parameters.
- SNMP Version 2 is identified by the value of `snmpTrapOID` .

To run the trap sender program, do the following:

1. Define a foreign command for the program:

       $ snmp_trapsnd == "$SYS$SYSTEM:TCPIP$SNMP_TRAPSND"

   Alternatively, you can run the SYS$MANAGER:TCPIP$DEFINE_COMMANDS.COM procedure to define all the foreign commands available with TCP/IP Services.
2. Enter a command using the following format:

       snmp_trapsnd enterprise agent generic-trap specific-trap timeticks
       [-v version] [-c community] [-d] [-h host] [-p port] [-tcp]
       [variable_name [data-type value]]

### 4.2.1.1 Trap Sender Parameters

Table 4-4 describes the `snmp_trapsnd` parameters. Each parameter is required, but you can specify zero, as appropriate.

Table 4-4 Parameters for the snmp_trapsnd Command
Parameter | Description
--- | ---
`enterprise` | For SNMP Version 1, specifies the enterprise object identifier (OID) on whose behalf the trap is being sent. For example, 1.3.6.1.4.1.1. If you specify 0 or 0.0, the null OID (0.0) is sent. Make sure that any OID you specify conforms to the OID rules. For SNMP Version 2, when specified with the `-v2c` flag, represents the value of `snmpTrapOID.0` .
`agent` | For SNMP Version 1 traps. Specifies the host name or IP address of the entity on whose behalf the trap is being generated. You can specify the name `local` , which is the same as specifying 0, 0.0, 0.0.0, or 0.0.0.0. In these cases, the address 0.0.0.0 is sent as the agent address in the SNMP Version 1 trap PDU. If the `-v2c` flag is specified, this parameter is ignored.
`generic-trap` | For SNMP Version 1, specifies the generic trap identifier in the form of a number. Must be one of the following values:
SNMP Version 1 Value | Object
--- | ---
`0` | `coldStart`
`1` | `warmStart`
`2` | `linkDown`
`3` | `linkUp`
`4` | `authenticationFailure`
`5` | `egpNeighborLoss`
`6` | `enterpriseSpecific`
For SNMP Version 2, when the `-v2c` flag is specified, this parameter must contain a valid OID or 0 as the value of `snmpTrapOID` .
`specific-trap` | For SNMP Version 1, specifies the enterprise-specific trap number. A numeric value greater than 0 must be present but is ignored if the `-v2c` flag is present or if `generic-trap` is a value other than 6 ( `enterpriseSpecific` ).
`timeticks` | Specifies the timestamp value associated with the generation of the trap message. The timestamp value is the current time in units of TIMETICKS (1/100 of a second) since the sending SNMP entity started. A value of 0 causes `snmp_trapsnd` to send the time in hundredths of a second since the operating system was last booted.
`variable_name | data-type value` | Specifies a list of MIB variables to be included in the trap message. For a list of supported values, including a value for the `Counter64` data type, see Table 4-3.

### 4.2.1.2 Trap Sender Flags

Table 4-5 describes the `snmp_trapsnd` flags.

Table 4-5 Flags for the snmp_trapsnd Command
Flag | Description
--- | ---
`-c community` | Specifies a community string to be used when sending the trap. The default is public.
`-d` | Displays a hexadecimal dump of the encoded packet.
`-h host` | Specifies the host name or IP address (in ASN.1 dot notation format) of the destination host to receive the trap message. The default is `localhost` (127.0.0.1).
`-p port` | Specifies a port number on the destination host where the message is to be sent. The default is UDP 162.
`-tcp` | Specifies that the TCP transport be used instead of the default UDP transport. If a connection cannot be established, the program displays the warning `connect - : connection refused` .
`-v version` | Specifies the SNMP version to use for sending the PDU. The valid versions are `2c` or `1` (default). You can specify the flag and value without including a space (for example, `-v2c` and `-v1` ).

### 4.2.1.3 Trap Sender Examples

In the following `snmp_trapsnd` command examples:

- The first line is the `snmp_trapsnd` command.
- The remainder is the display received when running the trap receiver program ( `snmp_traprcv` ) without flags included.

1. The following example generates a trap that originated on the `localhost` (specified by the `agent` parameter) using the default SNMP version (SNMP Version 1). The `-h host` parameter is not specified, so the trap will be sent to the local host.

       $ snmp_trapsnd 0.0 local 0 0 0

       Message received from 127.0.0.1

       SNMPv1-Trap-PDU:

       community -  7075626C 6963                         public

       enterprise - 0.0
       agent address - 0.0.0.0
       trap type - Cold Start (0)
       timeticks - 51938978

2. The following example generates the same trap as in example 1, except that it specifies the use of SNMP Version 2.

       $ snmp_trapsnd 0.0 local  0 0 0 "-v2c"

       Message received from 127.0.0.1

       SNMPv2-Trap-PDU:

       community -  7075626C 6963                         public

       sysUpTime.0 - 51938968 = 6 d 0:16:29
       snmpTrapOID.0 - 0.0

3. The following example sends values to the node `mynode` with the community name `special` .

       $ snmp_trapsnd 1.2.3 marley.dec.com 6 33 100 -c special -h mynode

       Message received from 16.20.208.68

       SNMPv1-Trap-PDU:
       community -  73706563 69616c            special

       enterprise - 1.2.3
       agent address - 6.20.208.53
       trap type - Enterprise-specific (6)
       enterprise-specific value - (33)
       timeticks - 100

Previous | Next | Contents | Index