Discussion:
[opennms-discuss] High Threshold for ifInDiscards + ifOutDiscards
Jim Jones
2012-03-28 13:57:54 UTC
Permalink
Hello,

Since updating to 1.10 I've been getting quite a few of the below messages, but as I understand it these counters show the equivalent of drops in the show interface command. When I do a show interface, there's nothing there (see below). Can anybody explain why I'm getting these or am I seeing a bug?

CHAS-2951#show int g0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is PQ3_TSEC, address is c89c.1dc3.0721 (bia c89c.1dc3.0721)
Internet address is 10.255.255.1/30
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1Gbps, media type is RJ45
output flow-control is unsupported, input flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 7301000 bits/sec, 1060 packets/sec
5 minute output rate 3712000 bits/sec, 899 packets/sec
9913974846 packets input, 10244003264600 bytes, 0 no buffer
Received 318709 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 318693 multicast, 0 pause input
7737949013 packets output, 3111655156231 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out

-----Original Message-----
From: root [mailto:***@nms.wvhdf.com]
Sent: Wednesday, March 28, 2012 9:47 AM
To: Jim Jones
Subject: Notice #166238: High Threshold for ifInDiscards + ifOutDiscards on node chas-2951.wvhdf.com.

A Threshold has been exceeded on node: chas-2951.wvhdf.com, interface:10.255.255.1. The parameter ifInDiscards + ifOutDiscards reached a value of 48.3 while the threshold is 1.0. This alert will be rearmed when ifInDiscards + ifOutDiscards reaches 0.0.


Thanks,
Jim Jones
Sr. Network Administrator
West Virginia Housing Development Fund


DISCLAIMER: This email is for the use of the intended recipient(s) only. If you have received this email in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this email without the author's prior permission . This email may contain information that is privileged,confidential, or protected by law and may be subject to the attorney-client privilege. If you are not the intended recipient you are hereby notified that any dissemination,copying or distribution of this email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. If you are the intended recipient and you do not wish to receive similar electronic messages from us in the future then please respond to the sender to this effect.

Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission.
Christian
2012-03-29 10:10:10 UTC
Permalink
Hi Jim,

I posted the following one or two weeks ago, but got no reply. So I
thought I might investigate this again after upgrading to 1.10 But looks
like there is something wierd going on with these
Threholds/Datacollections ??
For me this looks like a bug, but I cant really track this down on my own.
Maybe one of the developers can give us a hint ?


Hi all,

we are getting events on one of the default thresholds, where the values
go in the millions range but if I do an snmpwalk on the OIDs collected
there's always a different value. We run OpenNMS 1.8.15

High threshold exceeded for SNMP datasource ifInDiscards + ifOutDiscards on interface x.x.x.x., parms: ifLabel="Gi1_0_24" ifIndex="10124" label="Gi1/0/24" ds="ifInDiscards + ifOutDiscards" value="14221728.09" instance="10124" trigger="2" threshold="1.0" rearm="0.0"


After a couple of minutes the rearm event appears, but the counter for
ifOutDiscards for that interface ist still 5414. I thought if the rearm
evnts says the value is 0 then the counter should be 0 as well, isn't it
? These errors showed up multiple times today and got cleared, the
counter value always stays the same (see below)


On the switch Cisco3750 OID 1.3.6.1.4.1.9.1.516:

sh interfaces counters errors module 1
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
Gi1/0/24 0 0 0 0 0 5414

snmpwalk shows:

iso.3.6.1.2.1.2.2.1.19.10124 = Counter32: 5414
iso.3.6.1.2.1.2.2.1.13.10124 = Counter32: 0

The resource graphs also show max values in millions, but I don't
understand where these values come from, does anyone have an idea ?

