Trap IP Config Question - SNMP

This is a discussion on Trap IP Config Question - SNMP ; I have a basic question on trap configuration for SNMP agents. Somehow the SNMP agent needs to be configured with the IP address of the SNMP manager. Does the SNMP manager configure this? Is there an oid that contains the ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Trap IP Config Question

  1. Trap IP Config Question

    I have a basic question on trap configuration for SNMP agents. Somehow
    the SNMP agent needs to be configured with the IP address of the SNMP
    manager. Does the SNMP manager configure this? Is there an oid that
    contains the IP address of the manager? Also, the system I am working
    with is running SNMPv1 if that matters.


  2. Re: Trap IP Config Question

    HI,

    For GET/SET/GETNEXT operations, an "agent" does not need
    to know the address of the "manager". However to send
    notifications (traps in SNMPv1, or both traps and informs
    in SNMPv2c and SNMPv3), a "notification originator" (such
    as an agent) must know where to send the notification.

    This configuration can be done using a proprietary means,
    such as via a command line interface (CLI) to the
    system containing the notification originator,
    or via the MIB objects defined in RFCs 3413 and 3584.

    If you are supporting only SNMPv1 (or if you do not
    support SNMP SETs), then I suggest that you use a
    proprietary approach.

    On Mon, 4 Apr 2005 scooter_12358@yahoo.com wrote:
    > I have a basic question on trap configuration for SNMP agents. Somehow
    > the SNMP agent needs to be configured with the IP address of the SNMP
    > manager. Does the SNMP manager configure this? Is there an oid that
    > contains the IP address of the manager? Also, the system I am working
    > with is running SNMPv1 if that matters.
    >
    >

    Regards,
    /david t. perkins

  3. Re: Trap IP Config Question

    I've been looking at Solstice Enterprise Agents SNMP on Solaris, so
    this is OS-specific.

    Agents send traps to the traphost (defined in the/etc/hosts file) and
    to any other hosts that you like, if you declare them in the necessary
    configuration files. These are:

    /etc/snmp/conf/snmpd.conf
    /etc/snmp/conf/snmpdx.acl

    and any sub-agent specific *.acl files that you are using. In addition,
    if you are using the hardware/platform-specific Sun-supplied software
    (which acts as a sub-agent monitoring fanspeed, power supplies,
    batteries, watchdogs etc, etc) then you need to edit the config files
    for them as well. We're using SunFire V240 so wae have

    /etc/opt/SUNWmasf/conf/snmpd.conf

    and it has a different format to the other snmpd.conf file (of course -
    if it was easy they could get any monkey off the street to do this job,
    and what would that do to our salaries?)

    The trap destination is not defined by using an oid.

    I said that this is OS-specific. It is also SNMP implementation
    specific, as you are not forced to use Solstice Enterprise Agents on
    Solaris. I believe there are many other SNMP Agent implementations
    available such as NetSNMP and so on. Just as there are many SNMP
    Manager packages available, such as Loriot, HPOpenView, Castle Rock's
    SNMPc, etc, etc. And you _could_ write your own ;-)

    However your Agent is implemented, when it starts up you need to tell
    it the IP address of the traphost/SNMP Manager. UDP over IP is used for
    communication - it's a connectionless protocol so you don't get
    feedback about your messages when you send them. The Agent will send
    traps to port 162 and receive requests on port 161. Those ports are
    pre-defined for the purpose. Some Agents and Managers allow you to
    specify other ports.

    And one other thing: as you say you are using SNMPv1, make sure that
    you send traps and requests with community strings that are matched at
    each end of the comm link. If you send traps or requests with the wrong
    community strings they will be ignored. I mentiog this explicitly
    because you should set your own community strings up rather than
    leaving them as "private" and "public" because that's what any hacker
    will first try. And it _does_ matter for traps because if your Manager
    has to go to the effort of decoding more traps than necessary, that's a
    bit like a flood of pings attack. Better to reject the traps because
    they have the wrong community, early on.

    Get a decent book on the subject, or search the web and print out some
    free articles.


+ Reply to Thread