MichaelBalack
asked on
Why input errors on my Cisco 881 Internet router?
This is using Cisco Router 881 as a Internet router, for my Internet bandwidth 100 Mbps. This is a new setup. Recently, I typed "int fastethernet4" (for the WAN interface), and found that there are few errors as follows:
DSL#sh int fa4
FastEthernet4 is up, line protocol is up
Hardware is PQII_PRO_UEC, address is 885a.92c2.dba0 (bia 885a.92c2.dba0)
Internet address is xxx.xxx.xxx.xxx/23
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 6/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 never
Input queue: 23/75/1563/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 2358000 bits/sec, 193 packets/sec
5 minute output rate 64000 bits/sec, 105 packets/sec
15760684 packets input, 884649953 bytes
Received 0 broadcasts (0 IP multicasts)
178 runts, 0 giants, 905* throttles
985 input errors, 1 CRC, 0 frame, 984 overrun, 0 ignored
0 watchdog
0 input packets with dribble condition detected
13190300 packets output, 3412388052 bytes, 0 underruns
0 output errors, 0 collisions, 4 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
1 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Do the following matter? As they are increasing... How about 1 lost carrier?
178 runts, 0 giants, 905* throttles
985 input errors, 1 CRC, 0 frame, 984 overrun, 0 ignored
Thanks in advance
DSL#sh int fa4
FastEthernet4 is up, line protocol is up
Hardware is PQII_PRO_UEC, address is 885a.92c2.dba0 (bia 885a.92c2.dba0)
Internet address is xxx.xxx.xxx.xxx/23
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 6/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 never
Input queue: 23/75/1563/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 2358000 bits/sec, 193 packets/sec
5 minute output rate 64000 bits/sec, 105 packets/sec
15760684 packets input, 884649953 bytes
Received 0 broadcasts (0 IP multicasts)
178 runts, 0 giants, 905* throttles
985 input errors, 1 CRC, 0 frame, 984 overrun, 0 ignored
0 watchdog
0 input packets with dribble condition detected
13190300 packets output, 3412388052 bytes, 0 underruns
0 output errors, 0 collisions, 4 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
1 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Do the following matter? As they are increasing... How about 1 lost carrier?
178 runts, 0 giants, 905* throttles
985 input errors, 1 CRC, 0 frame, 984 overrun, 0 ignored
Thanks in advance
ASKER
Hi Vyaradaikin,
The Cisco router is connected with cat6 rj45 cable, with length in 5 meters, connected to the Internet ONT (Optical Network terminal).
The equipments on the other side is all those ISP Internet devices.
The Cisco router is connected with cat6 rj45 cable, with length in 5 meters, connected to the Internet ONT (Optical Network terminal).
The equipments on the other side is all those ISP Internet devices.
So, as I see the demarcation point(point of resposibility) ends with this patchcord. You can check this by enabling some device, laptop for example to the router and then ping your router. If errors continue to appear then you may change patchcord, port and try ping again. Also you must check the ISP equipment by enabling to their equipment by laptop also. So that you can narrow circle of possible problem.
ASKER
Hi vyaradaikin,
Users also feedback to me that certain web sites - yahoo, facebook, may delayed and and can not access as well.
Users also feedback to me that certain web sites - yahoo, facebook, may delayed and and can not access as well.
This also could be cause of the MTU mismatch with your ISP. You can check it by configuring tcp mss adjustment on user-side routed interface:
ip tcp adjust-mss 1380
Then try to access sites againg. If problem still exist search within physical connection. If problem is gone, then you must configure MTU your ISP support.
ip tcp adjust-mss 1380
Then try to access sites againg. If problem still exist search within physical connection. If problem is gone, then you must configure MTU your ISP support.
ASKER
Hi vyaradaikan,
I have put in the mtu adjustment in the router VLAN1 interface as follows:
Interface vlan1
description office network
ip address 192.168.100.1 255.255.255.0
ip nat inside
ip virtual-reassembly
ip tcp adjust-mss 1452
My ISP is using mtu - 1452. I will monitor the status...
I have put in the mtu adjustment in the router VLAN1 interface as follows:
Interface vlan1
description office network
ip address 192.168.100.1 255.255.255.0
ip nat inside
ip virtual-reassembly
ip tcp adjust-mss 1452
My ISP is using mtu - 1452. I will monitor the status...
You need decrease your mss to the value less then ISP mtu. It is because IP/TCP/UDP headers add bytes to each frame. so I recommend to try 1380 as an mss value.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Before you go down the rabbit hole. run frames are a collision issue or you have seen an Ethernet frame of less than 64 bytes; however, you have one CRC error, so it could be from when you first connected. Here is a piece of advice:
clear counters
This will reset all your interfaces. From there, monitor to see if you have issues with CRC or runts. One more thing, some ISP equipment doesn't play nice with straight through cables, I had this issue numerous times with Verizon circuits and their equipment. Switch to a cross over cable, sadly, and verify if the ISP side is set for auto-negotiation or hard coded at 100/FULL and ensure you match on your side.
clear counters
This will reset all your interfaces. From there, monitor to see if you have issues with CRC or runts. One more thing, some ISP equipment doesn't play nice with straight through cables, I had this issue numerous times with Verizon circuits and their equipment. Switch to a cross over cable, sadly, and verify if the ISP side is set for auto-negotiation or hard coded at 100/FULL and ensure you match on your side.
ASKER
Sorry for the delay, let's me check and update
ASKER
Excellent, now looks stable now
Terrific. I'm glad I could help!
throttles:
Packets which can increase the processor overload include IP packets with options, expired TTL, non-ARPA encapsulation, fragmentation, tunelling, ICMP packets, packets with MTU checksum failure, RPF failure, IP checksum and length errors.
overrun:
The input rate of traffic exceeded the ability of the receiver to handle the data.
I advise you to check physical connection, what type of media you use? Check the cable length to the other side. Try to change port on cisco router.
What kind of equipment on the other side?