crc errors on a 2950G - 3750 link

Discussion in 'Cisco' started by Trent Collicutt, Apr 26, 2004.

  1. We have a group of 2950Gs connected to a stack of 3750s. One fibre line
    from each gig port on the 2950G goes to a different 3750 in the stack.
    They are Dot1Q trunked and etherchannelled.

    On the 3750

    interface Port-channel3
    switchport trunk encapsulation dot1q
    switchport mode trunk
    !
    interface GigabitEthernet1/0/3
    description 3rd Shaw
    switchport trunk encapsulation dot1q
    switchport mode trunk
    channel-group 3 mode on
    !
    interface GigabitEthernet2/0/3
    description 3rd Shaw
    switchport trunk encapsulation dot1q
    switchport mode trunk
    channel-group 3 mode on
    !
    The channel-group 3 mode on is because the gig ports are not on the same
    switch, but in the same stack.


    On the 2950G
    interface Port-channel1
    !
    interface GigabitEthernet0/1
    channel-group 1 mode on
    !
    interface GigabitEthernet0/2
    channel-group 1 mode on


    This is the setup on the switches with the problems and those without
    problems.

    IOS
    Cisco Internetwork Operating System Software
    IOS (tm) C3750 Software (C3750-I9-M), Version 12.1(14)EA1a, RELEASE SOFTWARE
    (fc1)

    Cisco Internetwork Operating System Software
    IOS (tm) C2950 Software (C2950-I6Q4L2-M), Version 12.1(14)EA1a, RELEASE
    SOFTWARE (fc1)

    Some lines are getting CRC errors and some are not. There is no difference
    in configuration of IOS version. All lines are autoed to 1000 full.

    We have another building where the 2950Gs are etherchannelled and Dot1Q
    trunked, but none of these switches are getting errors.

    On the 3750

    Port-channel3 is up, line protocol is up (connected)
    Hardware is EtherChannel, address is 000f.23d8.2683 (bia 000f.23d8.2683)
    MTU 1500 bytes, BW 2000000 Kbit, DLY 10 usec,
    reliability 255/255, txload 1/255, rxload 1/255
    Encapsulation ARPA, loopback not set
    Full-duplex, 1000Mb/s
    input flow-control is off, output flow-control is off
    Members in this channel: Gi1/0/3 Gi2/0/3
    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 00:57:07
    Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
    Queueing strategy: fifo
    Output queue: 0/40 (size/max)
    5 minute input rate 0 bits/sec, 0 packets/sec
    5 minute output rate 14000 bits/sec, 23 packets/sec
    22910 packets input, 5906203 bytes, 0 no buffer
    Received 1882 broadcasts (0 multicast)
    0 runts, 0 giants, 0 throttles
    114 input errors, 114 CRC, 0 frame, 0 overrun, 0 ignored
    0 watchdog, 919 multicast, 0 pause input
    0 input packets with dribble condition detected
    108708 packets output, 25180671 bytes, 0 underruns
    0 output errors, 0 collisions, 0 interface resets
    0 babbles, 0 late collision, 0 deferred
    0 lost carrier, 0 no carrier, 0 PAUSE output
    0 output buffer failures, 0 output buffers swapped out

    On the 2950G

    Port-channel1 is up, line protocol is up (connected)
    Hardware is EtherChannel, address is 000f.2383.5019 (bia 000f.2383.5019)
    MTU 1500 bytes, BW 2000000 Kbit, DLY 1000 usec,
    reliability 255/255, txload 1/255, rxload 1/255
    Encapsulation ARPA, loopback not set
    Full-duplex, 1000Mb/s
    input flow-control is off, output flow-control is off
    Members in this channel: Gi0/1 Gi0/2
    ARP type: ARPA, ARP Timeout 04:00:00
    Last input 00:00:00, output 00:00:04, output hang never
    Last clearing of "show interface" counters 03:12:35
    Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
    Queueing strategy: fifo
    Output queue: 0/40 (size/max)
    5 minute input rate 17000 bits/sec, 26 packets/sec
    5 minute output rate 2000 bits/sec, 3 packets/sec
    459472 packets input, 143448562 bytes, 0 no buffer
    Received 288262 broadcasts (0 multicast)
    0 runts, 0 giants, 0 throttles
    0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
    0 watchdog, 223283 multicast, 0 pause input
    0 input packets with dribble condition detected
    160340 packets output, 44546260 bytes, 0 underruns
    0 output errors, 0 collisions, 0 interface resets
    0 babbles, 0 late collision, 0 deferred
    0 lost carrier, 0 no carrier, 0 PAUSE output
    0 output buffer failures, 0 output buffers swapped out

    According to our RCDD, if it were a problem with the fibre, we would be
    seeing more erors than we are getting now, as well a different types of
    errors.

    Any ideas?


    --
    ================================
    Trent Collicutt CET
    CCNP
    ===============================
    Trent Collicutt, Apr 26, 2004
    #1
    1. Advertising

  2. I should add that the building without any errors has the 2950Gs plugged
    into a 6509. This is GBIC to GBIC, whereas the other two buildings are
    GBIC to SFP, if this makes a difference. SX multimode.

    If it were a duplex mismatch, I would expect to see one end say half duplex,
    or show some collisions. I have seen references to removing keepalives or
    CDP. Didn't work.

    Fiber was tested after installation.




    "Trent Collicutt" <> wrote in message
    news:mnejc.34249$...
    > We have a group of 2950Gs connected to a stack of 3750s. One fibre line
    > from each gig port on the 2950G goes to a different 3750 in the stack.
    > They are Dot1Q trunked and etherchannelled.
    >
    > On the 3750
    >
    > interface Port-channel3
    > switchport trunk encapsulation dot1q
    > switchport mode trunk
    > !
    > interface GigabitEthernet1/0/3
    > description 3rd Shaw
    > switchport trunk encapsulation dot1q
    > switchport mode trunk
    > channel-group 3 mode on
    > !
    > interface GigabitEthernet2/0/3
    > description 3rd Shaw
    > switchport trunk encapsulation dot1q
    > switchport mode trunk
    > channel-group 3 mode on
    > !
    > The channel-group 3 mode on is because the gig ports are not on the same
    > switch, but in the same stack.
    >
    >
    > On the 2950G
    > interface Port-channel1
    > !
    > interface GigabitEthernet0/1
    > channel-group 1 mode on
    > !
    > interface GigabitEthernet0/2
    > channel-group 1 mode on
    >
    >
    > This is the setup on the switches with the problems and those without
    > problems.
    >
    > IOS
    > Cisco Internetwork Operating System Software
    > IOS (tm) C3750 Software (C3750-I9-M), Version 12.1(14)EA1a, RELEASE

    SOFTWARE
    > (fc1)
    >
    > Cisco Internetwork Operating System Software
    > IOS (tm) C2950 Software (C2950-I6Q4L2-M), Version 12.1(14)EA1a, RELEASE
    > SOFTWARE (fc1)
    >
    > Some lines are getting CRC errors and some are not. There is no

    difference
    > in configuration of IOS version. All lines are autoed to 1000 full.
    >
    > We have another building where the 2950Gs are etherchannelled and Dot1Q
    > trunked, but none of these switches are getting errors.
    >
    > On the 3750
    >
    > Port-channel3 is up, line protocol is up (connected)
    > Hardware is EtherChannel, address is 000f.23d8.2683 (bia 000f.23d8.2683)
    > MTU 1500 bytes, BW 2000000 Kbit, DLY 10 usec,
    > reliability 255/255, txload 1/255, rxload 1/255
    > Encapsulation ARPA, loopback not set
    > Full-duplex, 1000Mb/s
    > input flow-control is off, output flow-control is off
    > Members in this channel: Gi1/0/3 Gi2/0/3
    > 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 00:57:07
    > Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
    > Queueing strategy: fifo
    > Output queue: 0/40 (size/max)
    > 5 minute input rate 0 bits/sec, 0 packets/sec
    > 5 minute output rate 14000 bits/sec, 23 packets/sec
    > 22910 packets input, 5906203 bytes, 0 no buffer
    > Received 1882 broadcasts (0 multicast)
    > 0 runts, 0 giants, 0 throttles
    > 114 input errors, 114 CRC, 0 frame, 0 overrun, 0 ignored
    > 0 watchdog, 919 multicast, 0 pause input
    > 0 input packets with dribble condition detected
    > 108708 packets output, 25180671 bytes, 0 underruns
    > 0 output errors, 0 collisions, 0 interface resets
    > 0 babbles, 0 late collision, 0 deferred
    > 0 lost carrier, 0 no carrier, 0 PAUSE output
    > 0 output buffer failures, 0 output buffers swapped out
    >
    > On the 2950G
    >
    > Port-channel1 is up, line protocol is up (connected)
    > Hardware is EtherChannel, address is 000f.2383.5019 (bia 000f.2383.5019)
    > MTU 1500 bytes, BW 2000000 Kbit, DLY 1000 usec,
    > reliability 255/255, txload 1/255, rxload 1/255
    > Encapsulation ARPA, loopback not set
    > Full-duplex, 1000Mb/s
    > input flow-control is off, output flow-control is off
    > Members in this channel: Gi0/1 Gi0/2
    > ARP type: ARPA, ARP Timeout 04:00:00
    > Last input 00:00:00, output 00:00:04, output hang never
    > Last clearing of "show interface" counters 03:12:35
    > Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
    > Queueing strategy: fifo
    > Output queue: 0/40 (size/max)
    > 5 minute input rate 17000 bits/sec, 26 packets/sec
    > 5 minute output rate 2000 bits/sec, 3 packets/sec
    > 459472 packets input, 143448562 bytes, 0 no buffer
    > Received 288262 broadcasts (0 multicast)
    > 0 runts, 0 giants, 0 throttles
    > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
    > 0 watchdog, 223283 multicast, 0 pause input
    > 0 input packets with dribble condition detected
    > 160340 packets output, 44546260 bytes, 0 underruns
    > 0 output errors, 0 collisions, 0 interface resets
    > 0 babbles, 0 late collision, 0 deferred
    > 0 lost carrier, 0 no carrier, 0 PAUSE output
    > 0 output buffer failures, 0 output buffers swapped out
    >
    > According to our RCDD, if it were a problem with the fibre, we would be
    > seeing more erors than we are getting now, as well a different types of
    > errors.
    >
    > Any ideas?
    >
    >
    > --
    > ================================
    > Trent Collicutt CET
    > CCNP
    > ===============================
    >
    >
    Trent Collicutt, Apr 26, 2004
    #2
    1. Advertising

  3. Trent Collicutt

    Gordon Smith Guest

    "Trent Collicutt" <> wrote in message
    news:lKfjc.38132$...
    > I should add that the building without any errors has the 2950Gs plugged
    > into a 6509. This is GBIC to GBIC, whereas the other two buildings are
    > GBIC to SFP, if this makes a difference. SX multimode.
    >
    > If it were a duplex mismatch, I would expect to see one end say half

    duplex,
    > or show some collisions. I have seen references to removing keepalives or
    > CDP. Didn't work.
    >
    > Fiber was tested after installation.
    >
    >
    >


    There's a couple of things you can try....
    First, lock the interfaces i.e. turn off auto-negotiation, then see if the
    errors are still occurring. Next, I'd be tempted to swap out one of the
    3750's with a 2950 to eliminate the fibre. I've seen instances of fibre that
    had been damaged and only showed intermittant faults in the form of CRC
    errors and packet loss.

    Process of elimination looks to be your best bet in this case, I'd say. You
    could also break the stack and run the switches separately - I've had some
    rather odd problems stacking 3750's. Remember, they are relatively new and
    still have some teething issues

    Cheers,
    Gordon
    Gordon Smith, Apr 26, 2004
    #3
  4. I could try hard coding, even though they autoed to full.

    If it were a problem with the stacking, but I would have thought that there
    would have been other types of error messages, or the channelling might work
    intermittantly, if at all.

    Connections between the 2950s and the 2950 and the 6500 work fine. The one
    thing that I can think that is different is the LC connectors on the 3750
    ( the 2950 and 6500 use ST) and the fact that the 3750 uses SFP modules,
    rather than the GBIC.

    Has anyone found problems using GBICs and SFPs together?


    "Gordon Smith" <> wrote in message
    news:...
    >
    > "Trent Collicutt" <> wrote in message
    > news:lKfjc.38132$...
    > > I should add that the building without any errors has the 2950Gs plugged
    > > into a 6509. This is GBIC to GBIC, whereas the other two buildings are
    > > GBIC to SFP, if this makes a difference. SX multimode.
    > >
    > > If it were a duplex mismatch, I would expect to see one end say half

    > duplex,
    > > or show some collisions. I have seen references to removing keepalives

    or
    > > CDP. Didn't work.
    > >
    > > Fiber was tested after installation.
    > >
    > >
    > >

    >
    > There's a couple of things you can try....
    > First, lock the interfaces i.e. turn off auto-negotiation, then see if the
    > errors are still occurring. Next, I'd be tempted to swap out one of the
    > 3750's with a 2950 to eliminate the fibre. I've seen instances of fibre

    that
    > had been damaged and only showed intermittant faults in the form of CRC
    > errors and packet loss.
    >
    > Process of elimination looks to be your best bet in this case, I'd say.

    You
    > could also break the stack and run the switches separately - I've had some
    > rather odd problems stacking 3750's. Remember, they are relatively new and
    > still have some teething issues
    >
    > Cheers,
    > Gordon
    >
    >
    Trent Collicutt, Apr 27, 2004
    #4
  5. Trent Collicutt

    Chris Thomas Guest

    In article <nAhjc.40610$>,
    says...
    > Has anyone found problems using GBICs and SFPs together?


    I have a bunch of 3750 sfp -> 6500 gbic fiber links and absolutely
    no problems.

    /Chris, UCLA
    Chris Thomas, Apr 27, 2004
    #5
  6. We had a switch start doing something that took down a good chunk of the
    network, and when replaced all the FCS and CRC errors to all the floors but
    one went away.


    "Chris Thomas" <> wrote in message
    news:...
    > In article <nAhjc.40610$>,
    > says...
    > > Has anyone found problems using GBICs and SFPs together?

    >
    > I have a bunch of 3750 sfp -> 6500 gbic fiber links and absolutely
    > no problems.
    >
    > /Chris, UCLA
    Trent Collicutt, Apr 27, 2004
    #6
  7. premature


    "Trent Collicutt" <> wrote in message
    news:1fAjc.65016$...
    > We had a switch start doing something that took down a good chunk of the
    > network, and when replaced all the FCS and CRC errors to all the floors

    but
    > one went away.
    >
    >
    > "Chris Thomas" <> wrote in message
    > news:...
    > > In article <nAhjc.40610$>,
    > > says...
    > > > Has anyone found problems using GBICs and SFPs together?

    > >
    > > I have a bunch of 3750 sfp -> 6500 gbic fiber links and absolutely
    > > no problems.
    > >
    > > /Chris, UCLA

    >
    >
    Trent Collicutt, Apr 28, 2004
    #7
  8. Trent Collicutt

    Chris Thomas Guest

    No, I made a statement of fact: As of today, I have had absolutely no
    problems, which was the exact question you posed in your post. You
    are (presumably) making a prediction about future events. Maybe you
    are correct, maybe not. Doesn't change what I'm seeing today. If you
    don't want other peoples' experiences, don't post asking for them.

    In article <CDUjc.4441$k%>,
    says...
    > premature
    >
    >
    > "Trent Collicutt" <> wrote in message
    > news:1fAjc.65016$...
    > > We had a switch start doing something that took down a good chunk of the
    > > network, and when replaced all the FCS and CRC errors to all the floors

    > but
    > > one went away.
    > >
    > >
    > > "Chris Thomas" <> wrote in message
    > > news:...
    > > > In article <nAhjc.40610$>,
    > > > says...
    > > > > Has anyone found problems using GBICs and SFPs together?
    > > >
    > > > I have a bunch of 3750 sfp -> 6500 gbic fiber links and absolutely
    > > > no problems.
    > > >
    > > > /Chris, UCLA

    > >
    > >

    >
    >
    >
    Chris Thomas, Apr 29, 2004
    #8
  9. Trent Collicutt

    AnyBody43 Guest

    "Trent Collicutt" <> wrote in message news:<mnejc.34249$>...
    > We have a group of 2950Gs connected to a stack of 3750s. One fibre line
    > from each gig port on the 2950G goes to a different 3750 in the stack.
    > They are Dot1Q trunked and etherchannelled.
    >
    >
    > 22910 packets input, 5906203 bytes, 0 no buffer
    > Received 1882 broadcasts (0 multicast)
    > 0 runts, 0 giants, 0 throttles
    > 114 input errors, 114 CRC, 0 frame, 0 overrun, 0 ignored
    > 0 watchdog, 919 multicast, 0 pause input


    > According to our RCDD, if it were a problem with the fibre, we would be
    > seeing more erors than we are getting now, as well a different types of
    > errors.


    This is a very high error rate ~1:200. Over fiber an error rate a
    million times less would not be unexpected. It should therefore be
    easy to track down. As another poster has recommended (I apologise
    that I have not made the effort to quote it) do component substitution
    to see if it goes away.

    You did not mention if you are on MM or SM fiber or what GBICS/other
    things you are using. If you are on MM fiber are you within the
    spec. for distance which can be as little as 220M without mode
    conditioning cables? Are your patch cords the same 50-62.5 as
    the cable?
    AnyBody43, Apr 30, 2004
    #9
  10. I was not criticizing you. We are seeing problems, even though you are not.
    We thought that we had solved our problems, but we were premature in our
    assessment. Obviously, you believed that my statement of being premature
    referred to your assessment of the devices capabilities. It referred to my
    belief that we had solved our problem.

    Obviously there is no inherent incompatibility, as your lack of problems.
    I, however, am having problems. So far changing settings and replacing
    cables have not solved my problem. Also, the errors seem to be on lines
    that are etherchannelled AND trunked. Lined that are not etherchannelled or
    not trunked are not seeing problems.

    FYI, I am not seeing problems between the 3750 and our 6509 either.




    "Chris Thomas" <> wrote in message
    news:...
    > No, I made a statement of fact: As of today, I have had absolutely no
    > problems, which was the exact question you posed in your post. You
    > are (presumably) making a prediction about future events. Maybe you
    > are correct, maybe not. Doesn't change what I'm seeing today. If you
    > don't want other peoples' experiences, don't post asking for them.
    >
    > In article <CDUjc.4441$k%>,
    > says...
    > > premature
    > >
    > >
    > > "Trent Collicutt" <> wrote in message
    > > news:1fAjc.65016$...
    > > > We had a switch start doing something that took down a good chunk of

    the
    > > > network, and when replaced all the FCS and CRC errors to all the

    floors
    > > but
    > > > one went away.
    > > >
    > > >
    > > > "Chris Thomas" <> wrote in message
    > > > news:...
    > > > > In article <nAhjc.40610$>,
    > > > > says...
    > > > > > Has anyone found problems using GBICs and SFPs together?
    > > > >
    > > > > I have a bunch of 3750 sfp -> 6500 gbic fiber links and absolutely
    > > > > no problems.
    > > > >
    > > > > /Chris, UCLA
    > > >
    > > >

    > >
    > >
    > >
    Trent Collicutt, May 1, 2004
    #10
  11. Trent Collicutt

    hausherrs Guest

    550M for SX and LX (MCC) over 50 micron.

    http://tinyurl.com/2ys8e

    I would suspect the fiber between end points whether it is a siz
    mismatch, contaminated connector, or damaged glass.

    On the other side of things I have had a cat 4500 4013 sup II replace
    because of incrementing CRC errors. TAC reported a memory problem. CRC
    were being generated between the ports (RJ45) and Supervisor. So it i
    possible for there to be a hardware problem. Granted comparing the 290
    and 4500 sup II is like comparing an apple to a pair.




    This is a very high error rate ~1:200. Over fiber an error rate a
    million times less would not be unexpected. It should therefore be
    easy to track down. As another poster has recommended (I apologise
    that I have not made the effort to quote it) do component substitution
    to see if it goes away.

    You did not mention if you are on MM or SM fiber or what GBICS/other
    things you are using. If you are on MM fiber are you within the
    spec. for distance which can be as little as 220M without mode
    conditioning cables? Are your patch cords the same 50-62.5 as
    the cable? [/B


    -
    hausherr
    -----------------------------------------------------------------------
    Posted via http://www.mcse.m
    -----------------------------------------------------------------------
    View this thread: http://www.mcse.ms/message608464.htm
    hausherrs, May 2, 2004
    #11
  12. We are running 50 micron multimode. The patch cables are also 50 micron,
    although one of the respondents to our tender, I don't remember which one,
    claimed that noone wanted these 50 micron things unless they had wasted a
    lot of money on 50 micron building wiring. We bought them anyway. We
    replaced the patch cables, with cables from a different batch, just incase
    we received a faulty batch. No difference.

    If it is a hardware error, it is occurring with several machines. I have
    noticed that when etherchanneling, I get errors only on one of the lines.
    the other is fine, even though it is carrying about the same traffic load.
    When I shut down the line with the errors, the line that was OK before
    begins to increment the error counters. Also, as I mentioned in an earlier
    post, it only happens on dot1q trunked ports, and only to the 2950Gs, and
    not to the 6509.

    I tried shutting off keepalives. I've tried shutting off CDP. I have tried
    increasing the System Jumbo MTU value.

    I have had it suggested that the GBICs and SFPs need reseating, so I'll try
    that. A coworker has suggested that the problem is with running ISL and
    dot1q on the same network. this can't be changed until our upgrade is
    complete, since the 5005s that had been used as building switches can't do
    dot1q. The OS can. The hardware can't.

    Despite what Chris thinks, I AM interested in any comments am trying to
    cover as many bases I can think of. This is my first run at using fibre for
    interconnects and undoubtably have some ideas that may have to be adjusted.
    Our network is just moving people off of hubs and Cat 3 cabling, so few
    people around here have extensive experience with these models of switches
    or fibre in general (except for one technician and a RCDD).



    "hausherrs" <> wrote in message
    news:...
    >
    > 550M for SX and LX (MCC) over 50 micron.
    >
    > http://tinyurl.com/2ys8e
    >
    > I would suspect the fiber between end points whether it is a size
    > mismatch, contaminated connector, or damaged glass.
    >
    > On the other side of things I have had a cat 4500 4013 sup II replaced
    > because of incrementing CRC errors. TAC reported a memory problem. CRCs
    > were being generated between the ports (RJ45) and Supervisor. So it is
    > possible for there to be a hardware problem. Granted comparing the 2900
    > and 4500 sup II is like comparing an apple to a pair.
    >
    >
    >
    >
    > This is a very high error rate ~1:200. Over fiber an error rate a
    > million times less would not be unexpected. It should therefore be
    > easy to track down. As another poster has recommended (I apologise
    > that I have not made the effort to quote it) do component substitution
    > to see if it goes away.
    >
    > You did not mention if you are on MM or SM fiber or what GBICS/other
    > things you are using. If you are on MM fiber are you within the
    > spec. for distance which can be as little as 220M without mode
    > conditioning cables? Are your patch cords the same 50-62.5 as
    > the cable? [/B]
    >
    >
    >
    > --
    > hausherrs
    > ------------------------------------------------------------------------
    > Posted via http://www.mcse.ms
    > ------------------------------------------------------------------------
    > View this thread: http://www.mcse.ms/message608464.html
    >
    Trent Collicutt, May 2, 2004
    #12
  13. "Trent Collicutt" <> wrote in message news:<mnejc.34249$>...
    > We have a group of 2950Gs connected to a stack of 3750s. One fibre line
    > from each gig port on the 2950G goes to a different 3750 in the stack.
    > They are Dot1Q trunked and etherchannelled.
    >
    > On the 3750
    >
    > interface Port-channel3
    > switchport trunk encapsulation dot1q
    > switchport mode trunk
    > !
    > interface GigabitEthernet1/0/3
    > description 3rd Shaw
    > switchport trunk encapsulation dot1q
    > switchport mode trunk
    > channel-group 3 mode on
    > !
    > interface GigabitEthernet2/0/3
    > description 3rd Shaw
    > switchport trunk encapsulation dot1q
    > switchport mode trunk
    > channel-group 3 mode on
    > !
    > The channel-group 3 mode on is because the gig ports are not on the same
    > switch, but in the same stack.
    >
    >
    > On the 2950G
    > interface Port-channel1
    > !
    > interface GigabitEthernet0/1
    > channel-group 1 mode on
    > !
    > interface GigabitEthernet0/2
    > channel-group 1 mode on
    >
    >
    > This is the setup on the switches with the problems and those without
    > problems.
    >
    > IOS
    > Cisco Internetwork Operating System Software
    > IOS (tm) C3750 Software (C3750-I9-M), Version 12.1(14)EA1a, RELEASE SOFTWARE
    > (fc1)
    >
    > Cisco Internetwork Operating System Software
    > IOS (tm) C2950 Software (C2950-I6Q4L2-M), Version 12.1(14)EA1a, RELEASE
    > SOFTWARE (fc1)
    >
    > Some lines are getting CRC errors and some are not. There is no difference
    > in configuration of IOS version. All lines are autoed to 1000 full.
    >
    > We have another building where the 2950Gs are etherchannelled and Dot1Q
    > trunked, but none of these switches are getting errors.
    >
    > On the 3750
    >
    > Port-channel3 is up, line protocol is up (connected)
    > Hardware is EtherChannel, address is 000f.23d8.2683 (bia 000f.23d8.2683)
    > MTU 1500 bytes, BW 2000000 Kbit, DLY 10 usec,
    > reliability 255/255, txload 1/255, rxload 1/255
    > Encapsulation ARPA, loopback not set
    > Full-duplex, 1000Mb/s
    > input flow-control is off, output flow-control is off
    > Members in this channel: Gi1/0/3 Gi2/0/3
    > 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 00:57:07
    > Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
    > Queueing strategy: fifo
    > Output queue: 0/40 (size/max)
    > 5 minute input rate 0 bits/sec, 0 packets/sec
    > 5 minute output rate 14000 bits/sec, 23 packets/sec
    > 22910 packets input, 5906203 bytes, 0 no buffer
    > Received 1882 broadcasts (0 multicast)
    > 0 runts, 0 giants, 0 throttles
    > 114 input errors, 114 CRC, 0 frame, 0 overrun, 0 ignored
    > 0 watchdog, 919 multicast, 0 pause input
    > 0 input packets with dribble condition detected
    > 108708 packets output, 25180671 bytes, 0 underruns
    > 0 output errors, 0 collisions, 0 interface resets
    > 0 babbles, 0 late collision, 0 deferred
    > 0 lost carrier, 0 no carrier, 0 PAUSE output
    > 0 output buffer failures, 0 output buffers swapped out
    >
    > On the 2950G
    >
    > Port-channel1 is up, line protocol is up (connected)
    > Hardware is EtherChannel, address is 000f.2383.5019 (bia 000f.2383.5019)
    > MTU 1500 bytes, BW 2000000 Kbit, DLY 1000 usec,
    > reliability 255/255, txload 1/255, rxload 1/255
    > Encapsulation ARPA, loopback not set
    > Full-duplex, 1000Mb/s
    > input flow-control is off, output flow-control is off
    > Members in this channel: Gi0/1 Gi0/2
    > ARP type: ARPA, ARP Timeout 04:00:00
    > Last input 00:00:00, output 00:00:04, output hang never
    > Last clearing of "show interface" counters 03:12:35
    > Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
    > Queueing strategy: fifo
    > Output queue: 0/40 (size/max)
    > 5 minute input rate 17000 bits/sec, 26 packets/sec
    > 5 minute output rate 2000 bits/sec, 3 packets/sec
    > 459472 packets input, 143448562 bytes, 0 no buffer
    > Received 288262 broadcasts (0 multicast)
    > 0 runts, 0 giants, 0 throttles
    > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
    > 0 watchdog, 223283 multicast, 0 pause input
    > 0 input packets with dribble condition detected
    > 160340 packets output, 44546260 bytes, 0 underruns
    > 0 output errors, 0 collisions, 0 interface resets
    > 0 babbles, 0 late collision, 0 deferred
    > 0 lost carrier, 0 no carrier, 0 PAUSE output
    > 0 output buffer failures, 0 output buffers swapped out
    >
    > According to our RCDD, if it were a problem with the fibre, we would be
    > seeing more erors than we are getting now, as well a different types of
    > errors.
    >
    > Any ideas?


    I found an interesting tidbit, that seems to have improved things. We
    have 2950 and 2950T workgroup switches hanging off of 2950G floor
    switches. The 2950G switches run trunked etherchannelled lines back
    to a pair of 3750 building switches. I have said that we had problems
    with FCS errors on the 3750. This only happened when we trunked over
    the etherchannel. When we simply set the etherchannel to a VLAN,
    everything was fine.

    Naturally we tried to troubleshoot the problem on the 3750-2950G link.
    We tried setting the lines running from the floor switches to the
    workgroup switches with the command "Switchport mode access". The
    errors on the 3750 disappeared, even though the workgroup switches are
    not actually directly connected. The errors seem to have skipped the
    floor switch altogether.

    It would be interesting to know why I wouldn't get an error on the
    workgroup or floor switch, but a FCS on the Building switch.
    Trent Collicutt, May 7, 2004
    #13
    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. Steve
    Replies:
    8
    Views:
    52,755
    ulziit_delger
    Jul 30, 2010
  2. Ole Vik
    Replies:
    3
    Views:
    2,160
  3. Allen
    Replies:
    4
    Views:
    2,511
    Allen
    Jun 21, 2004
  4. Captain

    CRC errors....

    Captain, Jun 15, 2004, in forum: Cisco
    Replies:
    5
    Views:
    14,116
    Sam Wilson
    Jun 17, 2004
  5. Pix 506 crc errors

    , Feb 15, 2005, in forum: Cisco
    Replies:
    0
    Views:
    847
Loading...

Share This Page