ifInOctets stopped incrementing on PIX

Unanswered Question
Jul 30th, 2008

...even though the interfaces are still passing traffic. Is there a specific process on the PixOS that's responsible for such MIB counters?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Joe Clarke Wed, 07/30/2008 - 12:18

Typically we would advise a reload. I do not believe there is a way to restart the SNMP engine on a PIX. What version of PIX OS is this?

yjdabear Fri, 08/01/2008 - 13:58

The counters started incrementing again without any intervention. The PIX is running 7.1.2(20). It can't be CSCsm32972 though, since the PIX wasn't being polled every 5 secs. It's indeed the OID values being stuck for hours/days.

Joe Clarke Sun, 08/03/2008 - 23:16

I don't see any other bug which comes close. Could it be that the PIX was being polled by multiple managers during this time? Any aggressive polling could trigger CSCsm32972.

yjdabear Mon, 08/04/2008 - 06:58

That's an interesting perspective. I also find CSCsm33227 that says "In 7.0(5), 7.1(2), 7.2(1), 8.0(1) and later software, the information available through SNMP is refreshed approximately every 5 seconds. Therefore, it is advised to wait for at least 5 seconds between consecutive polls." I read CSCsm32972 as just another way of describing this inherent limitation, in other words it's entirely due to the SNMP poller's behavior. But your interpretation seems to suggest something wrong on the PIX OS side, that the MIB counters are indeed stuck, as I've seen on our PIXes, triggered by overly frequent polling. For completeness, I should mention that we have one script that's been polling every 10 secs for months if not years, and an assortment of other tools that poll mostly in 5-min intervals. The ifInOctets/ifOutOctets on the management interface (light traffic) on these PIXes never stopped incrementing, while all the other active interfaces that are actually used for client traffic did. Can the problem still be attributed to the CSCsm32972 bug?

Joe Clarke Mon, 08/04/2008 - 07:15

The fix involved changing the way a cache was updated. The original algorithm fell apart when the counters were polled aggressively. If multiple pollers are hitting this PIX, it is entirely possible that some combination "locked" the counters for an extended period of time.

That said, this may be a new bug altogether. Without upgrading, you could try backing off some of the polling to see if the problem occurs again.

Actions

This Discussion