SNMP collection from Waverider radio

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

SNMP collection from Waverider radio

Alan Clayson
Hello

A couple of years ago I tried to set up Opennms on both Ubuntu and
Centos installations and finally gave up after resounding failures using
the program to collect meaningful data from our network.

Today with vastly improved versions of both (Opennms 1.593 and Ubuntu
8.04) I have the same problems.

Basically I can't pull any SNMP data from Waverider CCU's. I know from
other posts that I'm not alone in this situation, but haven't been able
to find definitively that it can't be done.

Waverider technical support has offered the following explanation as to
how their system responds to SNMP query:

The EUM has two (2) Ethernet addresses: the statically or dynamically
set IP is eth0's primary address. The local link, or 'fixed' IP
(169.254.10.250) is the secondary eth0 address. If you query an OID from
a PC that is on the 169.254.0.0/16 subnet, the local link IP will reply.
If the same query originates from a PC that resides on the same subnet
as the EUM's static or dynamic IP, the EUM's static or dynamic IP will
reply. We recommend configuring your SNMP manager to attach to the
device's 'closest' IP address. For example, if you wish to query some
OIDs on a CCU in routed mode from your SNMP manager that is attached to
the same switch (subnet), use the CCU's (primary) Ethernet IP to
connect.

Like NICs and similar network devices, the loopback (lo0) is the
software address (127.0.0.1) for both EUM and CCU, and cannot be used to
access the device.

Note that when querying via SNMP, there is an OID instance for each of
the three interfaces:

.1 = lo0 (software loopback)
.2 = eth0 (Ethernet)
.3 = rdr1 (radio)

For example, if you walk the interfaces group MIB's 'ifDesc' OID
(1.3.6.1.2.1.2), there will be three instances, one for each interface:

1.3.6.1.2.1.2.1 = lo0
1.3.6.1.2.1.2.2 = eth0
1.3.6.1.2.1.2.3 = rdr1

Similarly, walking the ifSpeed OID (1.3.6.1.2.1.5) results in the
nominal bandwidth of each interface:

1.3.6.1.2.1.5.1 = 0
1.3.6.1.2.1.5.2 = 10000000
1.3.6.1.2.1.5.3 = 2750000

I will be loading up and trying OpenNMS in my test lab here.

*********** End of Waverider tech support ***********
All OID's behave as expected when using snmpwalk, snmpget, etc.

At the moment, I'm simply using mib2 OIDS in the data collection
configuration attempting to get some indication of collection in the
collectd output file. I've limited SNMP collection to only two items,
the two ccu's in the sytem.

Opennms discovers nodes OK, but this appears to be through the local
links.

I can collect some data from End User modems, but only through the lo0
link, not from links accessed through the static address. I can't
collect anything from CCU's (transceivers). Obviously the first network
piece of hardware that I connect to is my end-user modem. I assume that
this has something to do with the subnet mask that Opennms is using for
polling, collecting, etc.

No data appears in the snmpinterface table data for snmpipadentnetmask.
I can , of course, INSERT this information, but it makes no difference.
Other data collected in this file is sketchy as well (snmpifindex = -100
[if anything], no snmpiftype or snmpdescr). Basically no information
other that the subnet address. Inserting values into this table and the
ipinterface table will effect the web GUI, but does nothing to alter
data collection

It appears with my limited knowledge of these things that Opennms is not
discovering on the correct subnet mask. The local link addresses have a
mask of 16. Our static addresses at the present are on a single subnet
with a mask of 25. According to Waverider, the static IP address on my
PC should bring a response from the static address of the eum. This
doesn't appear to happen.

The Opennms documentation details the requirements for an index to be
selected as 'Primary'(a loopback address exists with a non 127.*.*.* IP
address and meets the qualifications above - then it is chosen.

However, several people have reported the need to monitor SNMP on a
device that either does not have a valid primary interface candidate or
they wish to use another address altogether. At the moment a solution
does not exist, although we hope to have something in place soon.)

I don't believe this covers the problems I'm having as they seem to be
related to how the program interprets or uses subnet masks.

I would be very grateful if anyone could shed any light on this matter.

With thanks.


-------------------------------------------------------------------------
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: SNMP collection from Waverider radio

Jeff Gehlbach
On Aug 27, 2008, at 3:27 PM, Alan Clayson wrote:
> Basically I can't pull any SNMP data from Waverider CCU's. I know from
> other posts that I'm not alone in this situation, but haven't been  
> able
> to find definitively that it can't be done.

