-----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
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?
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
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
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
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:
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).
Cisco drops SNMP requests but not return '0', I saw it (dropped requests
because of _busy_) many times.
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