Lots of collisions on interface vlan 1

I have a switch that has over 21 million collisions within the last week on the vlan 1 interface. Users on this switch have been experiencing slowness for a while, and we just started monitoring the switches statistics recently. None of the physical interfaces have any collisions at all, for the last week. The switch is connected to another switch via a dot1q trunk. The neighbor switch has not collisions, or other errors, on vlan 1.

I suspect that the high number of collisions is creating some latency on the switch that is causing the slowness. Out of all 20 switches that we have, there are no VLAN interfaces with any errors, like this.

Here is the information from the offending switch:

#show interface vlan 1 VLAN1 is up, line protocol is up Hardware is CPU Interface, address is 0001.42b4.a640 (bia

0001.42b4.a640) Internet address is MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set 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 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 1000 bits/sec, 3 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 2346 packets input, 173859 bytes, 0 no buffer Received 2021 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 input packets with dribble condition detected 262 packets output, 21449 bytes, 0 underruns 0 output errors, 20763204 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out

#show version Cisco Internetwork Operating System Software IOS (tm) C3500XL Software (C3500XL-C3H2S-M), Version 12.0(5.1)XP, MAINTENANCE INTERIM SOFTWARE Copyright (c) 1986-1999 by cisco Systems, Inc. Compiled Fri 10-Dec-99 11:16 by cchang Image text-base: 0x00003000, data-base: 0x002D84CC

ROM: Bootstrap program is C3500XL boot loader

DOM_Switch uptime is 1 hour, 57 minutes System returned to ROM by reload System image file is "flash:c3500XL-c3h2s-mz-120.5.1-XP.bin"

cisco WS-C3548-XL (PowerPC403) processor (revision 0x01) with

16384K/1024K bytes of memory. Processor board ID 0x17, with hardware revision 0x00 Last reset from warm-reset

Processor is running Enterprise Edition Software Cluster command switch capable Cluster member switch capable

48 FastEthernet/IEEE 802.3 interface(s) 2 Gigabit Ethernet/IEEE 802.3 interface(s)

32K bytes of flash-simulated non-volatile configuration memory. Base ethernet MAC Address: 00:01:42:B4:A6:40 Motherboard assembly number: 73-3903-04 Power supply part number: 34-0971-01 Motherboard serial number: FAA04089M5Z Power supply serial number: PAC040802HZ Model revision number: A0 Motherboard revision number: B0 Model number: WS-C3548-XL-EN System serial number: FAA0411J015 Configuration register is 0xF

Reply to
Loading thread data ...

Basically virtual interfaces can't have collisions. The report is erroneous. Most likely a cosmetic bug.

These numbers are just impossible. 262 packets output cannot generate 20763204 collisions even on ethernet since each packet is limited to 16 collisions before it is discarded. You are not though on Ethernet with this interface.

The VLAN interface is only use for management, I am pretty sure, on that switch, it is not a router.

What you do want to worry about are:-

drops, ignores, throttles, no buffers, on the physical interfaces. Any kind or ERROR on the physical interface - e.g. CRC, align, LATE COLLISIONs are bad.

Collisions are OK, Well not 10,000 per packet but a lot are OK.

YOu probably have to look elsewhere for your problems.

Post a sh int (yes all of it).

Reply to

Hi Dustin,

These characteristics smell just like a DUPLEX mismatch between the 2 Switches. This could be a result of llnking a 10Mb interface device to a 100Mb interface device and one end does NOT do Autoconfiguration (speed/duplex), while the other end does. The defaut for a failed Autonegotiation is 10/Half, so if you have one end FIXED at 10/Full then there is the problem.


Reply to

Thanks Bod and Peter.

That was all of the sh int for the interface. However, I am fairly certain that it is merely a cosmetic issue. After clearing the counters, everything reset to zero, except for the collisions. Very odd.

Peter, this seems to verify what I am thinking, and what I have heard from follow-up with someone who previously posted a similar problem, but never received a response via the group. I am going to manually configured speed/duplex on the trunk interfaces for each switch and see if that helps.

Hopefully, this does help. I am actually going to be going through our entire switch infrastructure and verify the trunk links are all manually configured, so that no autonegotiation occurs between them.

Thanks again!

Cheers from the USA

Reply to

"> None of the physical interfaces have any > collisions at all, for the last week. "

This eliminates a duplex missmatch as a possibility.

The lost packets that a duplex missmatch causes are the result of collisions that are not detected at the FD interface. These collisions ARE detected at the HD interface. No collisions = no lost packets.

Unless of course you don't believe the counters and suspect that there actually are interfaces that are on HD that are not correctly reporting collisions. Cisco counters though are usually OK. EXCEPT of course that some more modern switches incorrectly include the collision count in the error total for the interface. However Collisions are not Errors.

Reply to

You indeed have some type of serious problem. You should NEVER, EVER, EVER see collisions or errors on a VLAN interface, because it is virtual, not a real interface. You are running a VERY old version of code on this box, and I do remember seeing this issue before. (slowness and errors on the VLAN interface seem familiar) My memory is very foggy on this, but I believe it was a bug. I would suggest that you upgrade the IOS version. 12.0(5).WC5a was the first really stable release on the 3500XL (Sept 2002), and the current release is 12.0(5).WC15 (Dec 2006) The version you are running also has some very nasty security issues, that should be addressed.


Reply to

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.