Mailing List Archive: Cisco: NSP

snmpwalk for switch port status

Index | Next | Previous | View Threaded

aptgetd at gmail

Nov 17, 2009, 12:46 PM

Post #1 of 10 (1930 views)
Permalink

snmpwalk for switch port status

Hi,

Can anyone point me in right direction for a perl script that will
snmpwalk the MIB for switch port status whether "up" or "down" including
total number of ports available?

I have approximately 400 switches that I would like to query via script
and pipe the results to a file for every device.

I'm currently querying it manually (see below) which is not scaling :-)

$ snmpwalk -c <community> <host_ip>
interfaces.ifTable.ifEntry.ifOperStatus | grep down

Any pointers will be greatly appreciated.

regards
sky

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

dwbielawa at liberty

Nov 17, 2009, 4:32 PM

Post #2 of 10 (1937 views)
Permalink

Re: snmpwalk for switch port status [In reply to]

We use switchmap (http://switchmap.sourceforge.net/) it outputs name, description, admin status, oper status, vlan, and mac addresses. It outputs to plain text, as well as HTML.

Thank You

Daniel Bielawa
Network Engineer
Liberty University Network Services

-----Original Message-----
From: cisco-nsp-bounces [at] puck [mailto:cisco-nsp-bounces [at] puck] On Behalf Of sky vader
Sent: Tuesday, November 17, 2009 3:47 PM
To: cisco-nsp [at] puck
Subject: [c-nsp] snmpwalk for switch port status

Hi,

Can anyone point me in right direction for a perl script that will
snmpwalk the MIB for switch port status whether "up" or "down" including
total number of ports available?

I have approximately 400 switches that I would like to query via script
and pipe the results to a file for every device.

I'm currently querying it manually (see below) which is not scaling :-)

$ snmpwalk -c <community> <host_ip>
interfaces.ifTable.ifEntry.ifOperStatus | grep down

Any pointers will be greatly appreciated.

regards
sky

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

frnkblk at iname

Nov 17, 2009, 6:51 PM

Post #3 of 10 (1893 views)
Permalink

Re: snmpwalk for switch port status [In reply to]

Do the relevant scripts with NAGIOS meet your needs? See, for example,
check_snmp_int.

Frank

-----Original Message-----
From: cisco-nsp-bounces [at] puck
[mailto:cisco-nsp-bounces [at] puck] On Behalf Of sky vader
Sent: Tuesday, November 17, 2009 2:47 PM
To: cisco-nsp [at] puck
Subject: [c-nsp] snmpwalk for switch port status

Hi,

Can anyone point me in right direction for a perl script that will
snmpwalk the MIB for switch port status whether "up" or "down" including
total number of ports available?

I have approximately 400 switches that I would like to query via script
and pipe the results to a file for every device.

I'm currently querying it manually (see below) which is not scaling :-)

$ snmpwalk -c <community> <host_ip>
interfaces.ifTable.ifEntry.ifOperStatus | grep down

Any pointers will be greatly appreciated.

regards
sky

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

braaen at zcorum

Nov 18, 2009, 6:02 AM

Post #4 of 10 (1883 views)
Permalink

Re: snmpwalk for switch port status [In reply to]

try this, written for Debian Linux so may or may not need modification to run
on your system.

#!/bin/bash

comunity=
host=
group=
list=
output=

if [ "$#" == "0" ]
then
echo "$0: No Arguments.... please put at least a host" >&2
echo "Usage: $0 [-c community_string] [-l list_of_snmp_indexes_file]
[-o file_to_output_to] hostname" >&2
exit 1
fi

while getopts :c:l:o:h opt
do
case $opt in
c) community="$OPTARG"
;;
l) list="$OPTARG"
;;
o) output="$OPTARG"
;;
h) echo "Usage: $0 [-c community_string] [-g
nagios_contact_group] [-l list_of_snmp_indexes_file] [-o file_to_output_to]
hostname" >&2
exit 0
;;
'?') echo "$0: invalid option -$OPTARG" >&2
echo "Usage: $0 [-c community_string] [-g
nagios_contact_group] [-l list_of_snmp_indexes_file] [-o file_to_output_to]
hostname" >&2
exit 1
;;
esac
done

shift $((OPTIND - 1))

host="$1"

if [ ! $community ]
then
community="public"
fi

if [ $list ]
then
list=`cat $list`
else
list=`snmpwalk -v 2c -c $community -Oe $host 1.3.6.1.2.1.31.1.1.1.1 |
egrep -v "( STRING: Nu0| STRING: T1 | STRING: Lo| STRING: LI| = STRING: Vi| =
STRING: Vt)" | sed 's/.*\.$[0-9]*$ = STRING:.*/\1/'`
fi

for i in $list
do
index=$i
type=`snmpget -v 2c -c $community -Oev $host 1.3.6.1.2.1.2.2.1.2.
$index | sed 's/^STRING: //'`
description=`snmpget -v 2c -c $community -Oev $host
1.3.6.1.2.1.31.1.1.1.18.$index | sed 's/^STRING: //'`
status=`snmpget -v 2c -c $community -Ov $host .1.3.6.1.2.1.2.2.1.7.
$index | sed 's/^INTEGER: $.*$(.)/\1/'`
protocol=`snmpget -v 2c -c $community -Ov $host .1.3.6.1.2.1.2.2.1.8.
$index | sed 's/^INTEGER: $.*$(.)/\1/'`

if [ $output ]
then
echo -e "$type\t$status\t$protocol\t$description" >>$output
else
echo -e "$type\t$status\t$protocol\t$description"
fi

done

--

----------------------

Brian Raaen
Network Engineer
braaen [at] zcorum

On Tuesday 17 November 2009, sky vader wrote:
> Hi,
>
> Can anyone point me in right direction for a perl script that will
> snmpwalk the MIB for switch port status whether "up" or "down" including
> total number of ports available?
>
> I have approximately 400 switches that I would like to query via script
> and pipe the results to a file for every device.
>
> I'm currently querying it manually (see below) which is not scaling :-)
>
> $ snmpwalk -c <community> <host_ip>
> interfaces.ifTable.ifEntry.ifOperStatus | grep down
>
>
> Any pointers will be greatly appreciated.
>
>
> regards
> sky
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

eric.hoelzle at gmail

Nov 18, 2009, 6:25 AM

Post #5 of 10 (1902 views)
Permalink

Re: snmpwalk for switch port status [In reply to]

Here's a version in perl that runs on windows or *nix. Net::SNMP required.

I have an older version using net::snmp::info that reads more cleanly,
but had trouble getting that module to work under ActiveState perl at
my current job.

--
Eric

--------[ begin paste ]-----
use Net::SNMP;

$ARGC = $#ARGV + 1;
if ($ARGC != 2) {
die "\nUsage: deadports.pl hostname num_days\n\n";
}

$pulldays = $ARGV[1];
$hostname = $ARGV[0];
$community = 'CHANGEME';

print "Unused Port report on $hostname for $pulldays days.";

## set up SNMP session
my ($session, $error) = Net::SNMP->session(
-version => 'snmpv2c',
-translate => '0',
-hostname => $hostname,
-community => $community,
-port => 161
);

if (!defined($session)) {
printf("ERROR: %s.\n", $error);
exit 1;
}

## OIDs
my $sysUpTime = '1.3.6.1.2.1.1.3.0';
my $sysName = '1.3.6.1.2.1.1.5.0';
my $oid_ifTable = '1.3.6.1.2.1.2.2';
my $oid_ifIndex = '1.3.6.1.2.1.2.2.1.1';
my $oid_ifdescr = '1.3.6.1.2.1.2.2.1.2.';
my $oid_ifoperstatus = '1.3.6.1.2.1.2.2.1.8.';
my $oid_iflastchange = '1.3.6.1.2.1.2.2.1.9.';
my $oid_ifadminstatus = '1.3.6.1.2.1.2.2.1.7.';

## Counters
$tot_ports = 0;
$pull_ports = 0;

##
# these subs go gather the data basic.
# get_sysuptime has a print at the end as well.
##

&get_sysuptime;

## can't run a report for more days that we have uptime
if (($uptime/8640000) < $pulldays) {
print "Sorry, the Device hasn't been up $pulldays days yet.\n\n";
exit 0;
}

&get_ifindex;

##
# for each interface returned by get_ifindex, gather detail data
# and print out the status if it's a candidate to be pulled
##