Can you reference archives of some of the other posts to which you  
refer?

> Waverider technical support has offered the following explanation as  
> to
> how their system responds to SNMP query:
>
> The EUM has two (2) Ethernet addresses: the statically or dynamically
> set IP is eth0's primary address. The local link, or 'fixed' IP
> (169.254.10.250) is the secondary eth0 address. If you query an OID  
> from
> a PC that is on the 169.254.0.0/16 subnet, the local link IP will  
> reply.
> If the same query originates from a PC that resides on the same subnet
> as the EUM's static or dynamic IP, the EUM's static or dynamic IP will
> reply.

That sounds like an explanation of normally expected behavior -- SNMP  
response PDUs should always originate from the same IP address on  
which the corresponding request PDU was received.  The SNMP4J library  
that OpenNMS uses will discard response PDUs that come from the wrong  
IP address.

> We recommend configuring your SNMP manager to attach to the
> device's 'closest' IP address. For example, if you wish to query some
> OIDs on a CCU in routed mode from your SNMP manager that is attached  
> to
> the same switch (subnet), use the CCU's (primary) Ethernet IP to
> connect.

You may have to do some futzing with collection packages in order to  
make this happen.  I'll explain below.

> Like NICs and similar network devices, the loopback (lo0) is the
> software address (127.0.0.1) for both EUM and CCU, and cannot be  
> used to
> access the device.

Right, so when Waverider says "loopback" they mean it in the Unix  
sense rather than the IOS sense.


> <snip>
> *********** End of Waverider tech support ***********

> All OID's behave as expected when using snmpwalk, snmpget, etc.

Can you walk the "system", "ifTable", "ifXTable", and "ipAddrTable" of  
one of these radios?  If so, please provide the command line used  
(redacting community strings is fine, but please include everything  
else) and the output of the commands.

> At the moment, I'm simply using mib2 OIDS in the data collection
> configuration attempting to get some indication of collection in the
> collectd output file. I've limited SNMP collection to only two items,
> the two ccu's in the sytem.

Can you provide the configs that you have customized to this end?

> Opennms discovers nodes OK, but this appears to be through the local
> links.

That's the 169.254.0.0/16 interfaces, right?  It seems odd that this  
network is in use, as it's reserved for Zeroconf link-local addresses  
-- see http://en.wikipedia.org/wiki/Zeroconf#Choosing_addresses for  
details.  Does the openNMS server have an IP address in that same  
network?  Or are you somehow routing / NATing traffic in and out of  
that range?

> I can collect some data from End User modems, but only through the lo0
> link, not from links accessed through the static address.

Wait, the Waverider support message indicated that the lo0 interfaces  
are all 127.0.0.1 -- how can you reach those interfaces from openNMS  
in order to collect data from them?

> I can't
> collect anything from CCU's (transceivers). Obviously the first  
> network
> piece of hardware that I connect to is my end-user modem. I assume  
> that
> this has something to do with the subnet mask that Opennms is using  
> for
> polling, collecting, etc.

openNMS does not use a netmask, per se, for anything -- that's a  
function of the operating system on which openNMS is running.

> No data appears in the snmpinterface table data for  
> snmpipadentnetmask.

Does a valid netmask appear in the output of an snmpwalk of the  
ipAddrTable on the CCUs?

> I can , of course, INSERT this information, but it makes no  
> difference.

I wouldn't expect that it would -- I believe that information is kept  
only to be displayed for human consumption and maybe by Linkd (which  
is turned off by default, and you should not turn on).

> Other data collected in this file is sketchy as well (snmpifindex =  
> -100
> [if anything], no snmpiftype or snmpdescr). Basically no information
> other that the subnet address. Inserting values into this table and  
> the
> ipinterface table will effect the web GUI, but does nothing to alter
> data collection

It's beginning to sound as if these devices have buggy SNMP agents.  
Just on a hunch, could you try walking the following OID on one of them?

.1.3.6.1.4.1.2021.100

It may return nothing at all, but if it returns a bunch of stuff,  
please include that as it may be helpful.

> It appears with my limited knowledge of these things that Opennms is  
> not
> discovering on the correct subnet mask.

You need to leave behind that theory.  The netmask in the ipAddrTable  
has no bearing on openNMS' ability to collect data from an agent.

