Hey Adam,
What OID is used to generate stat about non-unicast packet, does these below correct?
1.3.6.1.2.1.31.1.1.1.2 1.3.6.1.2.1.31.1.1.1.3 1.3.6.1.2.1.31.1.1.1.4 1.3.6.1.2.1.31.1.1.1.5
I'm trying catch some error in stat which cause to show as 500M non-unicast packets, which is damn huge.
Yeah, these are correct. Just found IOS bug, these smartass Cisco guys decide to start count in reverse order, starting from 4294967296 and decreasing till zero. No wonder stats are looks like shit. I'll report them, for fix, this only affect specific IOS releases.
On 13.10.2011 0:57, Nikolay Shopik wrote:
Hey Adam,
What OID is used to generate stat about non-unicast packet, does these below correct?
1.3.6.1.2.1.31.1.1.1.2 1.3.6.1.2.1.31.1.1.1.3 1.3.6.1.2.1.31.1.1.1.4 1.3.6.1.2.1.31.1.1.1.5
I'm trying catch some error in stat which cause to show as 500M non-unicast packets, which is damn huge. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Haha, awesome bug!
Almost as fun as the EIGRP bug I have which randomly stops announcing routes :D
adam.
On Thu, 13 Oct 2011 01:05:20 +0400, Nikolay Shopik shopik@inblock.ru wrote:
Yeah, these are correct. Just found IOS bug, these smartass Cisco guys decide to start count in reverse order, starting from 4294967296 and decreasing till zero. No wonder stats are looks like shit. I'll report them, for fix, this only affect specific IOS releases.
On 13.10.2011 0:57, Nikolay Shopik wrote:
Hey Adam,
What OID is used to generate stat about non-unicast packet, does these below correct?
1.3.6.1.2.1.31.1.1.1.2 1.3.6.1.2.1.31.1.1.1.3 1.3.6.1.2.1.31.1.1.1.4 1.3.6.1.2.1.31.1.1.1.5
I'm trying catch some error in stat which cause to show as 500M non-unicast packets, which is damn huge. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
I've also notice some of Wifi interfaces traffic values up to 220M. I belive OID(outbound) is used for that .1.3.6.1.2.1.2.2.1.16. And inbound(towards interface) traffic is looks normal. But counters here doesn't looks like broken like previous. Any clue about that, maybe it's normal for wireless interfaces to have such peaks? btw this is 802.11b/g so no more 54Mbit.
On 13/10/11 01:05, Nikolay Shopik wrote:
Yeah, these are correct. Just found IOS bug, these smartass Cisco guys decide to start count in reverse order, starting from 4294967296 and decreasing till zero. No wonder stats are looks like shit. I'll report them, for fix, this only affect specific IOS releases.
On 13.10.2011 0:57, Nikolay Shopik wrote:
Hey Adam,
What OID is used to generate stat about non-unicast packet, does these below correct?
1.3.6.1.2.1.31.1.1.1.2 1.3.6.1.2.1.31.1.1.1.3 1.3.6.1.2.1.31.1.1.1.4 1.3.6.1.2.1.31.1.1.1.5
I'm trying catch some error in stat which cause to show as 500M non-unicast packets, which is damn huge. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
I'm still trying tracking down this issue, and so have question. Does observium use 64bit counter always?
On 13/10/11 11:17, Nikolay Shopik wrote:
I've also notice some of Wifi interfaces traffic values up to 220M. I belive OID(outbound) is used for that .1.3.6.1.2.1.2.2.1.16. And inbound(towards interface) traffic is looks normal. But counters here doesn't looks like broken like previous. Any clue about that, maybe it's normal for wireless interfaces to have such peaks? btw this is 802.11b/g so no more 54Mbit.
We use 64-bit if 64-bit is numeric, else we use 32bit.
what do an if(numeric($64bitvalue)) { $value = $64bitvalue }
Issues will occur if the 64bit value spontaneously disappears and it reverts to the 32bit value.
adam.
On Tue, 01 Nov 2011 18:41:41 +0400, Nikolay Shopik shopik@inblock.ru wrote:
I'm still trying tracking down this issue, and so have question. Does observium use 64bit counter always?
On 13/10/11 11:17, Nikolay Shopik wrote:
I've also notice some of Wifi interfaces traffic values up to 220M. I belive OID(outbound) is used for that .1.3.6.1.2.1.2.2.1.16. And inbound(towards interface) traffic is looks normal. But counters here doesn't looks like broken like previous. Any clue about that, maybe it's normal for wireless interfaces to have such
peaks?
btw this is 802.11b/g so no more 54Mbit.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Just FYI this is CSCtj72729 bug and affect different platforms on gigabit interfaces.
On 13/10/11 01:05, Nikolay Shopik wrote:
Yeah, these are correct. Just found IOS bug, these smartass Cisco guys decide to start count in reverse order, starting from 4294967296 and decreasing till zero. No wonder stats are looks like shit. I'll report them, for fix, this only affect specific IOS releases.
participants (2)
-
Adam Armstrong
-
Nikolay Shopik