[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2318
  • Last Modified:

Input errors on Fastethernet trunk

I have a Catalyst 3560 switch at an out-site, connecetd back via cat5e over a BT LES 10Mb circuit abck to the core 6509 switch.
I have been getting input errors increasing on the edge switch, on the trunk that connects it back to the 6509.  The users at the site have been experiencing a few issues with VoIP break-up, and I'm wondering if this is related, and what could be causing it.  

I've changed the patch leads at both ends, and changed the ports (and even the blades/switches) at both ends.  BT have tested the LES circuit, and not detected any issues on it, even under full load.  

The errors I get show up like this  (Counters cleared about 10 mins prior to this)...

FastEthernet0/24 is up, line protocol is up (connected)
  Hardware is Fast Ethernet, address is 0023.5d18.801a (bia 0023.5d18.801a)
  Description: LES 2 circuit to Core
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
     reliability 255/255, txload 8/255, rxload 21/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 10Mb/s, media type is 10/100BaseTX
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:01, output hang never
  Last clearing of "show interface" counters 00:12:40
  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 832000 bits/sec, 296 packets/sec
  5 minute output rate 320000 bits/sec, 286 packets/sec
     206713 packets input, 72601492 bytes, 0 no buffer
     Received 4719 broadcasts (0 multicasts)
     0 runts, 0 giants, 0 throttles
     25 input errors, 25 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 3583 multicast, 0 pause input
     0 input packets with dribble condition detected
     201211 packets output, 27942893 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

I always get the same rate of input errors and CRCs.  I really can't think what else it could be.  

Interface is set up as follows :-

interface FastEthernet0/24
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan x,y,z
 switchport mode trunk
 speed 10
 duplex full
 mls qos trust dscp
end

So nothing special.  

I'm not sure whether this rate of errors would be performance-impacting on this link, and would appreciate input on this too.

By the way, the other end (6509) does not have any errors showing...
0
Axemanbob
Asked:
Axemanbob
  • 2
  • 2
1 Solution
 
knightfoxCommented:
Axe,

Please post switch full sanitised switch config... do you know if the LES NTE is nailed up 10/full ??

/Fox

0
 
knightfoxCommented:
Here is what you need to do.

Check that you do not have duplex mismatch using
http://www.cisco.com/en/US/tech/tk38...80094781.shtml

Basically if you have a mismatch the HD end *may* record
late collisions and the FD end may record CRC and/or Frame
(Align) and/or Runts. If the traffic is heavy you are pretty certain
to see these reports.

If you don't have a mismatch then you can decide whether you
need or want to change the ports registering collisions from
HD to Full Duplex. The chances are that for a PC it will make
little measurable or noticable difference.

Collisions (or as Mr Siefert would now call them Contention Events)
are a perfectly normal part of ethernet operation.

Plan B.
You will *never* be happy until the collision counters are gone.
Convert all links to FD immediately. Then carry out the same
checks as above to make sure that you do not have
duplex mismatches.

You have also changed the cables.. to CAT5e which is alwasy the best place to start with CRC's.. I would also just make doubley sure that there is no interference around the cables.. power.. ect...

I have seen this before on one or out remote MPLS routers... it turned out to be a duplex mismatch...

/Fox
0
 
AxemanbobAuthor Commented:
There arn't any collisions.  Both ends are running at 10Mb, Full duplex fixed.  I don't do auto negotiation over LES circuits at all.  

The only errors showing up are on the remote switch, and are input and CRC errors (always the same quantity of each).  

The NTE is 10Mb/Full, and has been end-to-end tested as such by BT (with me there!).  

Hmmmm....  I'm not sure where else I can look...!
0
 
AxemanbobAuthor Commented:
Still ahvent found a solution to this.  Closing question for now.
0

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now