> The local link addresses have a
> mask of 16. Our static addresses at the present are on a single subnet
> with a mask of 25. According to Waverider, the static IP address on my
> PC should bring a response from the static address of the eum. This
> doesn't appear to happen.

One way to see whether this is happening is to run tcpdump on the  
openNMS server while making an uncomplicated SNMP request to one of  
these devices.  To avoid confusion, it's best to stop OpenNMS before  
doing this.  I'll assume that one of them is at 169.254.0.1.  The  
tcpdump command to run would be:

tcpdump -i any -v 'host 169.254.0.1 and port 161'

While that is running, do a very simple SNMP request from a separate  
shell on the openNMS server:

snmpget -v1 -c public 169.254.0.1 sysObjectID.0

The tcpdump output will show you which source address the response PDU  
came from.

> The Opennms documentation details the requirements for an index to be
> selected as 'Primary'(a loopback address exists with a non 127.*.*.*  
> IP
> address and meets the qualifications above - then it is chosen.
>
> However, several people have reported the need to monitor SNMP on a
> device that either does not have a valid primary interface candidate  
> or
> they wish to use another address altogether. At the moment a solution
> does not exist, although we hope to have something in place soon.)

When you quote documentation from the wiki, please also provide a link  
to the page that you are quoting.  I had to use Google to determine  
that the above is from <http://www.opennms.org/index.php/FAQ-Troubleshooting#Q:_I_can_snmpwalk_a_device.2C_but_OpenNMS_won.27t_collect_data_on_it.2C_why.3F 
 >.

You've already said that the lo0 interfaces on these devices are  
numbered as 127.0.0.1, so the more commonly encountered "lowest  
numbered interface that exists in some collection package wins" rule  
should apply in your case.

-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: SNMP collection from Waverider radio

Alan Clayson
jeff,

Many thanks for the very detailed analysis. This is most helpful (and
appreciated).

I've got some homework to do and will send results after they're
available.

Thanks again.

On Wed, 27 Aug 2008 17:48:40 -0400, you wrote:

