[c-nsp] snmpwalk for switch port status

[Matlock, Kenneth L]

And that's what I resorted to using (CLI access using expect, and then
pipe it to another script to parse it)

Unfortunately in my world, 500 days uptime is on the low side. We have
multiple chassis that have been up and running (and stable) for 6+ years
uptime now (and yes, we've mitigated the security issues on the code
revisions we're running). I manage the network for 3 hospitals, and 30+
clinics, so as you can imagine getting a downtime to 'upgrade' the code
is problematic (let alone the whole testing/validation process).

It's a lot more complicated to parse the CLI output, instead of just
getting a single value via SNMP. Doable? Yes. More work than necessary?
Yes. :)

Ken Matlock
Network Analyst
Exempla Healthcare
(303) 467-4671
matlockk at exempla.org



-----Original Message-----
From: Eric Hoelzle [mailto:eric.hoelzle at gmail.com] 
Sent: Wednesday, November 18, 2009 9:04 AM
To: Matlock, Kenneth L
Cc: Howard Jones; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] snmpwalk for switch port status

If you have CLI access as well, you can get the box uptime that way
and do some math.

In my world, 500 days uptime is an exception so a reboot is
acceptable.  Scripts like this are usually for access layer capacity
planning or cleanup.

--
Eric


On Wed, Nov 18, 2009 at 10:53 AM, Matlock, Kenneth L
<MatlockK at exempla.org> wrote:
> Well, what I meant.. :)
>
> They COULD expose a NEW OID for those values :)
>
> I agree that their hands are tied as far as the RFC, but that doesn't
> preclude a new OID tree.
>
> Ken Matlock
> Network Analyst
> Exempla Healthcare
> (303) 467-4671
> matlockk at exempla.org
>
>
>
> -----Original Message-----
> From: Howard Jones [mailto:howie at thingy.com]
> Sent: Wednesday, November 18, 2009 8:42 AM
> To: Matlock, Kenneth L
> Cc: Eric Hoelzle; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] snmpwalk for switch port status
>
> Matlock, Kenneth L wrote:
>> Seeing this script reminded me of a pet peeve I have with Cisco. Why
> oh
>> why did they use a 32-bit int for the uptime of the switch and port,
> and
>> use 1/100th second resolution, so after 497 days the counter rolls
> over
>> back to 0? Was a 64 bit int (or 1/10 a second resolution) not good
>> enough? :)
>>
>> The chassis knows the real uptime (a 'show ver' shows it), why not
>> expose that value to SNMP, and the same for the port last changed
> state?
>>
> Because then it would not be following RFC 1907/3418, which specify
it's
> a 32-bit int. It's not Cisco's fault (leaving aside that they are one
of
> the authors of RFC 1907 :-) ). You wouldn't want Cisco to not follow
> standards, would you? ;-)
>