-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, Just wondering if there are any pool of public accessible (read-only) snmp enabled devices that one can access for testing purposes (such as snmpwalk, polling devices via oid/mib, graphing chart..etc)? I'm looking for a pool of devices that I run my test on. Any pointers will be appreciated. regards, /virendra -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCJzLfpbZvCIJx1bcRAqLcAJ95PzxXE4v51JgzTpeqfuEDZG6ibgCaAg20 WJxjcsJYroHriTPr635QOBE= =SV3b -----END PGP SIGNATURE-----
Hmm, good idea. I add my voice to this question. But, btw, SNMP implementations are extremely buggy. Last 2 examples from my experience (with snmpstat system): - I found Cisco which have packet countters (on interface) _decreased_ instead of _increased_ (but octet counters are _increased_); - I have Cisco and interface, which do not report type if you ask it by exact request, but you can read type by requesting 'snmpwalk' ('get next variable'); - many many devices can be kicked down by SNMP packets (I kicked down Pix firewall in one point, and few 6509 switches in other). So, it is not so easy - to have such publickly available devices. I hear about companies whho rent you network systems (just full network, not a separae cisco or 3-com) for learning purposes; may be, use them? ----- Original Message ----- From: "Vicky Rode" <vickyr@socal.rr.com> To: <nanog@merit.edu> Sent: Thursday, March 03, 2005 7:53 AM Subject: public accessible snmp devices?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi there,
Just wondering if there are any pool of public accessible (read-only) snmp enabled devices that one can access for testing purposes (such as snmpwalk, polling devices via oid/mib, graphing chart..etc)?
I'm looking for a pool of devices that I run my test on.
Any pointers will be appreciated.
regards, /virendra -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCJzLfpbZvCIJx1bcRAqLcAJ95PzxXE4v51JgzTpeqfuEDZG6ibgCaAg20 WJxjcsJYroHriTPr635QOBE= =SV3b -----END PGP SIGNATURE-----
Alexei Roudnev wrote:
Hmm, good idea. I add my voice to this question.
But, btw, SNMP implementations are extremely buggy. Last 2 examples from my experience (with snmpstat system): - I found Cisco which have packet countters (on interface) _decreased_ instead of _increased_ (but octet counters are _increased_);
And lately, for reasons undetermined so far there has been instances of both vendor C and J where counters suddenly go to zero either temporarily (like 1,2,3,4,0,6,7,8,0,10,etc.) or reset altogether without any reason. Pete
On Sun, 2005-03-06 at 13:24 +0200, Petri Helenius wrote:
And lately, for reasons undetermined so far there has been instances of both vendor C and J where counters suddenly go to zero either temporarily (like 1,2,3,4,0,6,7,8,0,10,etc.) or reset altogether without any reason.
Was the device restarted? Was the polled interface so overloaded that UDP was dropped and your tool/application just happened to show a zero instead? -Jim P.
Jim Popovitch wrote:
Was the device restarted? Was the polled interface so overloaded that UDP was dropped and your tool/application just happened to show a zero instead?
That would be no on both counts. All packets got replies and while debugging the polling interval was fairly short. (on order of seconds) so restart would be out of question and it repeated frequently enough not to be a failover either. Pete
On Sun, 2005-03-06 at 17:09 +0200, Petri Helenius wrote:
the polling interval was fairly short. (on order of seconds)
I think this could be relevant. a LOT of devices drop snmp requests when they get busy or when too many incoming requests occur. Are you sure that you were the only one polling that device? Perhaps someone else put it into a "busy" state. Too often with SNMP devices and tools a '0' can mean things other than zero. -Jim P.
Jim Popovitch wrote:
I think this could be relevant. a LOT of devices drop snmp requests when they get busy or when too many incoming requests occur. Are you sure that you were the only one polling that device? Perhaps someone else put it into a "busy" state. Too often with SNMP devices and tools a '0' can mean things other than zero.
So you are saying that it's ok for a Cisco or Juniper router to return zero for a counter when they feel "busy" ? My RFC collection tells a different story. Pete
On Sun, 2005-03-06 at 17:18 +0200, Petri Helenius wrote:
So you are saying that it's ok for a Cisco or Juniper router to return zero for a counter when they feel "busy" ?
Is it OK? No. Does it happen? Sure. The problem *could* be as simple as this: What do you return for an integer value when the requested data is either unavailable, corrupted, or a fault occurred in the collection process? Null? Maybe, except that NULL and zero can be perceived as the same by some programmatic functions and integer operators. Assuming that somewhere during the polling failure an error is generated.... Does it make sense to always check errno every poll? Constantly checking for errors is perceived as "overhead" by a LOT of programmers. Don't assume that I adhere to this line of thinking, I'm just explaining to you how others may, and probably do, think.
My RFC collection tells a different story.
My experiences show that no complete segment of business, education, or government ever implements systems and networks according to holistic RFC thinking. YMMV. -Jim P.
Jim Popovitch wrote:
On Sun, 2005-03-06 at 17:18 +0200, Petri Helenius wrote:
My RFC collection tells a different story.
My experiences show that no complete segment of business, education, or government ever implements systems and networks according to holistic RFC thinking. YMMV.
The important thing is to determine which RFCs are being implemented, and why. <http://www.lightreading.com/document.asp?doc_id=2756> jc
On Sun, 2005-03-06 at 09:12 -0800, JC Dill wrote:
The important thing is to determine which RFCs are being implemented, and why.
:-) Not that I am defending Juniper, but it seems to me that their response "that the RFC wasn’t serious" is an indicator that they did in fact get the "joke", however they didn't want to reply in a jovial fashion. -Jim P.
It's OK to see any garbage in SNMP; I never got surprised (as I was not surprised when I killed firewall by snmpwalk). No one (in reality) makes good QA on SNMP functions (on routers or switches). I already have a few sanity checks in 'snmpstat', may be I should add one more (ignore answers with 0 counters). ----- Original Message ----- From: "Petri Helenius" <pete@he.iki.fi> To: "Jim Popovitch" <jimpop@yahoo.com> Cc: "Alexei Roudnev" <alex@relcom.net>; <vickyr@socal.rr.com>; <nanog@merit.edu> Sent: Sunday, March 06, 2005 7:18 AM Subject: Re: public accessible snmp devices?
Jim Popovitch wrote:
I think this could be relevant. a LOT of devices drop snmp requests when they get busy or when too many incoming requests occur. Are you sure that you were the only one polling that device? Perhaps someone else put it into a "busy" state. Too often with SNMP devices and tools a '0' can mean things other than zero.
So you are saying that it's ok for a Cisco or Juniper router to return zero for a counter when they feel "busy" ?
My RFC collection tells a different story.
Pete
Cisco drops SNMP requests but not return '0', I saw it (dropped requests because of _busy_) many times. ----- Original Message ----- From: "Petri Helenius" <pete@he.iki.fi> To: "Jim Popovitch" <jimpop@yahoo.com> Cc: "Alexei Roudnev" <alex@relcom.net>; <vickyr@socal.rr.com>; <nanog@merit.edu> Sent: Sunday, March 06, 2005 7:18 AM Subject: Re: public accessible snmp devices?
Jim Popovitch wrote:
I think this could be relevant. a LOT of devices drop snmp requests when they get busy or when too many incoming requests occur. Are you sure that you were the only one polling that device? Perhaps someone else put it into a "busy" state. Too often with SNMP devices and tools a '0' can mean things other than zero.
So you are saying that it's ok for a Cisco or Juniper router to return zero for a counter when they feel "busy" ?
My RFC collection tells a different story.
Pete
Petri Helenius wrote:
And lately, for reasons undetermined so far there has been instances of both vendor C and J where counters suddenly go to zero either temporarily (like 1,2,3,4,0,6,7,8,0,10,etc.) or reset altogether without any reason.
Pete
I am unclear as to what Vendors "C" and "J" are. Could you clarify please? thanks /vijay
participants (6)
-
Alexei Roudnev -
JC Dill -
Jim Popovitch -
Petri Helenius -
Vicky Rode -
vijay gill