>On Aug 27, 2008, at 3:27 PM, Alan Clayson wrote:
>> Basically I can't pull any SNMP data from Waverider CCU's. I know from
>> other posts that I'm not alone in this situation, but haven't been  
>> able
>> to find definitively that it can't be done.
>
>Can you reference archives of some of the other posts to which you  
>refer?
>
>> Waverider technical support has offered the following explanation as  
>> to
>> how their system responds to SNMP query:
>>
>> The EUM has two (2) Ethernet addresses: the statically or dynamically
>> set IP is eth0's primary address. The local link, or 'fixed' IP
>> (169.254.10.250) is the secondary eth0 address. If you query an OID  
>> from
>> a PC that is on the 169.254.0.0/16 subnet, the local link IP will  
>> reply.
>> If the same query originates from a PC that resides on the same subnet
>> as the EUM's static or dynamic IP, the EUM's static or dynamic IP will
>> reply.
>
>That sounds like an explanation of normally expected behavior -- SNMP  
>response PDUs should always originate from the same IP address on  
>which the corresponding request PDU was received.  The SNMP4J library  
>that OpenNMS uses will discard response PDUs that come from the wrong  
>IP address.
>
>> We recommend configuring your SNMP manager to attach to the
>> device's 'closest' IP address. For example, if you wish to query some
>> OIDs on a CCU in routed mode from your SNMP manager that is attached  
>> to
>> the same switch (subnet), use the CCU's (primary) Ethernet IP to
>> connect.
>
>You may have to do some futzing with collection packages in order to  
>make this happen.  I'll explain below.
>
>> Like NICs and similar network devices, the loopback (lo0) is the
>> software address (127.0.0.1) for both EUM and CCU, and cannot be  
>> used to
>> access the device.
>
>Right, so when Waverider says "loopback" they mean it in the Unix  
>sense rather than the IOS sense.
>
>
>> <snip>
>> *********** End of Waverider tech support ***********
>
>> All OID's behave as expected when using snmpwalk, snmpget, etc.
>
>Can you walk the "system", "ifTable", "ifXTable", and "ipAddrTable" of  
>one of these radios?  If so, please provide the command line used  
>(redacting community strings is fine, but please include everything  
>else) and the output of the commands.
>
>> At the moment, I'm simply using mib2 OIDS in the data collection
>> configuration attempting to get some indication of collection in the
>> collectd output file. I've limited SNMP collection to only two items,
>> the two ccu's in the sytem.
>
>Can you provide the configs that you have customized to this end?
>
>> Opennms discovers nodes OK, but this appears to be through the local
>> links.
>
>That's the 169.254.0.0/16 interfaces, right?  It seems odd that this  
>network is in use, as it's reserved for Zeroconf link-local addresses  
>-- see http://en.wikipedia.org/wiki/Zeroconf#Choosing_addresses for  
>details.  Does the openNMS server have an IP address in that same  
>network?  Or are you somehow routing / NATing traffic in and out of  
>that range?
>
>> I can collect some data from End User modems, but only through the lo0
>> link, not from links accessed through the static address.
>
>Wait, the Waverider support message indicated that the lo0 interfaces  
>are all 127.0.0.1 -- how can you reach those interfaces from openNMS  
>in order to collect data from them?
>
>> I can't
>> collect anything from CCU's (transceivers). Obviously the first  
>> network
>> piece of hardware that I connect to is my end-user modem. I assume  
>> that
>> this has something to do with the subnet mask that Opennms is using  
>> for
>> polling, collecting, etc.
>
>openNMS does not use a netmask, per se, for anything -- that's a  
>function of the operating system on which openNMS is running.
>
>> No data appears in the snmpinterface table data for  
>> snmpipadentnetmask.
>
>Does a valid netmask appear in the output of an snmpwalk of the  
>ipAddrTable on the CCUs?
>
>> I can , of course, INSERT this information, but it makes no  
>> difference.
>
>I wouldn't expect that it would -- I believe that information is kept  
>only to be displayed for human consumption and maybe by Linkd (which  
>is turned off by default, and you should not turn on).
>
>> Other data collected in this file is sketchy as well (snmpifindex =  
>> -100
>> [if anything], no snmpiftype or snmpdescr). Basically no information
>> other that the subnet address. Inserting values into this table and  
>> the
>> ipinterface table will effect the web GUI, but does nothing to alter
>> data collection
>
>It's beginning to sound as if these devices have buggy SNMP agents.  
>Just on a hunch, could you try walking the following OID on one of them?
>
>.1.3.6.1.4.1.2021.100
>
>It may return nothing at all, but if it returns a bunch of stuff,  
>please include that as it may be helpful.
>
>> It appears with my limited knowledge of these things that Opennms is  
>> not
>> discovering on the correct subnet mask.
>
>You need to leave behind that theory.  The netmask in the ipAddrTable  
>has no bearing on openNMS' ability to collect data from an agent.
>
>> The local link addresses have a
>> mask of 16. Our static addresses at the present are on a single subnet
>> with a mask of 25. According to Waverider, the static IP address on my
>> PC should bring a response from the static address of the eum. This
>> doesn't appear to happen.
>
>One way to see whether this is happening is to run tcpdump on the  
>openNMS server while making an uncomplicated SNMP request to one of  
>these devices.  To avoid confusion, it's best to stop OpenNMS before  
>doing this.  I'll assume that one of them is at 169.254.0.1.  The  
>tcpdump command to run would be:
>
>tcpdump -i any -v 'host 169.254.0.1 and port 161'
>
>While that is running, do a very simple SNMP request from a separate  
>shell on the openNMS server:
>
>snmpget -v1 -c public 169.254.0.1 sysObjectID.0
>
>The tcpdump output will show you which source address the response PDU  
>came from.
>
>> The Opennms documentation details the requirements for an index to be
>> selected as 'Primary'(a loopback address exists with a non 127.*.*.*  
>> IP
>> address and meets the qualifications above - then it is chosen.
>>
>> However, several people have reported the need to monitor SNMP on a
>> device that either does not have a valid primary interface candidate  
>> or
>> they wish to use another address altogether. At the moment a solution
>> does not exist, although we hope to have something in place soon.)
>
>When you quote documentation from the wiki, please also provide a link  
>to the page that you are quoting.  I had to use Google to determine  
>that the above is from <http://www.opennms.org/index.php/FAQ-Troubleshooting#Q:_I_can_snmpwalk_a_device.2C_but_OpenNMS_won.27t_collect_data_on_it.2C_why.3F 
> >.
>
>You've already said that the lo0 interfaces on these devices are  
>numbered as 127.0.0.1, so the more commonly encountered "lowest  
>numbered interface that exists in some collection package wins" rule  
>should apply in your case.
>
>-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

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