Regards,
Christian
Post by Jim Jones
Hello,
Since updating to 1.10 I've been getting quite a few of the below messages, but as I understand it these counters show the equivalent of drops in the show interface command. When I do a show interface, there's nothing there (see below). Can anybody explain why I'm getting these or am I seeing a bug?
CHAS-2951#show int g0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is PQ3_TSEC, address is c89c.1dc3.0721 (bia c89c.1dc3.0721)
Internet address is 10.255.255.1/30
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1Gbps, media type is RJ45
output flow-control is unsupported, input flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 7301000 bits/sec, 1060 packets/sec
5 minute output rate 3712000 bits/sec, 899 packets/sec
9913974846 packets input, 10244003264600 bytes, 0 no buffer
Received 318709 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 318693 multicast, 0 pause input
7737949013 packets output, 3111655156231 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
-----Original Message-----
Sent: Wednesday, March 28, 2012 9:47 AM
To: Jim Jones
Subject: Notice #166238: High Threshold for ifInDiscards + ifOutDiscards on node chas-2951.wvhdf.com.
A Threshold has been exceeded on node: chas-2951.wvhdf.com, interface:10.255.255.1. The parameter ifInDiscards + ifOutDiscards reached a value of 48.3 while the threshold is 1.0. This alert will be rearmed when ifInDiscards + ifOutDiscards reaches 0.0.
Thanks,
Jim Jones
Sr. Network Administrator
West Virginia Housing Development Fund
DISCLAIMER: This email is for the use of the intended recipient(s) only. If you have received this email in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this email without the author's prior permission . This email may contain information that is privileged,confidential, or protected by law and may be subject to the attorney-client privilege. If you are not the intended recipient you are hereby notified that any dissemination,copying or distribution of this email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. If you are the intended recipient and you do not wish to receive similar electronic messages from us in the future then please respond to the sender to this effect.
Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission.
------------------------------------------------------------------------------
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
http://www.opennms.org/index.php/Mailing_List_FAQ
opennms-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/opennms-discuss
John Blake
2012-03-30 01:24:48 UTC
Permalink
Wouldnt it be better to use 64 bit counters versus 32 bit seeing as how
you're trying to look at a Gigbit interface?





From: Christian <***@cs-it-service.net>
To: General OpenNMS Discussion
<opennms-***@lists.sourceforge.net>,
Date: 03/29/2012 06:14 AM
Subject: Re: [opennms-discuss] High Threshold for ifInDiscards +
ifOutDiscards



Hi Jim,

I posted the following one or two weeks ago, but got no reply. So I
thought I might investigate this again after upgrading to 1.10 But looks
like there is something wierd going on with these
Threholds/Datacollections ??
For me this looks like a bug, but I cant really track this down on my own.
Maybe one of the developers can give us a hint ?


Hi all,

we are getting events on one of the default thresholds, where the values
go in the millions range but if I do an snmpwalk on the OIDs collected
there's always a different value. We run OpenNMS 1.8.15

High threshold exceeded for SNMP datasource ifInDiscards + ifOutDiscards on
interface x.x.x.x., parms: ifLabel="Gi1_0_24" ifIndex="10124"
label="Gi1/0/24" ds="ifInDiscards + ifOutDiscards" value="14221728.09"
instance="10124" trigger="2" threshold="1.0" rearm="0.0"


After a couple of minutes the rearm event appears, but the counter for
ifOutDiscards for that interface ist still 5414. I thought if the rearm
evnts says the value is 0 then the counter should be 0 as well, isn't it
? These errors showed up multiple times today and got cleared, the
counter value always stays the same (see below)


On the switch Cisco3750 OID 1.3.6.1.4.1.9.1.516:

sh interfaces counters errors module 1
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
Gi1/0/24 0 0 0 0 0 5414

snmpwalk shows:

iso.3.6.1.2.1.2.2.1.19.10124 = Counter32: 5414
iso.3.6.1.2.1.2.2.1.13.10124 = Counter32: 0

The resource graphs also show max values in millions, but I don't
understand where these values come from, does anyone have an idea ?

