Skip to main content
Sign in

Configuring SNMP

Brendan Gibbs
  • Updated

CBA applications that run on Fusion Application Server can generate SNMP event data (traps). This data can provide valuable usage and diagnostic information to administrators and network operations personnel.

For example, an application that monitors changes to a critical resource might raise an asymmetric trap when the resource changes. Similarly, you might have an application that monitors the availability of specific resources (such as the memory, or some other limited resource). When that resource runs low, the application might set a warning state and send a Set trap. Once that resource returns to acceptable levels, it sends a Clear trap.

For details of the architecture of the SNMP subsystem, see the Fusion Application Server Architecture Guide.

If you need to change the configuration details for the SNMP Agent after installing FAS, you can do so by modifying the attributes defined in the snmp_subsystem within the management profile using the JBoss CLI, and then restarting the SNMP service.

You can optionally configure the SNMP Agent to send notifications to multiple SNMP trap receivers, each with its own SNMP protocol version, IP address, and port. The installer can only configure a single receiver, but you can add extra receivers to the configuration after installation by adding trap-target entries for the snmp_subsystem using the JBoss CLI, and then restarting the SNMP service (see the Configuring SNMP Trap Targets section in this article).

The Fusion Application Server platform itself can also raise SNMP notifications. These are detailed in the Fusion Application Server SNMP Traps section in this article.

Configuring the SNMP Agent

An SNMP Agent runs as part of the Host Controller process on each FAS node. The SNMP Agent sends the event data to an SNMP client of your choice. An SNMP client is not supplied with Fusion Application Server: you must install your own client and supply the IP address of the server on which the client is running when you install FAS and SNMP Agent.

If you need to change the configuration details for the SNMP Agent, such as the location of the SNMP client or the transport protocol used, or if you need to add additional SNMP trap receivers, you can do so using the JBoss CLI.

You can change some properties at the SNMP subsystem level, and other properties can be set for a specific SNMP trap target:

/profile=management/subsystem=snmp\_subsystem/:write-attribute(name=<attribute-name>,value=<new-value>)

The attributes you can change are:

Attribute Details
port The default port is 8161, but can be changed to any valid port number.
protocol The protocol used for sending the traps. Can be udp or tcp. If the protocol is not specified, udp is used.
poll‑period The polling period in seconds which the SNMP Agent uses to check for changes to JMX attributes. When it detects a change, it sends a symmetric trap.

For example, to change the port used to 1061, you would use the following command:

/profile=management/subsystem=snmp_subsystem/:write-attribute(name=port,value=1061)

If you make any changes to the SNMP options, you must restart the SNMP service:

/profile=management/subsystem=snmp\_subsystem/:restart-snmp

You can also change the security options for SNMP - see the Configuring SNMP Trap Security section in this article.

Configuring SNMP Trap Targets

To add an address for receiving traps, you add an SNMP trap target:

/profile=management/subsystem=snmp\_subsystem/trap-target=<target name>/:add(protocol=<snmp protocol>,ip=<target ip>,port=<target port>)

where

  • <target name> is the ID of the trap target (a name for identification purposes)

  • <snmp protocol> is the SNMP protocol to use for this target. This must be one of

    • SNMPv1

    • SNMPv2c

    • SNMPv3

If the protocol is omitted, it defaults to SNMPv2c.

  • <target ip> is the IP address of the trap target.

  • <target port> is the port number which the trap target is listening on.

For example, to add a target with an ID of local, you might use a command like:

/profile=management/subsystem=snmp\_subsystem/trap-target=local/:add(protocol=SNMPv2c,ip=127.0.0.1,port=1062)

The properties for each trap target can be changed using a command that specifies the target-name:

/profile=management/subsystem=snmp\_subsystem/trap-target=local/:write-attribute(name=port,value=1063)

If any changes are made to the SNMP trap target options, restart the SNMP service:

/profile=management/subsystem=snmp\_subsystem/:restart-snmp

Configuring the SNMP Client

Use an SNMP client that implements the ALARM-MIB file. You can download the file from a site such as http://www.simpleweb.org/ietf/mibs/. You must then import this file, along with any MIB files supplied with applications that you will deploy and which will raise traps, into your SNMP client tool.

For the Fusion Application Server traps, you must import the following MIB files into your SNMP client:

  • AS-PLATFORM.MIB

  • AS-LICENSING.MIB

These files can be found in the <install dir>/docs/mibs directory.

Fusion Application Server SNMP Traps

There are a number of SNMP traps that might be raised when significant events occur within the FAS cluster. Each of the following SNMP traps for FAS are symmetric; this means that each trap contains Set when an issue is detected, or Clear when the issue is resolved:

Set Trap Name Description
platformSetSlaveDomainConnectionDown A slave AS could not connect to the Domain Host Controller, suggesting that the Domain Host Controller is not running. Applies to multi-box deployments only.
platformSetServerGroupDown The server group has no active server processes
platformSetServerConnection The SNMP Agent failed to connect to a server process. This could be an AS, LB, or Management Server; it is identified by the resourceId in the notification. (See the Decoding the Resource ID section in this article)
platformSetServerState Set for any server process state change for an AS, Management Server or LB. The server process has either stopped or a restart is required.
platformSetNodesNotRegisteredWithLoadbalancer An LB has no ASs registered with it. This trap is fired only when an LB is restarted at a time when there are no ASs running.

The Clear traps are called platformClearSlaveDomainConnectionDown, etc.

When the issue is resolved, the associated Clear trap is raised; for example, if the platformSetServerGroupDown trap was raised, the platformClearServerGroupDown trap is raised when at least one server in the server group starts, signifying that the issue is resolved.

There is also an asymmetric trap, platformAbnormalServerShutdown. This trap is raised every time an AS or LB shuts down unexpectedly. By default, when an unexpected shutdown is detected the Host Controller will restart that server. This trap ensures that administrators are alerted to multiple restarts that might affect service, so that they can investigate the issue.

If FAS is running a product which requires a license, the following traps may be raised as the license changes state:

Trap Name Description
asLicensingSetState A license has changed state to something other than ACTIVE. The new state may be one of:

●　NOT_STARTED

●　EXPIRED

●　EXPIRING_SOON
asLicensingClearState The state of the license has changed to ACTIVE.

The content of these traps includes the Resource ID and the State. The Resource ID encodes information about the product whose license has changed state: the server process (which is always management), the product ID, and the license ID.

See the Licensing article for further details.

Example Scenarios

  • If all of the ASs in a server group go down, no traffic can be processed for that server group, FAS raises the platformSetServerGroupDown trap.

  • If the management server process on the Domain Host Controller goes down, the licensing subsystem becomes unavailable, so FAS raises the platformSetServerConnection trap. It might also raise the platformSetServerState, as the server state changes from the running state.

  • If a slave Host Controller loses connection to the Domain Host Controller, the configuration on that might become stale, so FAS raises the platformSetSlaveDomainConnectionDown trap.

  • If a slave Host Controller reinstates a connection to the Domain Host Controller, FAS raises the platformSetServerState trap (restart required state).

Decoding the Resource ID

The resource ID identifies a FAS resource. It consists of a prefix which identifies FAS itself, followed by a single digit which identifies either the Host Controller itself, or one of two tables; if it is a table, it is followed by an index identifying the member of that table.

All the table and scalar OIDs for the FAS trap resources start with 1.3.6.1.4.1.7377.100:

Resource ID Resource
1.3.6.1.4.1.7377.100.0 Host Controller
1.3.6.1.4.1.7377.100.1 Server Process table
1.3.6.1.4.1.7377.100.2 Server Group table

For the tables, the indexes are keys consisting of an encoded string (containing the server process name for the server process table, or the server group name for the server group table). The encoded string that makes up the index has a number representing the number of characters in the string, followed by the ASCII character numbers that make up the string.

For example, for a server process named Hello, the resource ID would be:

1.3.6.1.4.1.7377.100.1.5.72.101.108.108.111

where:

  • 1.3.6.1.4.1.7377.100.1 indicates the server process table.

  • 5 is the length of the string (Hello), followed by:

  • 72 (ASCII H)

  • 101 (e)

  • 108 (l)

  • 108 (l)

  • 111 (o)

Traps Raised on FAS Startup

When a FAS cluster is first started, a number of traps are raised. This is because the system has no history of traps raised, so the status of each node is tested. If the status is fine, a Clear trap will be raised, regardless of any previous state. Therefore, on start-up, FAS will raise at least the platformClearNodesNotRegisteredWithLoadbalancer and platformClearServerGroupDown traps.

As the nodes in a FAS cluster start in an undefined order, it is likely that it will raise some Set traps, closely followed by the associated Clear traps.

Configuring SNMP Trap Security

By default, where applications raise SNMP traps, SNMPv2 traps are generated. You can optionally change this to SNMPv3 traps on installation; these traps can be secured, but are insecure by default. This section describes how SNMPv3 traps can be secured.

You can also restrict access to SNMP managed objects for any SNMP protocol version. This is done using the View Access Control Model (VACM). This is described in the SNMP View Access Control section in this article.

SNMP security levels and users are defined as properties of the snmp_subsystem, and can be configured using the CLI. To get a list of all the properties in the SNMP subsystem, use:

/profile=management/subsystem=snmp\_subsystem/:read-resource(recursive=true)

All of the values starting snmp4j.agent.config are related to SNMPv3 security; there are a great many of them, and only some of these options are discussed in this section.

Configure them using a command like:

/profile=management/subsystem=snmp\_subsystem/property=<property name>/:write-attribute(name=value,value=<property value>)

After any change to the SNMP subsystem or properties, restart the SNMP service:

/profile=management/subsystem=snmp\_subsystem/:restart-snmp

SNMP Security Levels and Users

You can implement SNMPv3 User-based Security Model (USM) security at one of three levels; there are three users specified by default, each one corresponding to one of the three levels, using specific authentication and encryption algorithms:

User Maximum Security Level Description
SHADES authPriv Authorization (SHA) and encryption (DES)
SHA authNoPriv Authorization (SHA) without encryption
unsec noAuthNoPriv Neither authorization nor encryption

These users are defined by the SNMP properties snmp4j.agent.cfg.oid.1.3.6.1.6.3.15.1.2.2.1, snmp4j.agent.cfg.index.1.3.6.1.6.3.15.1.2.2.1.0 (SHADES), snmp4j.agent.cfg.index.1.3.6.1.6.3.15.1.2.2.1.1 (SHA), and snmp4j.agent.cfg.index.1.3.6.1.6.3.15.1.2.2.1.2 (unsec), together with their associated properties (snmp4j.agent.cfg.value.1.3.6.1.6.3.15.1.2.2.1.0.0, snmp4j.agent.cfg.value.1.3.6.1.6.3.15.1.2.2.1.0.1, etc. - note that the 1.3.6.1.6.3.15.1.2.2.1 part is constant across the user definitions). The only values in the user definitions which should be changed are the passwords (SHADESAuthPassword, SHADESPrivPassword, and SHAAuthPassword).

Other values in the SNMP subsystem may be changed. For instance, to change the SNMPv1 read access to unrestricted, use:

/profile=management/subsystem=snmp\_subsystem/property=snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.0.1/:write-attribute(name=value,value={s}unrestrictedReadView)  

Implementing SNMPv3 Security

The following properties control which security level and user the SNMPv3 messages use:

  • snmp4j.agent.cfg.value.1.3.6.1.6.3.12.1.3.1.2.2

  • snmp4j.agent.cfg.value.1.3.6.1.6.3.12.1.3.1.2.3

To set the user of the SNMPv3 messages, use:

/profile=management/subsystem=snmp\_subsystem/property=snmp4j.agent.cfg.value.1.3.6.1.6.3.12.1.3.1.2.2/:write-attribute(name=value,value=<user>)

where <user> is one of SHADES, SHA, or unsec.

To set the security level, use:

/profile=management/subsystem=snmp\_subsystem/property=snmp4j.agent.cfg.value.1.3.6.1.6.3.12.1.3.1.2.3/:write-attribute(name=value,value=<level>)

where <level> is one of:

Value Level Description
1 noAuthNoPriv Can be specified for any of SHADES, SHA, or unsec
2 authNoPriv Can be specified only for SHADES or SHA
3 authPriv Can be specified only for SHADES

After making changes to the SNMP subsystem properties, restart the SNMP service - see the Configuring SNMP Trap Security section in this article.

Configuring the SNMP Client

For every SNMP Agent that an NMS SNMP management client will be receiving traps from, the management client will need to perform an SNMP GET on the snmpFrameworkMib.snmpFrameworkMIBObjects.snmpEngine.snmpEngineID (.1.3.6.1.6.3.10.2.1.1.0) for that SNMP Agent. This engineID will be used to set up the USM user for the management client.

For every SNMP Agent, the management client will need a USM entry containing the following:

EngineID,USER[,SHA,auth passphrase][,DES, priv passphrase]

The details of this configuration will depend on the SNMP client being used. The following configuration has been tested with net-snmp, using the snmptrapd tool (set up your own client with the equivalent settings in the way that your client expects).

For snmptrapd, put these settings in the /usr/etc/snmp/snmptrapd.conf file:

authCommunity log,execute,net public
createUser -e <engineID> SHADES SHA <SHADESAuthPassword> DES <SHADESPrivPassword>
createUser -e <engineID> SHA SHA <SHAAuthPassword>
createUser -e <engineID> unsec
authUser log,execute,net SHADES
authUser log,execute,net SHA
authUser log,execute,net unsec noauth

where <SHADESAuthPassword>, <SHAAuthPassword>, and <SHADESPrivPassword> should be replaced by the real passwords set in the SNMP subsystem configuration, and <engineID> is the value returned by the SNMP GET described above.

SNMP View Access Control

You can restrict access to SNMP managed objects for any SNMP protocol version. This is done using the View Access Control Model (VACM).

The vacmSecurityToGroupTable (at property snmp4j.agent.cfg.oid.1.3.6.1.6.3.16.1.2.1) defines the default SNMP Agent. It contains indexes at properties snmp4j.agent.cfg.index.1.3.6.1.6.3.16.1.2.1.0, snmp4j.agent.cfg.index.1.3.6.1.6.3.16.1.2.1.1,and so on. These indexes map a combination of security model and security name to a group (at the properties snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.2.1.0.0, snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.2.1.1.0, etc.). The group is used to define an access control policy.

The index is made up of the integer representing the security model, the length of the string representing the security name, and the security name itself, for example:

3.5.'unsec'

for a security model of 3 and the five character security name unsec.

The security model may be:

  • 0 - Reserved for any

  • 1 - SNMPv1

  • 2 - SNMPv2

  • 3 - User Based Security Model (USM) used by SNMPv3

The security name is the community string for SNMPv1 or SNMPv2, or the USM user name for SNMPv3 (i.e. SHADES, SHA, or unsec - (see the SNMP Security Levels and Users section in this article).

For instance, these entries map the SHADES user (using the USM security model) to the v3group:

"snmp4j.agent.cfg.index.1.3.6.1.6.3.16.1.2.1.1" => {"value" => {o}3.6.'SHADES'"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.2.1.1.0" => {"value" => {s}v3group"}:
...

By default, the groups are:

  • v1v2cgroup

  • v3group

The default access rights for groups are defined by another table (at snmp4j.agent.cfg.oid.1.3.6.1.6.3.16.1.4.1). The indexes into this table (at snmp4j.agent.cfg.index.1.3.6.1.6.3.16.1.4.1.0, etc.) contain a group name, a context prefix, a security model, and a security level. For example:

7.'v3group'.0.3.1

means a 7 character group name (which is v3group), a zero length context string (context strings are not currently used, so all are 0), the security model is 3 (USM), and the security level is 1 (noAuthNoPriv).

In the default configuration the following index entries are defined:

  • 10.'v1v2cgroup'.0.2.1 - SNMPv2, noAuthNoPriv (SNMPv2 'public')

  • 10.'v1v2cgroup'.0.1.1 - SNMPv1, noAuthNoPriv (SNMPv1 'public')

  • 7.'v3group'.0.3.3 - USM, authPriv (SNMPv3 'SHADES')

  • 7.'v3group'.0.3.2 - USM, authNoPriv (SNMPv3 'SHA')

  • 7.'v3group'.0.3.1 - USM, authPriv (SNMPv3 'unsec')

Three of the values associated with each index contain the access levels for read, write, and notify access for each group:

  • .1={s}unrestrictedReadView

  • .2={s}unrestrictedWriteView

  • .3={s}unrestrictedNotifyView

You can either set these entries to the value above, or leave them blank to prevent that particular access to the managed object.

Thus the entries:

"snmp4j.agent.cfg.index.1.3.6.1.6.3.16.1.4.1.1" => {"value" => {o}7.'v3group'.0.3.3"}:
...
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.1.1" => {"value" => {s}unrestrictedReadView"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.1.2" => {"value" => {s}unrestrictedWriteView"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.1.3" => {"value" => {s}unrestrictedNotifyView"}:
...

define the v3group as having unrestricted access for read, write, and notify, while:

"snmp4j.agent.cfg.index.1.3.6.1.6.3.16.1.4.1.1" => {"value" => {o}10.'v1v2cgroup'.0.2.1"}:
...
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.1.1" => {"value" => {s}"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.1.2" => {"value" => {s}unrestrictedWriteView"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.1.3" => {"value" => {s}"}:
...

defines the v1v2cgroup as having unrestricted write access, but no access for read or notify.

For each entry in the access table, set the appropriate read, write, and notify views. For example, if you want to allow all groups to be able to raise notifications, but only v3group with USM, authPrivsecurity, to allow reads and writes, the following configuration would achieve it:

"snmp4j.agent.cfg.oid.1.3.6.1.6.3.16.1.4.1" => {"value" => 6:6"}:
"snmp4j.agent.cfg.index.1.3.6.1.6.3.16.1.4.1.0={o}10.'v1v2cgroup'.0.2.1"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.0.0" => {"value" => {i}1"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.0.1" => {"value" => {s}"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.0.2" => {"value" => {s}"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.0.3" => {"value" => {s}unrestrictedNotifyView"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.0.4" => {"value" => {i}4"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.0.5" => {"value" => {i}1"}:
"snmp4j.agent.cfg.index.1.3.6.1.6.3.16.1.4.1.1" => {"value" => {o}7.'v3group'.0.3.3"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.1.0" => {"value" => {i}1"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.1.1" => {"value" => {s}unrestrictedReadView"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.1.2" => {"value" => {s}unrestrictedWri"teView"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.1.3" => {"value" => {s}unrestrictedNotifyView"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.1.4" => {"value" => {i}4"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.1.5" => {"value" => {i}1"}:
"snmp4j.agent.cfg.index.1.3.6.1.6.3.16.1.4.1.2" => {"value" => {o}10.'v1v2cgroup'.0.1.1"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.2.0" => {"value" => {i}1"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.2.1" => {"value" => {s}"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.2.2" => {"value" => {s}"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.2.3" => {"value" => {s}unrestrictedNotifyView"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.2.4" => {"value" => {i}4"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.2.5" => {"value" => {i}1"}:
"snmp4j.agent.cfg.index.1.3.6.1.6.3.16.1.4.1.3" => {"value" => {o}7.'v3group'.0.3.2"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.3.0" => {"value" => {i}1"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.3.1" => {"value" => {s}"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.3.2" => {"value" => {s}"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.3.3" => {"value" => {s}unrestrictedNotifyView"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.3.4" => {"value" => {i}4"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.3.5" => {"value" => {i}1"}:
"snmp4j.agent.cfg.index.1.3.6.1.6.3.16.1.4.1.4" => {"value" => {o}7.'v3group'.0.3.1"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.4.0" => {"value" => {i}1"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.4.1" => {"value" => {s}"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.4.2" => {"value" => {s}"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.4.3" => {"value" => {s}unrestrictedNotifyView"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.4.4" => {"value" => {i}4"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.4.5" => {"value" => {i}1"}:
"snmp4j.agent.cfg.index.1.3.6.1.6.3.16.1.4.1.5" => {"value" => {o}7.'v3group'.0.4.1"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.5.0" => {"value" => {i}1"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.5.1" => {"value" => {s}"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.5.2" => {"value" => {s}"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.5.3" => {"value" => {s}unrestrictedNotifyView"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.5.4" => {"value" => {i}4"}:
"snmp4j.agent.cfg.value.1.3.6.1.6.3.16.1.4.1.5.5" => {"value" => {i}1"}:
 

 

Related articles

Comments

0 comments

Please sign in to leave a comment.

Powered by Zendesk