7                    Targets

The set of information that describes where and how to send a SNMP message is called a 'Target' and consists of three kinds of information:

Targets may be configured for the following purposes:

1.   To manage a SNMP agent or proxy agent (also known as command responder).

2.   To send traps/notifications or Inform requests to a trap receiver appli­cation (also known as command generator).

3.   To discover SNMP agents in a (sub) network.

7.1                 Target Configuration

Targets are configured by using the target and user editor which provides two tabs with two tables. The first table is used to configure targets and the other is used to configure USM users. The topmost entry in the target table is always the active target. Both tables can be sorted by arbitrary columns by clicking on the column headers.

By setting a master password with Edit->Master Password all passphrases and community names of the target and user configuration as well as the keystore passwords of the TLS transport are stored AES 128 encrypted in the configuration file within the users home directory.

To Edit Targets:

1.   Choose Targets from the Edit menu or MIB_Explorer_Manual00031.gif  from the toolbar.

2.   Edit the targets as described by “Adding a New Target” on page 46 and “Removing a Target” on page 48.

3.   Save your changes by pressing OK.

7.2                 Selecting the Active Target

To select the target you want to work with:

1.   Select the target from the combo-box in the Targets toolbar.

2.   Open the Targets editor by choosing Edit->Targets, select the target you want to use, and then choose Set Active from the context menu or select the checkbox in the first column named "Active".

7.3                 Adding a New Target

Although targets may be used for different purposes, they are created in the same way. Only the used address/port distinguishes between agent, trap, or discovery targets.

The target tab is divided into a upper and lower pane where the upper contains the list of all configured targets and the lower pane provides a form to edit the selected target.

Tip: The name column of the table is not editable and can be therefore used to easily select a row.

A changed form value is applied to the table whenever the focus is moved from the edited field. If a value is not valid, the field background will change to pink and the table value is not updated until the value has been corrected.

To Add a New Target:

1.   From the Edit menu choose Targets (MIB_Explorer_Manual00033.gif). A modal dialog will be shown.

2.   Choose the Targets tab.

3.   Press the New Target button.

4.   A new row will be inserted into the target configuration table and the target name editor is activated. You can now edit the entry using either the table directly or using the form on the lower half of the split pane.

5.   Enter an unique name for the target.

6.   Select the transport mapping (UDP, TCP or TLS) with which the tar­get can be accessed from the Transport column.

7.   Enter the IP address and port of the target separated by a slash (/). You can also enter a hostname if the target uses Dynamic Host Configura­tion Protocol (DHCP) to determine its IP address.  If you want to access the SNMP of your local system, you can either enter 127.0.0.1/161, 127.0.0.1, localhost/161, or localhost which are all the same. Additional examples are:

255.255.255.255 - Discovery target using an IPv4 broadcast address (only works with UDP)

92.168.0.255:4700 - Discovery target for port 4700 in class C network 192.168.0

080::8:800:200C:417A - An IPv6 address.

FFFF:129.144.52.38/161 - An standard IPv4 address in IPv6 format.

8.   Select the SNMP version for the target:

9.   Choose the Timeout value and the number of Retries.

10.Choose the MIB set you want to associate with the target from the drop down list. Select the empty entry, if you do not want to associate any MIB set with the target.

11.If you have chosen SNMPv1 or SNMPv2c as SNMP version then enter the community to be used with the target.

12.Otherwise, if you have chosen SNMPv3 then select an USM user from the dropdown list. If you need to add a new user then create it using New User.

13.You can continue to specify the optional SNMPv3 security parameters engine ID, context name, and context engine ID as described below.

14.Save the new target into MIB Explorer's configuration by pressing OK.

To Configure Optional SNMPv3 Security Parameters:

1.   Use the Discover menu item from the context menu to discover the targets Engine ID. Leaving the engine ID field empty will let MIB Explorer discover the target's engine ID automatically, once for each session.

2.   Enter the Context to be used with the target as plain text. The default is an empty string.

3.   Enter the Context Engine ID which selects the subsystem or proxy as a plain text or hexadecimal string, for example 0f:ab:12:A:g5 (use the context menu Format to change the input format). The default is an empty string. In this case, MIB Explorer will use the entered or dis­covered engine ID as context engine ID.

7.4                 Removing a Target

1.   From the Edit menu choose Targets (MIB_Explorer_Manual00035.gif). A modal dialog will be shown.

2.   Choose the Targets tab.

3.   Select the target to delete from the by clicking on it (using the Name column).

Removing a target will not invalidate monitor configurations using that target, however the removed target will no longer available for the discovery configuration after restarting MIB Explorer.

4.   Press the Delete Target button.

5.   Select a target you want to work with and choose Set Active from the context menu or select the corresponding checkbox in the column Active.

6.   Press the Save button.

7.5                 Communities

A SNMPv1/SNMPv2c community contains one agent and one or more managers. A community is named by a string of octets which is called a community string. Although many SNMP developers and users believe that a community string is a password, its originally intended use was not that simple. Nevertheless, many agent implementations are using a community string as password for read-only access and another for read-write access.

Community strings are send as plain text over the wire.

With MIB Explorer you can specify a single community for each target that is used for all request types.

7.6                 USM Users

The User based Security Model (USM) associates a user name with security information and is defined in RFC 2574. A USM user consists of:

An internal name for the user. In most cases this name would match the security name. The user name must be unique within a MIB Explorer configuration.

Identifies the user. The security name is used to refer to an user in many MIBs, in particular the SNMP-VIEW-BASED-ACM-MIB maps security model/name combinations to groups in the VACM. Without such a mapping a USM user cannot access any MIB informa­tion in an agent.

Determines which authentication protocol (no authentication, MD5 or SHA) can be used with this user.

If an authentication protocol is selected, an authentication passphrase has to be entered too. That will be combined with the target's SNMP engine ID to form the localized authentication key by using the selected hashing algorithm. Supported algorithms are: MD5 and SHA-1 as well as the new SHA-2 authentication protocols SHA-224, SHA-256, SHA-384, and SHA-512.

If you do not provide a Localization Engine ID for a USM user then the target's engine ID will be used to localize passphrases on-the-fly. The USM user can thus be used securely for several SNMP targets.

If you provide a Localization Engine ID then this user can only be used with a target whose authoritative engine ID equals the used local­ization engine ID.

To enter a passphrase in hexadecimal format, use the context menu to change the input format in the table or use the format button on the right of the input field.

 

Determines which privacy protocol (no privacy, DES, 3DES, AES128, AES196, or AES256) is used with this user.
The nonstandard privacy protocols AES192-KeyExt3DES and AES256-KeyExt3DES are provided to ensure interoperability with some devices that implemented AES 192 and 256 privacy with a key extension algorithm specified for 3DES. Although, that combination was never specified by an IETF RFC or draft, it has been implemented by some manufactures.

If the privacy protocol DES is selected then the entered privacy pass­phrase is localized with the selected authentication protocol (analo­gous to localizing an authentication passphrase) and then used to encrypt/decrypt SNMP messages.

The localization engine ID can be left empty by default. However, if two targets use the same security name with different passphrases and/or authentication/privacy protocols then you need to localize each user for its specific engine ID to avoid clashes. You can localize the pass­phrases of an user easily by using Localize User from the context menu. It prompts for the target engine ID used for the localization in hexadecimal format. Once you press OK, the passphrases are localized and the entered localization engine ID is stored with the USM user security credentials.

MIB Explorer abstracts from security names by using User Profiles. The User Profile Name is independent from the user's security name. Nevertheless, it makes sense to choose the profile name according to an user's security name for better readability.

7.7                 Adding an USM User

Please note that adding a new user to MIB Explorer's configuration does not create that user in the USM MIB of the target for which you added the user. To create a new user in the USM MIB of one or more targets, use the SNMPv3 user administration (See “SNMPv3 User Administration (Pro Edition)” on page 159.).

To Add a USM User Profile:

1.   Select Targets from the Edit menu.

2.   Press the New User button from the toolbar. The USM User tab will be shown and a new row at the bottom of the table will be inserted. The user name column editor is activated, so you can press <Ctrl>-A and then directly begin to enter the name of the USM user profile.

3.   Enter a unique name for the user profile. If possible, the profile name should be equal to the security name of the user.

4.   Enter the properties of the USM user (See “USM Users” on page 49.).

5.   Press the Save button.

7.8                 Deleting an USM User

A user profile can be deleted from MIB Explorer's configuration if there is not any target using that profile any more. Otherwise a different user has to be selected for those targets first. Deleting a user profile does not delete the corresponding USM user in the SNMP agent associated with the target. In order to delete a user from the USM MIB of an agent use the SNMPv3 user administration.

To Remove a User Profile:

1.   From the Edit menu choose Targets (MIB_Explorer_Manual00037.gif). A modal dialog will be shown.

2.   Choose the USM Users tab.

3.   Select the user profile to be deleted.

4.   Press the Delete User button to delete the profile. If other targets are also referencing that user an error message will be displayed and the profile will not be deleted.

5.   Press the Save button to finally commit your change.

7.9                 Target Statistics

In target selection toolbar there is a button named Statistics. It opens a dialog which displays a sortable read-only table that provides for each target address/port combination statistics about the number of messages totally sent to the SNMP entity, as well as the number of messages needed per request (one is optimal here). In addition, the number of retries needed to fulfill the request as well as the runtime of the successful message exchange is counted.

The columns of the target statistics table are described in the below table:

Table 5: Column descriptions of the Target Statistics table.

Column

Description

Address

The IP address and port of the target that was subject to SNMP requests that expected a response PDU.

PDU Size

Classifies the PDU size in number of variable bindings in the received response. The value * represents any PDU size.

Otherwise the PDU size range is provided, whereas he lower bound is inclusive and the upper is exclusive.

Total Messages Sent

The total number of confirmed messages sent to this target since the last start of the application.

Sent/Request MIN

The minimum number of messages sent per confirmed SNMPv3 request. SNMPv1/v2c messages are not counted.

Sent/Request MAX

The maximum number of messages sent per confirmed SNMPv3 request. SNMPv1/v2c messages are not counted.

Sent/Request AVG

The average number of messages sent per confirmed SNMPv3 request. SNMPv1/v2c messages are not counted.

Retries MIN

The minimum number of retries that where needed to receive a response for a SNMPv3 confirmed request.

Note: More retry messages could have been actually sent than this value indicates.

Retries MAX

The maximum number of retries that where needed to receive a response for a SNMPv3 confirmed request.

Note: More retry messages could have been actually sent than this value indicates.

Retries AVG

The average number of retries that where needed to receive a response for a SNMPv3 confirmed request.

Note: More retry messages could have been actually sent than this value indicates.

Runtime MIN

The minimum number of milliseconds elapsed between sending the request message (initial request or retry) and receiving the corresponding response PDU (SNMPv3 only).

Runtime MAX

The maximum number of milliseconds elapsed between sending the request message (initial request or retry) and receiving the corresponding response PDU (SNMPv3 only).

Runtime AVG

The average number of milliseconds elapsed between sending the request message (initial request or retry) and receiving the corresponding response PDU (SNMPv3 only).