[opennms-discuss] Changing SNMP port

[John A. Sullivan III]

Hello, all. We regularly move to non-standard ports for "dangerous"
protocols like ssh and snmp. We are seeing some strange behavior with
opennms when we do this. We created new discovery, polling, and
collection definitions named SNMP-SSI modeled on the SNMP definitions
and using the snmp plugin.

We see both SNMP and SNMP-SSI show up in the discovery even though we
are not listening on 161 /udp. When the poller runs, it then shows the
SNMP is down as one would expect. Why is SNMP being discovered at all?

Let's say we've changed the SNMP port on this server to 761. Netstat
shows this change:

[***@ldap2 ~]# netstat -tuln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:9830 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:199 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:6010 0.0.0.0:* LISTEN
tcp 0 0 :::389 :::* LISTEN
tcp 0 0 ::1:6010 :::* LISTEN
tcp 0 0 :::922 :::* LISTEN
tcp 0 0 :::636 :::* LISTEN
udp 0 0 0.0.0.0:761 0.0.0.0:*
udp 0 0 0.0.0.0:39137 0.0.0.0:*
udp 0 0 0.0.0.0:5353 0.0.0.0:*
udp 0 0 172.30.10.49:123 0.0.0.0:*
udp 0 0 127.0.0.1:123 0.0.0.0:*
udp 0 0 0.0.0.0:123 0.0.0.0:*
udp 0 0 :::49374 :::*
udp 0 0 :::5353 :::*
udp 0 0 ::1:123 :::*
udp 0 0 fe80::5652:ff:fe01:501:123 :::*
udp 0 0 :::123 :::*

We can connect just fine using snmpget and the SNMP test oid from
opennms:

snmpget -v 3 -x AES -X password -a SHA -A password -u snmpman -l authpriv ldap2:761 .1.3.6.1.2.1.1.2.0

We defined SNMP-SSI in capsd-configuration.xml as follows:
<protocol-plugin protocol="SNMP-SSI" class-name="org.opennms.netmgt.capsd.plugins.SnmpPlugin" scan="on">
<property key="port" value="761" />
<property key="timeout" value="2000" />
<property key="retry" value="1" />
</protocol-plugin>

We define it again in poller-configuration.xml as follows:
<service name="SNMP-SSI" interval="300000" user-defined="false" status="on">
<parameter key="retry" value="2" />
<parameter key="timeout" value="3000" />
<parameter key="port" value="761" />
<parameter key="oid" value=".1.3.6.1.2.1.1.2.0" />
</service>
<monitor service="SNMP-SSI" class-name="org.opennms.netmgt.poller.monitors.SnmpMonitor" />

We edited

<?xml version="1.0"?>
<?castor class-name="org.opennms.netmgt.collectd.CollectdConfiguration"?>
<collectd-configuration
threads="50">

<package name="SNMP161">
<filter>IPADDR != '0.0.0.0'</filter>
<include-range begin="172.x.x.8" end="172.x.x.9"/>
<include-range begin="172.y.y.3" end="172.y.y.254"/>

<service name="SNMP" interval="300000" user-defined="false" status="on">
<parameter key="collection" value="default"/>
<parameter key="thresholding-enabled" value="true"/>
</service>
</package>

<package name="SNMP761">
<filter>IPADDR != '0.0.0.0'</filter>
<include-range begin="1.1.1.1" end="254.254.254.254"/>

<service name="SNMP-SSI" interval="300000" user-defined="false" status="on">
<parameter key="collection" value="default"/>
<parameter key="port" value="761"/>
<parameter key="thresholding-enabled" value="true"/>
</service>
</package>

<collector service="SNMP" class-name="org.opennms.netmgt.collectd.SnmpCollector"/>
<collector service="SNMP-SSI" class-name="org.opennms.netmgt.collectd.SnmpCollector"/>

</collectd-configuration>


To add to the strangeness, once SNMP has been erroneously discovered, if
we delete it from the interface and rescan, it is not rediscovered. If
we delete SNMP-SSI and rescan, it is also not rediscovered. If we
delete them both and restart opennms and then rescan, they both show up!

How can we safely use a non-standard SNMP port? I have read
http://www.opennms.org/wiki/Monitor_several_SNMP_Agents but it has not
helped with the problem of discovering a bogus SNMP on 161 /udp when it
actually running on another port. Thanks - John

[Jeff Gehlbach]

Don't change the SNMP parameters in the individual daemon configs.
Change them in snmp-config.xml instead, as the values there get used
by default for all SNMP operations unless overridden by another
mechanism. You'll still need to restart after making changes, since
you're mangling v3 stuff which currently can't be done in the restart-
free web UI way.

-jeff

[John A. Sullivan III]

Post by Jeff Gehlbach
Don't change the SNMP parameters in the individual daemon configs.
Change them in snmp-config.xml instead, as the values there get used
by default for all SNMP operations unless overridden by another
mechanism. You'll still need to restart after making changes, since
you're mangling v3 stuff which currently can't be done in the restart-
free web UI way.

<snip>
Thanks, Jeff, but I'm a little confused by that although that may be
because I am being unnecessarily redundant.

I did change snmp-config.xml although I wasn't aware I needed a restart
after changing that file. Thanks for the heads up. I currently reads
(data changed):

<?xml version="1.0" encoding="UTF-8"?>
<snmp-config xmlns="http://xmlns.opennms.org/xsd/config/snmp" retry="1" timeout="1800" read-community="public" version="v2c">
<definition read-community="somepassphrase" version="v1">
<ns1:range xmlns:ns2="http://xmlns.opennms.org/xsd/types"
begin="172.x.x.3" end="172.x.x.254"/>
</definition>
<definition version="v3" security-name="snmpuser" auth-passphrase="password" auth-protocol="SHA" privacy-passphrase="password" privacy-protocol="DES" port="161">
<ns3:range xmlns:ns3="http://xmlns.opennms.org/xsd/types"
begin="172.x.y.8" end="172.x.y.9"/>
</definition>
<definition version="v3" security-name="snmpuser" auth-passphrase="password" auth-protocol="SHA" privacy-passphrase="password" privacy-protocol="AES" port="961">
<ns3:range xmlns:ns3="http://xmlns.opennms.org/xsd/types"
begin="172.z.z.1" end="172.x.z.254"/>
</definition>
</snmp-config>

That seems to be working for connecting the SNMP daemons.

However, I do want to know if an SNMP daemon fails. That's why I added
it on all ports it uses as a discovered and polled service, i.e., both
the SNMP service on port 161 where I cannot change the port on the
daemon and the SNMP-SSI service on a different port for those systems
where I can.

This last part seems to be the problem. Perhaps it is unnecessary. It
does not appear ONMS sends a notification on losing SNMP contact but
that may be configurable; we are exploring events today.

So why would the discovery service "discover" the SNMP service defined
on udp port 161 if a system is not even listening on port 161 but is
running an SNMP daemon on a different port? Thanks - John

[John A. Sullivan III]

Post by Jeff Gehlbach
Don't change the SNMP parameters in the individual daemon configs.
Change them in snmp-config.xml instead, as the values there get used
by default for all SNMP operations unless overridden by another
mechanism. You'll still need to restart after making changes, since
you're mangling v3 stuff which currently can't be done in the restart-
free web UI way.

<snip>
Oops! Never mind. Now I get it. The discovery definition for SNMP does
not have a port configured. It pulls the port from snmp-config.xml.
That's why the SNMP service is being discovered on the devices running
SNMP-SSI (i.e., SNMP on a different port) - it is using the non-default
port read from snmp-config.xml to do the discovery test and not port
161. Sorry for being so dense! Thanks - John