foreach $ifindex(@ifindexes) {
@args = ($oid_ifdescr . $ifindex, $oid_ifoperstatus . $ifindex,
$oid_ifadminstatus . $ifindex, $oid_iflastchange . $ifindex);
#print "@args\n";
my $result = $session->get_request(
-varbindlist => \@args
);

my $desc = $result->{$oid_ifdescr . $ifindex};
my $operstatus = $result->{$oid_ifoperstatus . $ifindex};
my $lastchange = $result->{$oid_iflastchange . $ifindex};
my $adminstatus = $result->{$oid_ifadminstatus . $ifindex};
my $status_time_days = ($uptime - $lastchange) / 8640000;
$tot_ports++;

## are we a pull candidate? if ifoperstatus 2 == down we are
if ($operstatus == '2' && $status_time_days >= $pulldays) {
$pull_ports++;
$rounded_days = sprintf("%.2f", $status_time_days);
if ($adminstatus == '1' ) {
print "$desc has been down for $rounded_days days \n";
}
if ($adminstatus == '2' ) {
print "$desc is ADMINDOWN and has been down for $rounded_days days \n";
}
## die if we see a negative number
if ($rounded_days < 0) {
die "\nUh-oh...Looks like we've actually been up more than 498
days.\nThat rocks, but is unfortunate for our purposes.\nReboot this
gear and try again later.\n";
}
}

}

## done. go home.
print "\nTotal interfaces found: $tot_ports\nPorts Unsed for the last
$pulldays Days: $pull_ports";
$session->close;

exit 0;

##
# subs below here
##

sub get_ifindex {
my $tbl_ifIndex = $session->get_table(
-baseoid => $oid_ifIndex
);

if (!defined($tbl_ifIndex)) {
printf("ERROR: %s.\n", $session->error);
$session->close;
exit 1;
}

foreach $key (keys %$tbl_ifIndex) {
#print "$key => $$tbl_ifIndex{$key}\n";
push (@ifindexes, $$tbl_ifIndex{$key});
}
@ifindexes = sort(@ifindexes);

}

sub get_sysuptime {
my $result = $session->get_request(
-varbindlist => [$sysUpTime]
);
$uptime = $result->{$sysUpTime};

my $result = $session->get_request(
-varbindlist => [$sysName]
);
$sysname = $result->{$sysName};

printf("\nDevice'%s' has been up for %.2f days\n\n",
$sysname, $uptime/8640000
);

}
------[ end paste ]----
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

MatlockK at exempla

Nov 18, 2009, 7:20 AM

Post #6 of 10 (1950 views)
Permalink

Re: snmpwalk for switch port status [In reply to]

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?

Ken Matlock
Network Analyst
Exempla Healthcare
(303) 467-4671
matlockk [at] exempla

-----Original Message-----
From: cisco-nsp-bounces [at] puck
[mailto:cisco-nsp-bounces [at] puck] On Behalf Of Eric Hoelzle
Sent: Wednesday, November 18, 2009 7:26 AM
To: cisco-nsp [at] puck
Subject: Re: [c-nsp] snmpwalk for switch port status

Here's a version in perl that runs on windows or *nix. Net::SNMP
required.

I have an older version using net::snmp::info that reads more cleanly,
but had trouble getting that module to work under ActiveState perl at
my current job.

--
Eric

--------[ begin paste ]-----
use Net::SNMP;

$ARGC = $#ARGV + 1;
if ($ARGC != 2) {
die "\nUsage: deadports.pl hostname num_days\n\n";
}

$pulldays = $ARGV[1];
$hostname = $ARGV[0];
$community = 'CHANGEME';

print "Unused Port report on $hostname for $pulldays days.";

## set up SNMP session
my ($session, $error) = Net::SNMP->session(
-version => 'snmpv2c',
-translate => '0',
-hostname => $hostname,
-community => $community,
-port => 161
);

if (!defined($session)) {
printf("ERROR: %s.\n", $error);
exit 1;
}

## OIDs
my $sysUpTime = '1.3.6.1.2.1.1.3.0';
my $sysName = '1.3.6.1.2.1.1.5.0';
my $oid_ifTable = '1.3.6.1.2.1.2.2';
my $oid_ifIndex = '1.3.6.1.2.1.2.2.1.1';
my $oid_ifdescr = '1.3.6.1.2.1.2.2.1.2.';
my $oid_ifoperstatus = '1.3.6.1.2.1.2.2.1.8.';
my $oid_iflastchange = '1.3.6.1.2.1.2.2.1.9.';
my $oid_ifadminstatus = '1.3.6.1.2.1.2.2.1.7.';

## Counters
$tot_ports = 0;
$pull_ports = 0;

##
# these subs go gather the data basic.
# get_sysuptime has a print at the end as well.
##

&get_sysuptime;

## can't run a report for more days that we have uptime
if (($uptime/8640000) < $pulldays) {
print "Sorry, the Device hasn't been up $pulldays days yet.\n\n";
exit 0;
}

