Flags are specified in UNIX style format.

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.

If you do not specify a flag, or if you specify an invalid flag, a usage message is displayed. You must place the flag(s) after the request_type parameter.

The flags for the snmp_request command are outlined in Table 11-4.

Table 11-4 Flags for the snmp_request Command

Flag	Description
-v version	Specifies the SNMP version to use for sending the PDU. The versions are: 2c or 1 (default). Not case sensitive. You can specify the flag without a space ( -v2c and -v1). If request_type is getbulk, the version defaults to SNMPv2. If you specify -v 2c to send a message to an SNMPv1 agent or subagent, it is unlikely to respond.
-p port	Specifies the port where the request is to be sent. If not specified, the request is sent to well-known SNMP port 161.
-l	Specifies loop mode. Note that this flag is the letter l, not the number 1. Valid only if request_type is getnext or getbulk (where flag n is set to 0 and flag m is set to a number greater than 0). Causes the master agent to traverse all the MIBs registered with the master agent, starting at the first OID after the one specified in the command. (Note that you can specify only one variable_name (OID).) Responses are received one at a time, and for each one, the OID returned by the master agent is used in a subsequent request. Corresponds to the behavior of standard mibwalk programs. The MIB browser reads and prints responses and issues requests until the master agent has no more data, times out, or you enter Ctrl/Y or Ctrl/C. If specified with the getbulk request, the -n and -m flags and associated values are ignored, and the behavior is identical to that of getnext. When the last OID handled by the master agent is reached, you receive a response similar to the following for a query on OID 1.3.6.1.6.3.1.1.6.1 using SNMPv1: 1.3.6.1.6.3.1.1.6.1.0 = 693056825 - no such name - returned for variable 1 For a query using SNMPv2, the example response is: 1.3.6.1.6.3.1.1.6.1.0 = 693056825 1.3.6.1.6.3.1.1.6.1.0 = - end of mib view - These examples assume that: OID 1.3.6.1.6.3.1.1.6.1.0 is the last OID supported on the target host. The target host is running an SNMPv2 agent. The statement end of mib view refers to OIDs for all MIBs registered with the master agent.
-t	Specifies tree mode. Valid only if request_type is getnext or getbulk (where flag n is set to 0 and flag m is set to a number greater than 0). Similar to the -l flag. Directs the agent to perform a MIB walk for the subtree with the variable_name as its root. The program reads and prints responses and issues requests until the agent has no more data for the specified subtree, times out, or is interrupted by a user.
-d	Specifies hex dump mode. Before displaying a return value, displays a hexadecimal dump of SNMP packets sent and received. For example: $ snmp_request host1 "public" getnext -d -v 2c 1.3.6.1.6.3.1.1.6 Sent: 30290201 01040670 75626C69 63A11C02 0).....public... 047BE9C1 BD020100 02010030 0E300C06 .{.........0.0.. 082B0601 06030101 060500 .+......... Received: 30820033 02010104 06707562 6C6963A2 0..3.....public. 2602047B E9C1BD02 01000201 00308200 &..{.........0.. 16308200 12060A2B 06010603 01010601 .0.....+........ 00020478 D917FC ...x... 1.3.6.1.6.3.1.1.6.1.0 = 2027493372
-w max_wait	Specifies the maximum seconds the snmp_request program waits for a reply before timing out. Cannot be 0. The default is 3.
-n non_repeaters	Specifies the number of variables for which no repetition is requested. Applies only to the getbulk request. If you specify getbulk without specifying both the -m and -n flags, the results are unpredictable.
-m max_reps	Specifies the number of repetitions requested for repeating variables. Applies only to the getbulk and getnext requests. Note that the resulting display can be confusing because the results for the repeater OIDs are interleaved. That is, the OIDs are displayed in alternate progression for faster memory throughput. If you specify getbulk without specifying both the -m and -n flags, the results are unpredictable.

11.6.3 Data Types

The snmp_request and snmp_trapsnd commands support tge data types listed in Table 11-5. The values are applicable only for the set request.

Table 11-5 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

Note: Except for -l (Counter64), the data types are case sensitive. To preserve uppercase for display string and NULL, enclose each 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 0l0 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 0l0 mynode 6 33 100 -h mynode -v2c - _$ 1.3.6.1.2.1.1.4.0 "l" 0x1234567890ABCDEF

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

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

11.6.4 Command Examples for snmp_request

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 command responses have been edited for readability.

1. 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. 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 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. Retrieve the next MIB-II variable. 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. Use the SNMPv2 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 3 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. 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 SNMPv2 agent is the server, the results using getbulk are identical (in general, SNMPv1 agents do not support getbulk requests).
   This example also illustrates the display for the /LOCATION example in Section 11.4.

   $ 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. Use the command in the previous example but specify 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 SNMPv2 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. Send a set request. The request succeeds because the command line specifies the correct type for the variable, and all the conditions for enabling sets 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. 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

DIGITAL TCP/IP Services for OpenVMS 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 SNMPv1 and SNMPv2 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 port 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.

11.7.1 Entering Commands for the Trap Sender Program

The trap sender program lets you send SNMPv1 and SNMPv2 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 SNMPv1-Trap-PDU (see RFCs 1155, 1156, 1157, and 1215) or an SNMPv2-Trap-PDU (see RFCs 1905 and 1908) into an SNMP message and sends it to the specified host(s). You use parameters and flags to specify the data fields in the trap PDU.

Traps are uniquely identified in the PDU:

• SNMPv1 is identified by a combination of parameters.
• SNMPv2 is identified by the value of snmpTrapOID.

To run the trap sender program, do the following:

1. Define a foreign command for the program. Enter:

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

   
   Or, you can run SYS$MANAGER:TCPIP$DEFINE_COMMANDS.COM 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]]

The snmp_trapsnd parameters are described in Table 11-6. Each parameter is required, but you can specify 0, as appropriate.

Table 11-6 Parameters for the snmp_trapsnd Command

Parameter	Description
enterprise	SNMPv1: 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. SNMPv2: When specified with the -v2c flag, represents the value of snmpTrapOID.0.
agent	For SNMPv1 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 SNMPv1 trap PDU. If the -v2c flag is specified, this parameter is ignored.
generic-trap	SNMPv1: Specifies the generic trap identifier in the form of a number. Must be one of the following values: SNMPv1 Value Object 0 coldStart 1 warmStart 2 linkDown 3 linkUp 4 authenticationFailure 5 egpNeighborLoss 6 enterpriseSpecific SNMPv2: When the -v2c flag is specified, this parameter must contain a valid OID or 0 as the value of snmpTrapOID.
specific-trap	SNMPv1: 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 11-5.

11.7.1.2 Flags

The snmp_trapsnd flags are described in Table 11-7.

Table 11-7 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).