Opennms scanning outside ip ranges explicitly configured for discovery and snmpop

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Opennms scanning outside ip ranges explicitly configured for discovery and snmpop

lesly dorval
Dont believe everything you read.

... set auto-discovery="false" in linkd-configuration.xml. This notes applies only for 1.3.8. By default in following release autodiscovery is disabled.  Read more there: http://www.opennms.org/index.php/Linkd

But in 1.5.93-1  auto-discovery is set to true with a range of 10.1.1.1/8 which may explain why I had those entries in my capsd.log

Thanks for your input Tomás Heredia


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-discuss mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Opennms scanning outside ip ranges explicitly configured for discovery and snmpop

lesly dorval

The information in linkd is definitely commented out and linkd was not the culprit. 
 
After Jeff suggested opennms was probably scanning the ifTable..., I took a look at the physical interfaces on the amazon nodes.  The ip addresses were the actual private ip addresses on the physical interfaces of the Amanzon ec2 instances that I also collect statistics on.
So, I went into Admin>>Manage and Unmaged interfaces and un-checked every service with an 10.something ip address.



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-discuss mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Opennms scanning outside ip ranges explicitly configured for discovery and snmpop

Jeff Gehlbach
On Sep 10, 2008, at 4:56 PM, lesly dorval wrote:

> So, I went into Admin>>Manage and Unmaged interfaces and un-checked  
> every service with an 10.something ip address.

Unmanaging an interface does not disqualify that interface from  
consideration as an SNMP primary interface.  It just tells the poller  
not to try to test the availability of any services on that interface.

You'll need to make the changes I mentioned earlier in collectd-
configuration.xml.  This is because polling and data collection are  
two separate processes.

-jeff

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-discuss mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Opennms scanning outside ip ranges explicitly configured for discovery and snmpop

lesly dorval
This is what my collectd-configuration looks like.
<package name="example1">
                <filter>IPADDR != '0.0.0.0'</filter>
                <include-range begin="172.17.0.0" end="172.17.255.254"/>
                <specific>public_ec2_IP1</specific>
                ...
                <specific>public_ec2_IP10</specific>
                <service name="SNMP" interval="300000" user-defined="false" status="on">
                        <parameter key="collection" value="default"/>
                </service>
        </package>

There is no 10-range to exclude, unless you are suggesting something similar to
 <filter>IPADDR != '10.0.0.0'</filter>
which I doubt.

Moreover, I generated new suspect events for the public addresses.  Do i need to consider and account for  the service provider's association of a private to public address?

You clarification is welcome.

--- On Wed, 9/10/08, Jeff Gehlbach <[hidden email]> wrote:

Unmanaging an interface does not disqualify that interface from
consideration as an SNMP primary interface. It just tells the poller
not to try to test the availability of any services on that interface.

You'll need to make the changes I mentioned earlier in collectd-
configuration.xml. This is because polling and data collection are
two separate processes.

-jeff


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-discuss mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Opennms scanning outside ip ranges explicitly configured for discovery and snmpop

Jeff Gehlbach
On Sep 10, 2008, at 5:37 PM, lesly dorval wrote:

> This is what my collectd-configuration looks like.
> <package name="example1">
>                 <filter>IPADDR != '0.0.0.0'</filter>
>                 <include-range begin="172.17.0.0"  
> end="172.17.255.254"/>
>                 <specific>public_ec2_IP1</specific>
>                 ...
>                 <specific>public_ec2_IP10</specific>
>                 <service name="SNMP" interval="300000" user-
> defined="false" status="on">
>                         <parameter key="collection" value="default"/>
>                 </service>
>         </package>

OK, yeah, assuming that "public_ec2_IP1" et al. are stand-ins for  
actual IP addresses, this should do the trick.

> There is no 10-range to exclude, unless you are suggesting something  
> similar to
>  <filter>IPADDR != '10.0.0.0'</filter>
> which I doubt.

By not including the 10.252.x addresses in this package, you have  
excluded them.  The default collectd-configuration.xml, however,  
includes the range 1.1.1.1-254.254.254.254.  That's what I was  
referring to.

> Moreover, I generated new suspect events for the public addresses.  
> Do i need to consider and account for  the service provider's  
> association of a private to public address?

Not sure what that last term means.

When Capsd discovers SNMP on an interface, it goes and "looks inside"  
the node, digging through the ifTable, ifXTable, and ipAddrTable.  So  
openNMS now "knows about" even interfaces with addresses that it can't  
reach.  Because you've excluded the 10.252.x addresses from your  
collectd package, though, the collector should no longer be trying to  
talk SNMP to those interfaces.

-jeff

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-discuss mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Opennms scanning outside ip ranges explicitly configured for discovery and snmpop

lesly dorval
Thank you for this resolution.

--- On Wed, 9/10/08, Jeff Gehlbach <[hidden email]> wrote:
From: Jeff Gehlbach <[hidden email]>
Subject: Re: [opennms-discuss] Opennms scanning outside ip ranges explicitly configured for discovery and snmpop
To: [hidden email], "General OpenNMS Discussion" <[hidden email]>
Date: Wednesday, September 10, 2008, 5:47 PM

On Sep 10, 2008, at 5:37 PM, lesly dorval wrote:

> This is what my collectd-configuration looks like.
> <package name="example1">
> <filter>IPADDR != '0.0.0.0'</filter>
> <include-range begin="172.17.0.0"
> end="172.17.255.254"/>
> <specific>public_ec2_IP1</specific>
> ...
> <specific>public_ec2_IP10</specific>
> <service name="SNMP"
interval="300000" user-
> defined="false" status="on">
> <parameter key="collection"
value="default"/>
> </service>
> </package>

OK, yeah, assuming that "public_ec2_IP1" et al. are stand-ins for
actual IP addresses, this should do the trick.

> There is no 10-range to exclude, unless you are suggesting something
> similar to
> <filter>IPADDR != '10.0.0.0'</filter>
> which I doubt.

By not including the 10.252.x addresses in this package, you have
excluded them. The default collectd-configuration.xml, however,
includes the range 1.1.1.1-254.254.254.254. That's what I was
referring to.

> Moreover, I generated new suspect events for the public addresses.
> Do i need to consider and account for the service provider's
> association of a private to public address?

Not sure what that last term means.

When Capsd discovers SNMP on an interface, it goes and "looks inside"

the node, digging through the ifTable, ifXTable, and ipAddrTable. So
openNMS now "knows about" even interfaces with addresses that it
can't
reach. Because you've excluded the 10.252.x addresses from your
collectd package, though, the collector should no longer be trying to
talk SNMP to those interfaces.

-jeff


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-discuss mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-discuss