Tags: beenexperiencing, cisco, collisions, interface, lastweek, lots, million, slowness, software, switch, users, vlan

Lots of collisions on interface vlan 1

On Software » Cisco

13,093 words with 5 Comments; publish: Wed, 04 Jun 2008 02:16:00 GMT; (400218.75, « »)

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 192.168.253.16/24

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

All Comments

Leave a comment...

  • 5 Comments
    • Dustin wrote:

      > 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 192.168.253.16/24

      > 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

      Basically virtual interfaces can't have collisions.

      The report is erroneous. Most likely a cosmetic bug.

      > 2346 packets input, 173859 bytes, 0 no buffer

      > Received 2021 broadcasts, 0 runts, 0 giants, 0 throttles

      > 262 packets output, 21449 bytes, 0 underruns

      > 0 output errors, 20763204 collisions, 0 interface resets

      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).

      #1; Wed, 04 Jun 2008 02:18:00 GMT
    • Hi Dustin,

      > 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.

      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.

      Cheers...........pk.

      Peter from Auckland.

      #2; Wed, 04 Jun 2008 02:18:00 GMT
    • 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

      #3; Wed, 04 Jun 2008 02:19:00 GMT
    • Dustin wrote:

      > 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.

      >

      "> 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.

      #4; Wed, 04 Jun 2008 02:21:00 GMT
    • <Bod43.cisco.todaysummary.com.hotmail.co.uk> wrote in message

      news:1167945791.943604.307190.cisco.todaysummary.com.s34g2000cwa.googlegr oups.com...

      > Dustin wrote:

      >

      > "> None of the physical interfaces have any

      > 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.

      >

      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.

      Scott

      #5; Wed, 04 Jun 2008 02:21:00 GMT