Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (Flatly)
  • No Skin
Collapse
Brand Logo

NetXMS Forum

C

computercolin

@computercolin
Unfollow Follow
About
Posts
4
Topics
1
Shares
0
Groups
0
Followers
0
Following
0

Posts

Recent Best Controversial

  • Need to change SNMP request-id behavior -- configurable?
    C computercolin
    Support

    Other major equipment vendor have same SNMP behavior as my device.
    See Juniper Networks http://www.juniper.net/documentation/en_US/junos12.3/topics/reference/configuration-statement/source-address-edit-snmp-qfx-series.html

    juniper documentation snmp-source-address said:

    Set the source address of every SNMP trap packet sent by this switch
    to a single address regardless of the outgoing interface. If the source
    address is not specified, the default is to use the address of the outgoing
    interface as the source address.


  • Need to change SNMP request-id behavior -- configurable?
    C computercolin
    Support

    @tomaskir said in Need to change SNMP request-id behavior -- configurable?:

    This is the fault of your device, your device needs to respond from the same IP address that the connection was initiated to.
    This is a basic IP networking principle, you always respond from the src-address that was the dst-address in the original packet.

    I suggest contacting the device manufacturer to fix this.

    Actually, what my device is doing is not wrong.
    From SNMP RFC 1157

    RequestIDs are used to distinguish among outstanding requests.  By
    use of the RequestID, an SNMP application entity can correlate
    incoming responses with outstanding requests.

    If we recall OSI Model, it is also principle to not depend on data from different OSI layers in your protocol. If your protocol depend on information in Layer2 or Layer3, then your protocol will not work if different Layer2 or Layer3 are used. Then your layers are not independent, you cannot swap A-layer2 for B-layer2, and OSI is broken.

    So actually NetXMS is in violation of SNMP standard  😕

    Also, I realize, my comment about port-numbers is not correct  :-[, NetXMS should use only RequestID to match SNMP. It should not use UDP port number for matching.


  • Need to change SNMP request-id behavior -- configurable?
    C computercolin
    Support

    Here is packet capture of SNMP conversation with my device.
    Request-ID matches between request-response pairs (and only between each pairs, not reused)

    You may think but if NetXMS is polling many devices, request-id will have collisions!
    Well, port-number also matches (49152 here), so this can be used as extra bits!

    request:

    response:


  • Need to change SNMP request-id behavior -- configurable?
    C computercolin
    Support

    Hello,
    I have a scenario where NetXMS SNMP polling does not work.. but I think it can be made to work.

    target device:
     - Private IP - 10.X.Y.Z
      - stable
     - PPPoE
        - PPP IP change every 4 hours
        - default route through PPPoE

    I add device to NetXMS with private IP (10.X.Y.Z) but NetXMS cannot SNMP poll device.
    This is because NetXMS send SNMP request to 10.X.Y.Z but device responds src-ip=$pppoe_public_ip. The two IPs do not match, so NetXMS does not match up the SNMP-request and the SNMP-response correctly.

    SNMP includes a request-id, so if NetXMS matches SNMP-request and SNMP-response using request-id, it will work correctly.
    (for example, I have windows tool that does this, and it works with my device)

    Is there a way to configure NetXMS to match SNMP based on request-id and ignore src-ip?

  • Login

  • Don't have an account? Register

  • Login or register to search.
Powered by NodeBB Contributors
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups