Axemanbob
asked on
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...
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...
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
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
ASKER
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...!
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...!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Please post switch full sanitised switch config... do you know if the LES NTE is nailed up 10/full ??
/Fox