Does someone has already encountered the following ?
I have two routers CISCO2851 linked by microwave with E1 interface (VWIC2-2MFT-G703). I have too much CRC errors on both E1 interfaces when one of the routers is connected to LAN switch.
But if I cross connect a PC directly to the LAN port, no error occurs even if I load high traffic.
Is it possible that a LAN congestion on the switch could cause CRC errors on my E1 WAN interfaces ??
Some colleagues think that the switch might have an electrical problem passing electrical flow through the Ethernet copper cable, and cause router clocking unstable.
Any help is much appreciated.
what are doing your routers?
are you routing over the E1/ microwave link or are you doing bridging to carry ethernet frames over it?
if you are routing IP packets are extracted from ethernet frames and sent within PPP or HDLC frames (routed)
if you are bridging ethernet frames are placed inside PPP or HDLC frames and carried to the other side.
I think it is more likely a question of burstiness of traffic, the lan switch can send bursts (groups of frames near in time) and the PC sends less traffic (it is a single NIC after all).
An electrical issue is lees likely.
if you are using bridging I would consider to move to a routed solution.
Hope to help
Thanks for your prompt reply.
I confirm that I use routing over the E1 link.
How can I check and solve this burstiness traffic generated by the LAN switch (WS-C3750G-24TS).
With the PC, for testing purpose, I used WAN killer generating non-stop full 2 Mbps traffic on the link.But once I connect to my switch, errors appear and increase quickly;
On my router LAN interface, I have no error in exception of the following :
227 unknown protocol drops
173942 unknown protocol drops
I am seeing what may be the same issue.
GigabitEthernet0/0 is up, line protocol is up
Hardware is MV96340 Ethernet, address is xxxx.xxxx.xxxx (bia xxxx.xxxx.xxxx)
Internet address is 10.23.1.225/24
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is T
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:17, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:16:22
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 3000 bits/sec, 4 packets/sec
5 minute output rate 7000 bits/sec, 4 packets/sec
9835 packets input, 1328727 bytes, 0 no buffer
Received 51 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
9487 packets output, 2317792 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
33 unknown protocol drops
26816 unknown protocol drops
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
Did you find any resolve?
That is, cable goes straight to appliance, or switch ? These can be STP or other proprietary packets.
Anyway, please open new thread for new problems.
I know about the new thread....I thought about that after I replied....it looked like it was the same issue. I think I am ok with this now, I got a responce from our Cisco TAC and here is what he said...From the case notes, I understand that you are receiving a some "Unknown
Protocol Drops" on your Gigabit Interface; but actually, this is not an
issue, it is a counter integrated in several 12.4 versions, and it
increments every time that the interface receives a packet that the device
is not configured to support.
For example, sometimes when an interface is configured to support a specific
Routing Protocol, but by any reason it receives a packet from another
Routing Protocol, the interface discards that packet and it is considered an
Unknown Protocol Drop.
Thanks for you help,
All good, the thing is that:
1. apparently you have 26,000 of these in 16 minutes, that is about 25 ppps, that's little high and one would naturally like to know what these are exactly.
2. the TAC reply implies that these are IP packets (unknown routing protocol), but "IP unknow" these have never been counted under interface, rather under "show ip traffic".
3. The simple fact of having two counters with the same identical description, but different values, is wrong and confusing in itself, although just cosmetic.
He just sent me this as well. I thought it was very high as well. I may continue to look at this but right now the circuit is working good so I don't want to interfere too much but I am curious about the things you listed. Just a side note...this thread must be corrupt because I tried to rate your posts and they don't show up...sorry.
BUG ID: CSCsh98950
The last link, is not an actual BUG, it is like an enhancement request to
show the counter. As you can check the severity is "4 - Minor".
I see, the matter is even more confusing when you consider that the enh. request is still open, but it appears like it has made to live code already.
Not really surprising as Cisco has an history of messing unpredictably with this type of things (and worse).
If you have the case still open that would be a good chance to request that the duplicate counters are either merged, or labeled properly.