PIX 525 - Incrementing No Buffer and Overrun

[molinek]

Hi All, we have a PIX 525, with (2) fiber 1GB interfaces, auto neg, connected to a 3750G switch, auto neg. We are incrementing interface counters on the "No Buffer" and "Overrun". The output interpretor tool suggests a few things, but I wanted to pass it out to the community to see if anyone else has run into this issue. I am planing upgrading the PIX OS from 6.3.3 to 7.0.1, then up to 8.0.4 after it runs a few weeks.

interface gb-ethernet0 "Hostdmz" is up, line protocol is up
  Hardware is i82543 rev02 gigabit ethernet, address is 000e.0c2b.d2b3
  IP address 10.X.X.X, subnet mask 255.255.254.0
  MTU 1500 bytes, BW 1 Gbit full duplex
2166496744 packets input, 75837026583963 bytes, 76922875 no buffer
Received 938241735 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 152071 frame, 278320 overrun, 0 ignored, 0 abort
4221379184 packets output, 34008554011956 bytes, 0 underruns
input queue (curr/max blocks): hardware (0/25) software (0/0)
output queue (curr/max blocks): hardware (0/256) software (0/0)

The interface runs over 5,000 PPS with an avg. packet size of 183bytes RX and 591bytes TX

Current traffic is 7.46MB RX 27MB TX

No client complaints to speak of.

Thoughts?

[Panos Kampanakis · Accepted solution]

Hi ,

I would suggest tracking link use during the counters increase. With 7Mbps it doesn't make much sense for them to increase. There were some defects in older releases where counters increased without high traffic and they were cosmetic.

I hope it helps.

PK

[molinek]

It did state in the output interpreteur to ignore them if there are 0 input and 0 CRC and there is. I will post this and see what you think.

In 4 hours we've had 50 overruns and 19614 No buffer counters

Here is the output from the Cisco Output Interpreter:

SHOW INTERFACES (ASA/PIX) NOTIFICATIONS (if any)

Network Cards:
  1 - INTEL i82543 (1GE-66, Ports - One MM SC GB Ethernet)

Interface Hostdmz - gb-ethernet0 (up/up)
  WARNING: There have been 152071 'frame errors' reported.
  This indicates the number of packets received having a CRC error and a non-integer
  number of octets. On a LAN, this is usually the result of collisions or a malfunctioning
  Ethernet device.
  TRY THIS: Monitor the level of frame errors over time. If they are increasing,
  try swapping interfaces and/or ports to identify the problem.
  REFERENCE: For more information, see Troubleshooting Ethernet.
 
  WARNING: There have been 278370 'overruns' reported.
  This shows the number of times that the receiver hardware was incapable of handling
  received data to a hardware buffer because the input rate exceeded the receiver's
  capability to handle the data. If the overruns are equal to input errors and
  there are no CRC errors then at one point the ASA/PIX received packets faster
  than it can handle. This is not a cause of concern and can be ignored.
  TRY THIS: Verify that speed and duplex settings are hard-coded on the ASA/PIX
  and on the other directly connected devices. Use show blocks ASA/PIX command.
  A zero in the LOW column indicates a previous event where memory exhausted. A
  zero in the CNT column means memory is exhausted now. If the memory is continuously
  exhausted and traffic is not moving, then consider upgrading the interface to
  Gigabit or the ASA/PIX to a higher model. If this is DMZ interface, you can use
  other unused interfaces by splitting your current DMZ into 2 networks. If very
  large object-groups or large access-lists are used on ASA/PIX then use object-group-search
  keyword in the access-list ASA/PIX command to specify that access-list search
  is performed on object groups that are contained in access-list instead of searching
  the entire expanded access-list.
 
  WARNING: 0.0328274% (more than 0.1%) of received packets have been discarded due
  to lack of buffer space in the main system (no buffers).
  TRY THIS: If software 6.x and above is being used, monitor the CPU usage with
  the 'show cpu usage' command, and buffer usage with the 'show blocks' command.
 
  WARNING: More than 20% of packets received on this interface have been broadcasts.
  TRY THIS: Ensure that this level of broadcasts is required on this interface.
 
REFERENCE: For more information, see Troubleshooting Ethernet.

NOTE: Output Interpreter will perform analysis of ASA/PIX interface statistics
for all interfaces that are not administratively shutdown. Ensure that interface
statistics reflect the current state of the interfaces (<24hrs) by periodically clearing the
counters with the 'clear interface' command.

[Panos Kampanakis · Accepted solution]

Yes, it could be one of the old cosmetic bugs.

You said you would upgrade, please take the PIX to the latest 7.x version it can support and check if these counters still increment. With such low traffic I doubt they will.

I hope it makes sense.

PK