CRC errors on E1 WIC caused by LAN congestion ??!!

Unanswered Question
Nov 3rd, 2009

Dear all,

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.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Giuseppe Larosa Tue, 11/03/2009 - 11:23

Hello Tsilavo,

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


tranarison Tue, 11/03/2009 - 11:44


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

burleyman Thu, 11/05/2009 - 06:38

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)

Description: LAN

Internet address is

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?



burleyman Thu, 11/05/2009 - 07:36

The Gi0/0 interface connectes to a Riverbed applicance that connects to a Catalyst 3560 switch.


Paolo Bevilacqua Thu, 11/05/2009 - 08:51

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.

burleyman Thu, 11/05/2009 - 09:00

I know about the new thread....I thought about that after I 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,


Paolo Bevilacqua Thu, 11/05/2009 - 09:07

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.

burleyman Thu, 11/05/2009 - 09:19

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

BUG Toolkit:

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".

Paolo Bevilacqua Thu, 11/05/2009 - 09:29

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.

burleyman Thu, 11/05/2009 - 12:11

I will have TAC do that....thanks for your help.

Now off to the next thing.... :-)



This Discussion