Regards,
Christian
Post by Jim Jones
Hello,
Since updating to 1.10 I've been getting quite a few of the below
messages, but as I understand it these counters show the equivalent of
drops in the show interface command. When I do a show interface, there's
nothing there (see below). Can anybody explain why I'm getting these or am
I seeing a bug?
Post by Jim Jones
CHAS-2951#show int g0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is PQ3_TSEC, address is c89c.1dc3.0721 (bia c89c.1dc3.0721)
Internet address is 10.255.255.1/30
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1Gbps, media type is RJ45
output flow-control is unsupported, input flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 7301000 bits/sec, 1060 packets/sec
5 minute output rate 3712000 bits/sec, 899 packets/sec
9913974846 packets input, 10244003264600 bytes, 0 no buffer
Received 318709 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 318693 multicast, 0 pause input
7737949013 packets output, 3111655156231 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
-----Original Message-----
Sent: Wednesday, March 28, 2012 9:47 AM
To: Jim Jones
Subject: Notice #166238: High Threshold for ifInDiscards + ifOutDiscards
on node chas-2951.wvhdf.com.
Post by Jim Jones
A Threshold has been exceeded on node: chas-2951.wvhdf.com,
interface:10.255.255.1. The parameter ifInDiscards + ifOutDiscards reached
a value of 48.3 while the threshold is 1.0. This alert will be rearmed when
ifInDiscards + ifOutDiscards reaches 0.0.
Post by Jim Jones
Thanks,
Jim Jones
Sr. Network Administrator
West Virginia Housing Development Fund
DISCLAIMER: This email is for the use of the intended recipient(s) only.
If you have received this email in error, please notify the sender
immediately and then delete it. If you are not the intended recipient, you
must not keep, use, disclose, copy or distribute this email without the
author's prior permission . This email may contain information that is
privileged,confidential, or protected by law and may be subject to the
attorney-client privilege. If you are not the intended recipient you are
hereby notified that any dissemination,copying or distribution of this
email or its contents is strictly prohibited. If you have received this
message in error, please notify us immediately by replying to the message
and deleting it from your computer. If you are the intended recipient and
you do not wish to receive similar electronic messages from us in the
future then please respond to the sender to this effect.
Post by Jim Jones
Internet communications are not assured to be secure or clear of
inaccuracies as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. Therefore, we do
not accept responsibility for any errors or omissions that are present in
this email, or any attachment, that have arisen as a result of e-mail
transmission.
------------------------------------------------------------------------------
Post by Jim Jones
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
http://www.opennms.org/index.php/Mailing_List_FAQ
opennms-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/opennms-discuss
------------------------------------------------------------------------------

This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
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
Christian
2012-04-03 08:55:43 UTC
Permalink
Hi John,

thanks for your reply, but I am "only" the Linux guy administrating the
ONMS system and try to investigate the problems my colleagues throw
over. I am not really into the Cisco stuff, but my networking colleagues
seem not to be aware of this problem.
So with your hint I googled and found:

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_q_and_a_item09186a00800b69ac.shtml

So this seems to be the problem and I need to use the 64 bit counters on
that device. I was thinking ONMS maybe is smart enough to use the
correct counters on "standard" Gigabit devices.
So that was a good lesson for me...

