Lots of collisions on interface vlan 1

Discussion in 'Cisco' started by Dustin, Jan 3, 2007.

  1. Dustin

    Dustin Guest

    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
    Dustin, Jan 3, 2007
    #1
    1. Advertising

  2. Dustin

    Guest

    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).
    , Jan 3, 2007
    #2
    1. Advertising

  3. Dustin

    Peter Guest

    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.
    Peter, Jan 3, 2007
    #3
  4. Dustin

    Dustin Guest

    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
    Dustin, Jan 4, 2007
    #4
  5. Dustin

    Guest

    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.
    , Jan 4, 2007
    #5
  6. Dustin

    Thrill5 Guest

    <> wrote in message
    news:...
    >
    > 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.
    >


    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
    Thrill5, Jan 6, 2007
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. JFerri
    Replies:
    1
    Views:
    514
    FireSword
    Nov 19, 2003
  2. Jim
    Replies:
    9
    Views:
    8,490
    mikester
    Jan 5, 2004
  3. Andrew Dancy
    Replies:
    2
    Views:
    13,673
    kawad
    Jun 13, 2007
  4. chris-c

    late collisions

    chris-c, Aug 10, 2004, in forum: Cisco
    Replies:
    2
    Views:
    4,442
    Hansang Bae
    Aug 11, 2004
  5. Liam

    Switches and collisions

    Liam, Sep 9, 2004, in forum: Cisco
    Replies:
    6
    Views:
    622
    Scooby
    Sep 10, 2004
Loading...

Share This Page