Problem with input packet errors, MAC ARP table loss (WS-C2950G-48-EI)

[fr0x]

Hello! I keep getting information on my switch Fa0/27 port input packet errors, but cannot figure out, what kind of device is creating those errors. Is there any way to see on WS-C2950G-48-EI device, what device in ethernet network is sending error packets. I would like to see the MAC of the device. Is it possible for WS-C2950G-48-EI? Port's interface status dump below.

I can put *NIX/Windows PC box on the network, to check for errors from "inside", but then I have to know, what kind of software I have to use? Is there any packet sniffers on the net, which collects error packets on switched network?

I have noticed that, if error packet is received on WS-C2950G-48-EI Fa port, WS-C2950G-48-EI automatically resets MAC address table on that port. Is there any option, which to set on WS-C2950G-48-EI not to reset arp table on port if an input error packet is received on port?

Thanks.

switch#show interfaces Fa0/27
FastEthernet0/27 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 000d.bd3f.02db (bia 000d.bd3f.02db)
Description: brivibas22-switch
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 100BaseTX
input flow-control is unsupported output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:00, output hang never
Last clearing of "show interface" counters never
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 671000 bits/sec, 84 packets/sec
5 minute output rate 414000 bits/sec, 83 packets/sec
1526517221 packets input, 1914184066 bytes, 0 no buffer
Received 1391408 broadcasts (271322 multicast)
0 runts, 6 giants, 0 throttles
1116 input errors, 743 CRC, 367 frame, 0 overrun, 0 ignored
0 watchdog, 271322 multicast, 0 pause input
0 input packets with dribble condition detected
1222472371 packets output, 1163628669 bytes, 0 underruns
0 output errors, 0 collisions, 3 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

 

[cisconooblet]

What is that port connected to? Unless its connected to a hub the errors come from whatever is connected to the port.
Is this an access port or trunking port?


As far as monitoring on a switched network you can create a monitor port on your switch and plug in a machine with an analyzer.

 

[fr0x]

I have Repotec RP-1708K switch (10/100 Mbps standart switch) connected to 2950 switch port. It's access port (see below).

What kind of analyzing software you could suggest. I could add a PC box on the next port with VLAN 11, so they would be in one switched network.

As far as I understand thos error packets does not get thru this port, because Cisco switch says there is no output errors on the port Fa0/27 --> " 0 output errors, 0 collisions, 3 interface resets" and clients connected to other ports with vlan 11 on 2950 are not getting packet loss, what I cannot say about those on Fa0/27.. :/


switch#show running-config
...
!
interface FastEthernet0/27
description brivibas22-switch
switchport access vlan 11
switchport mode access
!
...

 

[cisconooblet]

Yes if the frames does not pass the FCS check it will be dropped, so it will not forward the frames. If you want something free you can use wireshark, and mirror a port on the switch. However I'd check a few things first.

Have you checked the cabling? New cable, ends, re-punch, new patch cable etc? Checked that both switches have negotiated or been set to full duplex? Using CAT5 or better? Cable isn't bundled up with a power cable etc. Its less than 100m? I'm just throwing out stuff. That doesn't seem like a lot of errors to me, I'm assuming you are here because of the interface resets.

 

[robertjo24]

As cisconooblet suggested, check the physical layer first.

I would also force the insterfce on both ends to 100/FULL. I have had some problems with the 2950 series interfacing with non-Cisco equipment. Forcing the interface seemed to work for me.

 

[fr0x]

Installed WS-C2950-24 on other side, so now I have WS-C2950G-48-EI on one side and WS-C2950-24 on the other. Configured both ports to speed 100, duplex full. We are using CAT5 outdoor cables, and the length of cable is 70m (aprox).

After quite a while I keep getting packet loss again. Here is stats of the other sides WS-C2950-24 switch ("2 input errors, 1 CRC, 1 frame, 0 overrun, 0 ignored" and "3 output errors, 4 collisions, 2 interface resets").