Christian
Post by John Blake
Wouldnt it be better to use 64 bit counters versus 32 bit seeing as how
you're trying to look at a Gigbit interface?
To: General OpenNMS Discussion
Date: 03/29/2012 06:14 AM
Subject: Re: [opennms-discuss] High Threshold for ifInDiscards +
ifOutDiscards
Hi Jim,
I posted the following one or two weeks ago, but got no reply. So I
thought I might investigate this again after upgrading to 1.10 But looks
like there is something wierd going on with these
Threholds/Datacollections ??
For me this looks like a bug, but I cant really track this down on my own.
Maybe one of the developers can give us a hint ?
Hi all,
we are getting events on one of the default thresholds, where the values
go in the millions range but if I do an snmpwalk on the OIDs collected
there's always a different value. We run OpenNMS 1.8.15
High threshold exceeded for SNMP datasource ifInDiscards + ifOutDiscards on
interface x.x.x.x., parms: ifLabel="Gi1_0_24" ifIndex="10124"
label="Gi1/0/24" ds="ifInDiscards + ifOutDiscards" value="14221728.09"
instance="10124" trigger="2" threshold="1.0" rearm="0.0"
After a couple of minutes the rearm event appears, but the counter for
ifOutDiscards for that interface ist still 5414. I thought if the rearm
evnts says the value is 0 then the counter should be 0 as well, isn't it
? These errors showed up multiple times today and got cleared, the
counter value always stays the same (see below)
sh interfaces counters errors module 1
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
Gi1/0/24 0 0 0 0 0 5414
iso.3.6.1.2.1.2.2.1.19.10124 = Counter32: 5414
iso.3.6.1.2.1.2.2.1.13.10124 = Counter32: 0
The resource graphs also show max values in millions, but I don't
understand where these values come from, does anyone have an idea ?
Regards,
Christian
Post by Jim Jones
Hello,
Since updating to 1.10 I've been getting quite a few of the below
messages, but as I understand it these counters show the equivalent of
drops in the show interface command. When I do a show interface, there's
nothing there (see below). Can anybody explain why I'm getting these or am
I seeing a bug?
Post by Jim Jones
CHAS-2951#show int g0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is PQ3_TSEC, address is c89c.1dc3.0721 (bia c89c.1dc3.0721)
Internet address is 10.255.255.1/30
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1Gbps, media type is RJ45
output flow-control is unsupported, input flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 7301000 bits/sec, 1060 packets/sec
5 minute output rate 3712000 bits/sec, 899 packets/sec
9913974846 packets input, 10244003264600 bytes, 0 no buffer
Received 318709 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 318693 multicast, 0 pause input
7737949013 packets output, 3111655156231 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
-----Original Message-----
Sent: Wednesday, March 28, 2012 9:47 AM
To: Jim Jones
Subject: Notice #166238: High Threshold for ifInDiscards + ifOutDiscards
on node chas-2951.wvhdf.com.
Post by Jim Jones
A Threshold has been exceeded on node: chas-2951.wvhdf.com,
interface:10.255.255.1. The parameter ifInDiscards + ifOutDiscards reached
a value of 48.3 while the threshold is 1.0. This alert will be rearmed when
ifInDiscards + ifOutDiscards reaches 0.0.
Post by Jim Jones
Thanks,
Jim Jones
Sr. Network Administrator
West Virginia Housing Development Fund
DISCLAIMER: This email is for the use of the intended recipient(s) only.
If you have received this email in error, please notify the sender
immediately and then delete it. If you are not the intended recipient, you
must not keep, use, disclose, copy or distribute this email without the
author's prior permission . This email may contain information that is
privileged,confidential, or protected by law and may be subject to the
attorney-client privilege. If you are not the intended recipient you are
hereby notified that any dissemination,copying or distribution of this
email or its contents is strictly prohibited. If you have received this
message in error, please notify us immediately by replying to the message
and deleting it from your computer. If you are the intended recipient and
you do not wish to receive similar electronic messages from us in the
future then please respond to the sender to this effect.
Post by Jim Jones
Internet communications are not assured to be secure or clear of
inaccuracies as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. Therefore, we do
not accept responsibility for any errors or omissions that are present in
this email, or any attachment, that have arisen as a result of e-mail
transmission.
------------------------------------------------------------------------------
Post by Jim Jones
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
http://www.opennms.org/index.php/Mailing_List_FAQ
opennms-discuss mailing list
To *unsubscribe* or change your subscription options, see the bottom of
https://lists.sourceforge.net/lists/listinfo/opennms-discuss
------------------------------------------------------------------------------
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
http://www.opennms.org/index.php/Mailing_List_FAQ
opennms-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/opennms-discuss
------------------------------------------------------------------------------
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
http://www.opennms.org/index.php/Mailing_List_FAQ
opennms-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/opennms-discuss
Ken Eshelby
2012-04-03 18:32:28 UTC
Permalink
I don't think there are 64 bit counters for discards. IIRC, only octets
and packet counts in that ifindex kind of area of the MIB.

I see this issue frequently enough that I have the default discard
threshold notification disabled.
Christian
2012-04-04 15:24:47 UTC
Permalink
alright, I didn't have the time to study this article in depth, but it
seems that these ifDiscard counters are only 32 bit don't realy work for
some people.
So can anyone say if this is a bug related to Cisco devices or OpenNMS
or a general SNMP problem ?
Post by Ken Eshelby
I don't think there are 64 bit counters for discards. IIRC, only
octets and packet counts in that ifindex kind of area of the MIB.
I see this issue frequently enough that I have the default discard
threshold notification disabled.
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
http://www.opennms.org/index.php/Mailing_List_FAQ
opennms-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/opennms-discuss
Christian Seifert
2012-04-04 15:22:26 UTC
Permalink
alright, I didn't have the time to study this article in depth, but it
seems that these ifDiscard counters are only 32 bit don't realy work for
some people.
So can anyone say if this is a bug related to Cisco devices or OpenNMS
or a general SNMP problem.
Post by Ken Eshelby
I don't think there are 64 bit counters for discards. IIRC, only
octets and packet counts in that ifindex kind of area of the MIB.
I see this issue frequently enough that I have the default discard
threshold notification disabled.
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
http://www.opennms.org/index.php/Mailing_List_FAQ
opennms-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/opennms-discuss
John Blake
2012-04-05 14:37:21 UTC
Permalink
I thought it depended on if the device supports the mib and if the device
has that type of interface (1 gig).




