Notifcation proxy forwarder - SNMP

This is a discussion on Notifcation proxy forwarder - SNMP ; Hi, Is the following a correct statement? If so, which RFC (and where exactly) indicates that, because I couldn't spot one? "If a system A sends a SNMPv2c/v3 notification to a system B, and the system B forwards it to ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Notifcation proxy forwarder

  1. Notifcation proxy forwarder

    Hi,

    Is the following a correct statement? If so, which RFC (and where
    exactly) indicates that, because I couldn't spot one?

    "If a system A sends a SNMPv2c/v3 notification to a system B, and the
    system B forwards it to a system C, there will be no trace of the system
    A, e.g. its IP address, in the notification when the system C receives it."

    Thanks,
    Nhan

  2. Re: Notifcation proxy forwarder

    Nhan Nguyen wrote:

    > "If a system A sends a SNMPv2c/v3 notification to a system B, and the
    > system B forwards it to a system C, there will be no trace of the system
    > A, e.g. its IP address, in the notification when the system C receives it."


    Talking about SNMPv3, this statement is incorrect. SNMPv3's
    scoped-PDUs include the contextEngineID of the originating SNMP engine
    which should be preserved by a proxy engine.

    With SNMPv2c, things are less clear. RFC 3584 defines the object
    snmpTrapAddress which can be used to preserve information about the
    sender. However, the description clause says that this is for SNMPv1
    compatibility.

    I consider this broken. I raised my voice in the WG because I wanted
    to have something similar to this object which however generally
    allows to convey the transport endpoint information of the originating
    engine (and is not bound to just IPv4 addresses). But as you can see,
    I failed to convince people to do something useful here.

    /js

    --
    Juergen Schoenwaelder International University Bremen
    P.O. Box 750 561, 28725 Bremen, Germany

+ Reply to Thread