&get_ifindex;

##
# for each interface returned by get_ifindex, gather detail data
# and print out the status if it's a candidate to be pulled
##

foreach $ifindex(@ifindexes) {
@args = ($oid_ifdescr . $ifindex, $oid_ifoperstatus . $ifindex,
$oid_ifadminstatus . $ifindex, $oid_iflastchange . $ifindex);
#print "@args\n";
my $result = $session->get_request(
-varbindlist => \@args
);

my $desc = $result->{$oid_ifdescr . $ifindex};
my $operstatus = $result->{$oid_ifoperstatus . $ifindex};
my $lastchange = $result->{$oid_iflastchange . $ifindex};
my $adminstatus = $result->{$oid_ifadminstatus . $ifindex};
my $status_time_days = ($uptime - $lastchange) / 8640000;
$tot_ports++;

## are we a pull candidate? if ifoperstatus 2 == down we are
if ($operstatus == '2' && $status_time_days >= $pulldays) {
$pull_ports++;
$rounded_days = sprintf("%.2f", $status_time_days);
if ($adminstatus == '1' ) {
print "$desc has been down for $rounded_days days \n";
}
if ($adminstatus == '2' ) {
print "$desc is ADMINDOWN and has been down for $rounded_days days
\n";
}
## die if we see a negative number
if ($rounded_days < 0) {
die "\nUh-oh...Looks like we've actually been up more than 498
days.\nThat rocks, but is unfortunate for our purposes.\nReboot this
gear and try again later.\n";
}
}

}

## done. go home.
print "\nTotal interfaces found: $tot_ports\nPorts Unsed for the last
$pulldays Days: $pull_ports";
$session->close;

exit 0;

##
# subs below here
##

sub get_ifindex {
my $tbl_ifIndex = $session->get_table(
-baseoid => $oid_ifIndex
);

if (!defined($tbl_ifIndex)) {
printf("ERROR: %s.\n", $session->error);
$session->close;
exit 1;
}

foreach $key (keys %$tbl_ifIndex) {
#print "$key => $$tbl_ifIndex{$key}\n";
push (@ifindexes, $$tbl_ifIndex{$key});
}
@ifindexes = sort(@ifindexes);

}

sub get_sysuptime {
my $result = $session->get_request(
-varbindlist => [$sysUpTime]
);
$uptime = $result->{$sysUpTime};

my $result = $session->get_request(
-varbindlist => [$sysName]
);
$sysname = $result->{$sysName};

printf("\nDevice'%s' has been up for %.2f days\n\n",
$sysname, $uptime/8640000
);

}
------[ end paste ]----
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

howie at thingy

Nov 18, 2009, 7:41 AM

Post #7 of 10 (1873 views)
Permalink

Re: snmpwalk for switch port status [In reply to]

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? ;-)
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

MatlockK at exempla

Nov 18, 2009, 7:53 AM

Post #8 of 10 (1883 views)
Permalink

Re: snmpwalk for switch port status [In reply to]

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

-----Original Message-----
From: Howard Jones [mailto:howie [at] thingy]
Sent: Wednesday, November 18, 2009 8:42 AM
To: Matlock, Kenneth L
Cc: Eric Hoelzle; cisco-nsp [at] puck
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? ;-)
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

eric.hoelzle at gmail

Nov 18, 2009, 8:04 AM

Post #9 of 10 (1893 views)
Permalink

Re: snmpwalk for switch port status [In reply to]

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> 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
>
>
>
> -----Original Message-----
> From: Howard Jones [mailto:howie [at] thingy]
> Sent: Wednesday, November 18, 2009 8:42 AM
> To: Matlock, Kenneth L
> Cc: Eric Hoelzle; cisco-nsp [at] puck
> 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? ;-)
>
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

MatlockK at exempla

Nov 18, 2009, 8:18 AM

Post #10 of 10 (1883 views)
Permalink

Re: snmpwalk for switch port status [In reply to]

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

-----Original Message-----
From: Eric Hoelzle [mailto:eric.hoelzle [at] gmail]
Sent: Wednesday, November 18, 2009 9:04 AM
To: Matlock, Kenneth L
Cc: Howard Jones; cisco-nsp [at] puck
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> 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
>
>
>
> -----Original Message-----
> From: Howard Jones [mailto:howie [at] thingy]
> Sent: Wednesday, November 18, 2009 8:42 AM
> To: Matlock, Kenneth L
> Cc: Eric Hoelzle; cisco-nsp [at] puck
> 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? ;-)
>
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads