Need to change SNMP request-id behavior -- configurable?

[computercolin]

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?

[tomaskir]

I dont know about any way to make NetXMS do this.

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.

[computercolin]

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:

[gmonk63]

What type of the Device is this ?  Is sounds like this might be a ppoe router of some sort.  So your best bet would be to setup a port based translation that would translate any requests to the public address:port  to the internal  address:port  but since it changes every four hours you would have to setup dyndns or no-ip  and refer to it by dns or else you will have to update your netxms configs

[computercolin]

@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.

[computercolin]

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.

[tomaskir]

Again, this breaks basic IP communication standards.
Packets like this would not traverse through any SPI firewall, or any NAT.

Even basic iptables firewall on your server would block such packets.
Any network device along the path that does any SPI or NAT will drop these packets.
These packets will be considered as unsolicited packets, since they are not responses to any established UDP stream (because of wrong IP header).

What you quoted from Juniper is for SNMP traps, which behave entirelly differently from RESPONSES to SNMP requests.

Imagine if NetXMS was to implement behaviour for every vendor's broken networking/snmp implementation...
That would be a very fast way to hell...

The correct way here is for the vendor of your device to fix the broken implementation, not for NetXMS to adjust to a broken implementation.