Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
  
[+] Expand All
[-] Collapse All

jnprsnmpd.conf File Overview

The jnprsnmpd.conf configuration file stores settings for the SNMP agent. After you install the SNMP agent for Steel-Belted Radius Carrier on a server, you can modify the jnprsnmpd.conf configuration file to reflect your network environment.

Note: When you install Steel-Belted Radius Carrier, you are prompted to enter your SNMP settings by the installation script. The installation script updates the jnprsnmpd.conf file based on the values you enter.

If SNMP was not set up during installation, we recommend you run the configuration script again and enable SNMP. Take care not to make any changes to the existing configuration.

The "clientaddr" needs to be placed under [snmp] in the jnprsnmpd.conf file; otherwise, an error is logged in the jnprsnmpd.log. To avoid this issue, place "clientaddr" under the [snmp] header in the jnprsnmpd.conf file.

Access Control Overview and Syntax

jnprsnmpd supports the View-Based Access Control Model (VACM) described in RFC 2575. To configure access control, you must map community names to security names, map security names to groups, and specify access rights and views for groups.

Use the com2sec keyword to map each source/community pair to a security name. The com2sec entry is used to determine a security name from the traditional community string, taking into account where a request has come from.

The syntax for the com2sec keyword is:

com2sec security_name source community

where:

  • security_name identifies the security name you want to create.
  • source can be a hostname, a subnet, or the word default. You can specify a subnet as an IP address and mask (nnn.nnn.nnn.nnn/nnn.nnn.nnn.nnn) or as an IP address and Classless Inter-Domain Routing (CIDR) bits (nnn.nnn.nnn.nnn/nn).
  • community is an SNMP community string, which acts as a password to authenticate SNMP communications.

    Note: If you use a CIDR address to identify a subnet, the host portion of the CIDR address must be 0. For example, if you are using the equivalent of a Class C subnet such as 192.168.1.x, you must enter the network address as 192.168.1.0/24 (which is the equivalent of 192.168.1.0/255.255.255.0).

The first source/community combination that matches an incoming packet is selected.

For example, the following creates two security names (local and mynetwork) and maps them to two different subnet/community name pairs:

 

sec.name

source

community

 

 

 

 

com2sec

local

localhost

local_community

com2sec

mynetwork

192.168.1.0/24

remote_community

Security Names Overview and Syntax

Use the group keyword to map security names into group names. The group keyword gives general control by mapping between a security name (for a particular protocol version), and the internal name used in the access line.

The syntax for the group keyword is:

group name model security

where:

  • name is the name of an access group
  • model identifies the security model you want to use: v1 or v2c.
  • security is a security name.

For example, these lines map the two security names to four group/model pairs:

#

sec.model

sec.name

 

group

LocalGroup

v1

local

group

LocalGroup

v2c

local

group

LANGroup

v1

mynetwork

group

LANGroup

v2c

mynetwork

Access View Overview and Syntax

Use the view keyword to specify what portions of the MIB tree a specified group can view or modify. The syntax for the view keyword is:

view name {include | excluded} subtree [mask]

where:

  • name is the identifier used for the view.
  • include | exclude lets you include or exclude specific portions of the MIB tree from the view.
  • subtree identifies the portion of the MIB tree that this name refers to in numeric or named form.
  • mask specifies what elements of the MIB subtree are relevant. The mask argument enables you to control access to specific rows in a table. When the entire MIB can be viewed, you can omit the mask field or enter ff.

Group Access Overview and Syntax

Use the access keyword to specify who has access to part or all of the MIB tree. The syntax for the access keyword is:

access name context model level prefix read write notify

where:

  • name is the name of a group.
  • context specifies the context for the view. For SNMPv1 or SNMPv2c, context is empty.
  • model is the security model: any, v1, or v2c.
  • level can be used to ensure that the request is authenticated or encrypted. For SNMPv1 or SNMPv2c, level is noauth.
  • prefix specifies how the context setting is matched against the context of the incoming PDU. Enter exact or prefix.
  • read specifies the view to be used for READ access.
  • write specifies the view to be used for WRITE access.
  • notify specifies the view to be used for NOTIFY access.

For example, these settings specify that the LocalGroup uses the all view for READ, WRITE, and NOTIFY access:

#

 

 

sec

sec

 

 

 

 

#

 

context

model

level

prefix

read

write

notify

access

LocalGroup

""

any

noauth

exact

all

all

all

access

LANGroup

""

any

noauth

exact

all

none

none

System Contact Overview and Syntax

You can specify your system contact information in the jnprsnmpd.conf file or in the MIB. If you configure your system contact information in the jnprsnmpd.conf file, the objects are locked and cannot be modified by means of SNMP.

