ERR_DISABLE on a 3750

[nicolasvibert]

Hi,

Our client has had issues with a server connected to a stack of 3750 switches. A couple of times, hundreds of collisions suddenly occurred on an interface. Collisions were expected (the server can only work in 10 HD) but the main issue was that the 3750 performances became really poor (switch hardly manageable, really slow, difficulties to connect to servers connected to that switch).

When the client removed the switch from that stack and installed it somewhere else, it started working as well as before.

So my questions were:

- should the switch 3750 not put the port in err_disable state? Is this mechanism configured by default on these switches?

- Why would this port provoke a bad behaviour of the switch itself?

The 3750 has a 12.2(25)SEB version.

Thank you in advance!

Nicolas

[amit-singh]

Hi,

For your first questions, there is not any cause in errordisable feature to put the interface in err_disable state if there are collisions on the port.

These are the once detected by the switch:

errdisable detect cause {all | arp-inspection | dhcp-rate-limit | dtp-flap | gbic-invalid | l2ptguard | link-flap | loopback | pagp-flap}

For your second question , I would say there could be some unusual traffic like huge broadcast that the switch had to process and it took the CPU on load. I would suggest to put a sniffer on teh switch and see the kind of traffic forwarded on the switch.

HTH,

-amit singh

[nicolasvibert]

Thank you for your reply,

We indeed put a sniffer on the switch and we discovered LOOP packets (CTP) sent every 10 seconds, STP packets (sent every 2 secondes, I guess it's the regular BPDUs), IPX SA and IPX packets.

The difficulty is also that we can not reproduce the problem and therefore it is hard to see what is going on.

I also noticed on the "show controllers" many "Invalid packets, too small" on that interface.

Any ideas about what they would be?

[amit-singh]

Hi,

"Invalid packets, too small" are the number of frames received that are smaller than 64 bytes (including the FCS bits and excluding the frame header) and that have either an FCS error or an alignment error.

These are again related to speed and duplex i.e the physical layer issue.

HTH,

-amit singh

[nicolasvibert]

Ok, thank you for this answer.

But as explained earlier, these invalids packets must then come from the half-duplex setting of the port.

What about the other packets (mentionned earlier) seen in the sniffer outputs ?

Thanks in advance,

Regards,

Nicolas

[amit-singh]

Nicolas,

Rest of the Packets were the normal that you see on any switch. STP BPDU sent every 2 sec i.e normal hello time. IPX and SPX packet I dot aware of.

So in all you didnt see any unsual traffic at all... No broadcast nothing... Did you sniff the whole switch or just few ports.

I would say that it all will be troubleshooted when that problem happens agaain.. Can we reproduce the problem some how...

regards,

-amit singh

[nicolasvibert]

Amit,

As I explained earlier, we can not reproduce the problem.

Can you advise us a few traces to get if it happens again ?

What surprises me is that the client has a SNMP server that polls regularly the switch and checks the memory, the CPU, etc... And when the problem happened, it seems that they were quite low and nothing special appeared in those SNMP outputs.

Regards,

Nicolas

[glen.grant]

Is there any info in the logg that indicates a problem ? Also make sure clients are setup with portfast on . If you get a get port that starts flapping and spanning tree is continually running this could cause some of the problems you are seeing .

[nicolasvibert]

Hi Glen,

Unfortunately, there was nothing in the loggs that indicated whatsoever.

And portfast is indeed set up on the ports where the servers are connected.

Regards,

Nicolas