Improve company productivity with a Business Account.Sign Up

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

Cisco edge router - input/crc errors on WAN interface

I am getting input and CRC errors on the WAN interface of my Cisco router.

I have tried several Cisco routers - (3) 1841's, and now a 2801.

I've replaced all cabling.  The Internet connection (cable) has been changed from coax (30x5 - replaced the modem 3 times as well), to fiber at 50x50.

We've worked with ISP and changed speed/duplex to different values - both auto and "locked" to matching values.

Any possibility the 10/100 interfaces on the 1841/2801 are having issues with the Gbe links on all sides?  The inside interface is connected to either a Gbe switch, or to the Gbe port on the Barracuda and does not report input errors.

Additionally, with 50x50 service, and a single laptop connected to the inside interface of the 1841/2801, I can only pull about 20x50.  If I bypass the Cisco and connect directly to the ISP gear, I can pull the full bandwidth (50x50).

The current configuration is:

- Cisco ME3400 fiber switch from the ISP
- copper patch cable directly to the 2801
- both devices set to auto speed/duplex
0
snowdog_2112
Asked:
snowdog_2112
  • 7
  • 4
  • 2
  • +1
1 Solution
 
snowdog_2112Author Commented:
Two additional nuggets of info:
- The Cisco router is *not* performing any NAT.  All interfaces have public IP's.
- The "problem" interface connects to the cable ISP, but we're using BGP and a GRE tunnel on this link to route a /29 block from ISP #2, which is also connected to this router via T1 WIC (s0/0/0).

Thanks in advance!
0
 
ffleismaSenior Network EngineerCommented:
few suggestions:

1. check MTU settings with service provider, or try setting it to 1500
2. hardcode both speed/duplex on SP side and router side
3. if issue persist, request service provider to provide BER test on the circuit to remove doubt on physical issues on the line. most service provider circuit are BER tested before handing over to client, but to be sure, if you can request to isolate any issues.
0
 
InfamusCommented:
can you post sh interface (troubled interface)?

and also sh run interface..
0
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

 
snowdog_2112Author Commented:
Int stats - IP changed.  Doesn't look like we're flooding the bandwidth on the interface (about 2.5mb x 0.7 mb below).
MTU is already 1500 bytes.  
As mentioned in OP - we've changed speed/duplex to every variation with no changes.
BER Test - seems to apply to serial interfaces, this is Ethernet (100Mbps) - and we've had 4 different devices connected to this router (or the other 3 routers I've replaced).

interface FastEthernet0/1
 ip address 71.71.71.71 255.255.255.240
 ip access-group in.isp1 in
 ip nat outside
 ip virtual-reassembly in
 duplex auto
 speed auto
end


FastEthernet0/1 is up, line protocol is up
  Hardware is Gt96k FE, address is 001f.ca95.7849 (bia 001f.ca95.7849)
  Internet address is 71.71.71.71/28
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 7/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 100Mb/s, 100BaseTX/FX
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 21:42:20
  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 2747000 bits/sec, 351 packets/sec
  5 minute output rate 769000 bits/sec, 207 packets/sec
     18025650 packets input, 4239067542 bytes
     Received 81283 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     101135 input errors, 152 CRC, 0 frame, 3 overrun, 14 ignored
     0 watchdog
     0 input packets with dribble condition detected
     10939957 packets output, 601933670 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out
0
 
ffleismaSenior Network EngineerCommented:
BER test doesn't necessary limited to serial interfaces, service provider can run BER test on ethernet hand-off as well primarily to test circuit before turn-over to client

i see your interface is on full 100

Full-duplex, 100Mb/s

has provider confirmed they are matching on their end?
0
 
Craig BeckCommented:
has provider confirmed they are matching on their end?
I believe so...
We've worked with ISP and changed speed/duplex to different values - both auto and "locked" to matching values.
What ISP device are you connecting your router to?
0
 
snowdog_2112Author Commented:
Charter (Wisconsin).

As mentioned, we've actually converted from a coax service (a cable modem with 10/100 Ethernet handoff), to fiber service.

On coax service, we forced the ISP to change the modem 3 times for this issue.

On fiber service, Charter has a Cisco ME3400 series switch on premise with a Gbe Ethernet handoff.

As mentioned, I've had my Cisco router 2 switch hops (fiber between) away from the Charter switch (all Gbe between), and have moved my Cisco right next to the Charter switch.
0
 
Craig BeckCommented:
What is the exact model of ME switch?
What switches do you have between the ME switch and your router (I understand you bypassed this).
0
 
snowdog_2112Author Commented:
Looks to be a ME-3400G-2CS-A  (I don't have physical access to it now, I'm going off web images that match).

I have had Netgear switches between the ME3400 in the following configurations with the same results (input/crc errors):

ME3400 --> Copper cat5e patch (replaced this several times) -->

1. Directly to my 1841
2. Directly to a temporary 2801
3. Netgear GS105 (5-port Gb) --> 1841
4. Netgear GS105 (5-port Gb) --> 2801
5. Netgear gsm7224 --> 1841
6. Netgear gsm7224 --> MM Fiber  --> gsm7224 --> 1841

Config's 5 and 6 have also been tried with the SMC coax cable modem.

you can see I haven't resorted to EE without trying a bunch of things first.  :)
0
 
Craig BeckCommented:
Ok, you're probably receiving lots of micro-bursts which is filling the buffer.

Can you post the show buffer output from the router?
0
 
snowdog_2112Author Commented:
Update - we're running tests bypassing the Cisco completely with the Charter link to see if the Barracuda reports errors.
0
 
snowdog_2112Author Commented:
Update - according to some well-hidden Cisco doc, it appears the 100mb interface is "not suitable" for WAN speeds over 15mbps.

http://www.cisco.com/en/US/prod/collateral/routers/ps10536/Routing_Poster.pdf

We're leaning toward this as the cause of the issues, since there is no piece of physical hardware that has not been replaced - several times.

Will be replacing the router with a different solution.
0
 
Craig BeckCommented:
The platform itself won't be causing this, which is why no-one (including the vendor) mentioned it.  Dropped packets are different to what the PDF is talking about (especially CRC errors).

The metrics in the router performance guide relate to how much the router can handle when under load and running different features (firewall, ACLs, IPSec, etc).  The interfaces can do what they say on the tin though.

As an example, I have a 1841 connected to my fibre-based internet service at home.  I can achieve 70Mbps on this consistently with all services apart from IP routing disabled.  That guide mentions that I should 'expect' only 25Mbps with a 1941 though, and the 1941 is a superior router to the 1841.
0
 
snowdog_2112Author Commented:
I've had literally a dozen cases open with Cisco - replaced the router 3 times, and even dropped a 2801 in as a test.  In none of these cases did Cisco (or anyone else) suggest the platform itself may be the issue.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

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.

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