We have a regression in the SNMP core API for get effective address (snmp-proxy)

Description

At some point in refactoring the SNMP API, the support for the proxy-host attribute in the SNMP configuration quit working.  I could not find any reference to the method: org.opennms.netmgt.snmp.SnmpAgentConfig.getEffectiveAddress()

Which returns the proxy host address vs the nodes "provisioned" address.

 

NAT'd 1.1.1.1:50161->10.1.1.1:161 Example:

 A node provisioned with the IP address 169.254.1.1 would have an SNMP proxy agent reachable at 1.1.1.1 on port 50161.

 

I've seen another implementation of an actually SNMP Proxy agent that uses an overloaded community string and the definition would look like:

 This used to work but seems to have slipped through our refactoring.

Acceptance / Success Criteria

None

Lucidchart Diagrams

Activity

Jesse White May 13, 2019 at 1:59 PM

That's the idea, I would like to see us have two different listeners bound though. Here we would redirect two different agents to the same host on different ports.

The MockSnmpAgent can be used to setup the actual UDP listener so that we speak the protocol instead of creating a naive listener.

Patrick Schweizer May 6, 2019 at 1:03 PM

Hi ,

I looked into the usage of MockSnmpAgent. I am not sure if I understand the concept correctly but I don't know how it helps to test if the proxy server is actually called instead of the target? So I replicated what I did manually before:

  • setting up a configuration with a proxy

  • create a UDP listerner on the proxy machine

  • run the agentclient

  • check if the proxy host was called

I created a pull request for that: https://github.com/OpenNMS/opennms/pull/2487

Could you check if that tests what you have imagined?

Jesse White April 30, 2019 at 2:59 PM

Test case can look something like:
1. Start two different SNMP agents bound to 127.0.0.1 using the MockSnmpAgent.createAgentAndRun()
2. Build a config that maps 169.254.1.1 to agent1 and 169.254.1.2 to agent2
3. Issues an SNMP GET to 169.254.1.1 and another to 169.254.1.2
4. Verify that these return some expected value (should ideally be different between to two agents to make sure we did in fact hit the right one)

Patrick Schweizer April 29, 2019 at 7:07 PM

Jesse White April 29, 2019 at 3:11 PM

that behavior looks correct - it's possible that it does in fact work.

Can you find and share the portion of the code where the proxy host is applied? Also, can we add a integration test for this if not already covered?

Fixed

Details

Assignee

Reporter

Labels

Components

Sprint

Priority

PagerDuty

Created July 23, 2018 at 7:46 PM
Updated May 27, 2019 at 8:36 AM
Resolved May 27, 2019 at 8:36 AM