From: Christian Seifert <***@cs-it-service.net>
To: General OpenNMS Discussion
<opennms-***@lists.sourceforge.net>,
Date: 04/05/2012 09:07 AM
Subject: Re: [opennms-discuss] High Threshold for ifInDiscards +
ifOutDiscards




alright, I didn't have the time to study this article in depth, but it
seems that these ifDiscard counters are only 32 bit don't realy work for
some people.
So can anyone say if this is a bug related to Cisco devices or OpenNMS or a
general SNMP problem.





On 4/3/12 8:32 PM, Ken Eshelby wrote:
I don't think there are 64 bit counters for discards. IIRC, only
octets and packet counts in that ifindex kind of area of the MIB.

I see this issue frequently enough that I have the default discard
threshold notification disabled.


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

Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev


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

Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
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
David Hustace
2012-04-07 15:22:04 UTC
Permalink
Post by John Blake
I thought it depended on if the device supports the mib and if the device
has that type of interface (1 gig).
I think that if one is having so many discards that they a need 64-bit counter, that is problem of a much higher severity. That is either a hardware issue, a configuration issue, or a network planning issue. (I'm not a network engineer but I play one on TV).

The RFC for MIB2 interfaces determines where 64-bit counters live. The device decided which interfaces get provided 64-bit counters. For Cisco, at least it used to be, it provided 64-bit counters only for interfaces of speeds > 20mbs.


David

David Hustace
The OpenNMS Group, Inc.

+1 919 533 0160 x7734
'\ . . |>
\ . ' . |
O>> . 'o |
\ . |
/\ . |
/ / .' |
^^^^^^^`^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Les Mikesell
2012-04-07 16:06:55 UTC
Permalink
Post by John Blake
I thought it depended on if the device supports the mib and if the device
has that type of interface (1 gig).
I think that if one is having so many discards that they a need 64-bit
counter, that is problem of a much higher severity.  That is either a
hardware issue, a configuration issue, or a network planning issue.  (I'm
not a network engineer but I play one on TV).
The RFC for MIB2 interfaces determines where 64-bit counters live.  The
device decided which interfaces get provided 64-bit counters.  For Cisco, at
least it used to be, it provided 64-bit counters only for interfaces of
speeds > 20mbs.
But his CLI listing showed 0 and that the counters had not been
cleared. It's pretty unlikely that a 32-bit counter just wrapped at
that moment. The only place I ever see a lot of discards is on tunnel
interfaces where the MTU is reduced (and if the DF bit is set on a
packet, that's the right thing to do).
--
Les Mikesell
***@gmail.com
John Blake
2012-04-09 12:48:57 UTC
Permalink
Does the 64 bit counter for the interface also show the errors?




From: Les Mikesell <***@gmail.com>
To: General OpenNMS Discussion
<opennms-***@lists.sourceforge.net>,
Date: 04/07/2012 12:10 PM
Subject: Re: [opennms-discuss] High Threshold for ifInDiscards +
ifOutDiscards
Post by John Blake
I thought it depended on if the device supports the mib and if the device
has that type of interface (1 gig).
I think that if one is having so many discards that they a need 64-bit
counter, that is problem of a much higher severity.  That is either a
hardware issue, a configuration issue, or a network planning issue.  (I'm
not a network engineer but I play one on TV).
The RFC for MIB2 interfaces determines where 64-bit counters live.  The
device decided which interfaces get provided 64-bit counters.  For Cisco, at
least it used to be, it provided 64-bit counters only for interfaces of
speeds > 20mbs.
But his CLI listing showed 0 and that the counters had not been
cleared. It's pretty unlikely that a 32-bit counter just wrapped at
that moment. The only place I ever see a lot of discards is on tunnel
interfaces where the MTU is reduced (and if the DF bit is set on a
packet, that's the right thing to do).

--
Les Mikesell
***@gmail.com

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

For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
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

Loading...