System contact information consists of the following:

  • syslocation—The physical location of the managed device.
  • syscontact—The person or department responsible for maintaining the managed device.
  • sysname—The name of the managed device.

This information is stored in the system group of the MIB-II tree.

The syntax for specifying system contact information is:

syslocation string
syscontact string
sysname string

Traps Overview and Syntax

Traps can be used by network entities to signal abnormal conditions to management stations. Identify the NMS that receives trap messages generated by Steel-Belted Radius Carrier.

Note: You can configure Steel-Belted Radius Carrier to use either SNMPv1 or SNMPv2c traps. You cannot configure Steel-Belted Radius Carrier to generate both types of traps simultaneously.

  • Use the trapcommunity keyword to specify the default community string to be used when sending traps. Syntax for the trapcommunity keyword is:
    trapcommunity string


    The trapcommunity keyword must precede the trap2sink keyword in the jnprsnmpd.conf file.

  • Use the trapsink and trap2sink keywords to specify whether you want Steel-Belted Radius Carrier to use either SNMPv1 traps or SNMPv2c traps. Do not enable both types of traps at the same time.
    • The trapsink keyword specifies the host or hosts to which the Steel-Belted Radius Carrier server is to send SNMPv1 trap messages. If you want to use SNMPv1 traps, uncomment the trapsink keyword and specify the host or hosts to which you want Steel-Belted Radius Carrier to send SNMPv1 trap messages.

      Syntax for the trapsink keyword is:

      trapsink host[:port] [community]

      where:

      • host specifies the hostname or IP address of the NMS.
      • community specifies the community string the NMS accepts.
      • port specifies the UDP port on which the NMS is listening for SNMPv1 trap messages. Default is UDP port 162.

        For example:

        # send v1 traps
        trapsink nms.system.com secret
    • The trap2sink keyword specifies the host or hosts to which you want Steel-Belted Radius Carrier server to send SNMPv2c trap (notification) messages. If you want to use SNMPv2c traps, uncomment the trap2sink keyword to specify the host or hosts to which you want Steel-Belted Radius Carrier to send SNMPv2c trap (notification) messages.

      The syntax for the trap2sink keyword is:

      trap2sink host[:port] [community]

      where:

      • host specifies the hostname or IP address of the NMS.
      • community specifies the community string the NMS accepts.
      • port specifies the port on which the NMS is listening for SNMPv2c trap messages.

        For example:

        # send v2 traps
        trap2sink nms.system.com secret

[snmp] Overview and Syntax

The SNMP agent uses the jnprsnmpd.conf file to store static agent configuration information, such as community strings. The SNMP agent uses the persist directory to store information set during the running of the agent, which needs to be persistent from one run to the next.

The persistentDir keyword in the [snmp] section of jnprsnmpd.conf specifies the location of the persist directory. By default, the persist directory is located in the /snmp directory within radiusdir on your server.

The syntax for specifying the location of the persist directory is:

[snmp]
persistentDir radiusdir/snmp/persist

init.jnprsnmpd Overview and Syntax

By default, jnprsnmpd listens for incoming SNMP requests on UDP port 161 on all IP interfaces. You can specify a different UDP port in the init.jnprsnmpd file. The syntax for specifying a listening port is:

SNMPDPORT=port_number

Note: If you change the SNMP port number in init.jnprsnmpd, you must also enter the same port number in testagent.sh.

Note: If you run more than one SNMP agent on your server, each agent must use a unique UDP port number.

Subagent Overview and Syntax

By default, the SNMP subagent in Steel-Belted Radius Carrier communicates with the SNMP agent on TCP port 6669. If you change the port used for subagent-agent communication, you must modify jnprsnmpd.conf to uncomment the a3s_admin_parameters keyword and specify host, port, and interval values.

The syntax for the a3s_admin_parameters keyword is:

a3s_admin_parameters host=localhost port=port tryinterval=interval

where:

  • port identifies the TCP port the Steel-Belted Radius Carrier server uses for SNMP communication. The default value is 6669.
  • interval specifies the number of seconds the subagent waits to reconnect to the server if the connection breaks. If your SNMP management station issues queries intermittently, set the tryinterval value to a small number (1-5) to ensure timely information. If your SNMP management station polls the server periodically, set the tryinterval value to a larger number to avoid flooding the server with queries. The default is 10 seconds.
  • lifetime specifies the number of seconds information can remain in the SNMP subagent cache. If your SNMP management station issues queries intermittently, set the tryinterval value to a small number (1-5) to ensure timely information. If your SNMP management station polls the server periodically, set the tryinterval value to a larger number to avoid flooding the server with queries. The default is 10 seconds.

Modified: 2018-01-11