Does WS-C2950-24 Standard Image switch forward error packets, instead of Enhanced Image?

switch#show interfaces fa0/1
FastEthernet0/1 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 0017.e0ea.3641 (bia 0017.e0ea.3641)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 100BaseTX
input flow-control is unsupported output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:26, output 00:00:00, output hang never
Last clearing of "show interface" counters never
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 73000 bits/sec, 12 packets/sec
5 minute output rate 71000 bits/sec, 8 packets/sec
2920913 packets input, 988891249 bytes, 0 no buffer
Received 18373 broadcasts (0 multicast)
0 runts, 0 giants, 0 throttles
2 input errors, 1 CRC, 1 frame, 0 overrun, 0 ignored
0 watchdog, 1501 multicast, 0 pause input
0 input packets with dribble condition detected
4647212 packets output, 553318458 bytes, 0 underruns
3 output errors, 4 collisions, 2 interface resets
0 babbles, 3 late collision, 8 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out

 

[cisconooblet]

If your switch is using "store and forward" switching it will discard errored frames. (default) If its been changed to say "cut-through" switching it will not discard the errored frames as it forwards them as soon as it can.

Are you sure that cable is only 70m? Late collisions can mean that your cable is to long. Also I would use a different cable than the original all together. EMI can also cause sporadic errors. If you ran a temp line you could check both assuming you didn't run it with the original path.

 

[fr0x]

Thanks for your help and concern, it's 10:30pm in my country, so I will continue tomorrow, and will let you know about the results.

Will check documentation about Cut-Through and Store-and-Forward Ethernet Switching feature in Cisco switches.

Good luck.

 

[vipergg]

Verify settings , you cannot get collisions if both sides are hardcoded to 100/full . If you hardcoded one side and left the other at auto then you could have collisions. If its only a few collisions then those probably came while setting the ports and ignore them . to get a better look at whats happening first do the following "clear controllers ethernet controllers" , then do a show controllers ethernet controllers and this gives you better stats than show interface. Also you cannot run a different image on the 2950 because they all use the same image , the software is smart enough to know what switch you have and it will use either the EI feature set if a switch is a ei switch or the standard image if it not . Maybe post a show run on both interfaces and a show interface status .Input errors can also be caused when traffic is coming in on a interface faster than the switch can process it , if traffic is low then that is probably not the problem.

 

[fr0x]

Seems that there is some problems with physical layer. What kind of device you recommend to use, to check quality of the cable?

vipergg, here is the result of the clearing controllers.

#clear controllers ethernet fastEthernet0/27
#show controllers ethernet fastEthernet0/27

Transmit Receive
8040394 Bytes 9547416 Bytes
9667 Frames 10448 Frames
8 Multicast frames 1 FCS errors
124 Broadcast frames 82 Multicast frames
0 Pause frames 110 Broadcast frames
0 Single defer frames 0 Control frames
0 Multiple defer frames 0 Pause frames
0 1 collision frames 0 Unknown opcode frames
0 2-15 collisions 1 Alignment errors
0 Late collisions 0 Length out of range
0 Excessive collisions 0 Symbol error frames
0 Total collisions 0 False carrier errors
0 Control frames 0 Valid frames, too small
0 VLAN discard frames 0 Valid frames, too large
0 Too old frames 53 Invalid frames, too small
0 Tagged frames 0 Invalid frames, too large
0 Aborted Tx frames 0 Discarded frames

Transmit and Receive
6891 Minimum size frames
1240 65 to 127 byte frames
184 128 to 255 byte frames
301 256 to 511 byte frames
495 512 to 1023 byte frames
10951 1024 to 1518 byte frames
0 1519 to 1522 byte frames

 

[fr0x]

Counter for "Invalid frames, too small" is increasing, for now it's already "53 Invalid frames, too small".

 

[fr0x]

The same with FCS errors! "162 FCS errors".