|
Home > Archive > CCNP > December 2000 > Help packets being dropped
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Help packets being dropped
|
|
|
| Help with packets being dropped:
Output queue: 7/64/1699 (size/threshold/drops)
Conversations 5/60 (active/max active)
Reserved Conversations 0/0 (allocated/max allocated)
5 minute input rate 561000 bits/sec, 886 packets/sec
5 minute output rate 1327000 bits/sec, 715 packets/sec
178505 packets input, 14102677 bytes, 0 no buffer
Received 20 broadcasts, 0 runts, 0 giants
138 input errors, 0 CRC, 0 frame, 69 overrun, 69 ignored, 0 abort
--------------------------------------------
as you can see every time i reset my counter, the input error rate keeps going up, can any one help me to solve this problems.
thanks | |
|
| I am trying to figure this out:
Form the 3 facts:
1.Big output queue drops -- output queue (in RP) is reaching maximum size. Lots of packets (after being routing processed) are still waiting in output queue for their turn out. (outgoing stock)
2. Overruns -- receiver hardware was unable to hand received data to interface hardware buffer (incoming stock)
3. Ignored -- interface hardware buffer low /full (can’t even come in)
COULD IT BE CONCLUDED AS: Either SP/RSP is not fast enough, or CxBus/CyBus is too busy to handle the following situation:
1. Broadcast storms (What is the encapsulated protocol ? ex: if Novell is running, this could be caused by RIP of SAP updates)
2. Bursts or noise
Please help to correct it, thanks!
[This message has been edited by cuuutest (edited 12-19-2000).] | |
|
| Akholi,
My guess is you have appletalk running on that interface. I have yet to get a good answer from Cisco on this issue but all my sites running Appletalk do this. I brought to their attention with 11.3.8, but 12.0 was coming out so they weren't addressing 11.3 issues as bug reports. I'll resubmit it when I have a 12.1 site do it too.
Yankee
Yankee | |
|
| nope i am running ip.
could there be a problem between the csu/dsu and the serial interface on teh router.
if so, the csu/dsu is an adtran. How do i do loopback check?
thanks guys- any other suggestions? C&W have already done a line test and no problem from their end. | |
|
| Does that CSU/DSU has any front control to put it in loopback...
Is it a frame-relay connection can you post the Running Config or email it to me..
Usually if it is a frame relay and it is dropping frames look for BECN and FECN . If it is not zero you have a config problem at your router and at the end after your SP tested line good.
quote:
Originally posted by akohli8745:
nope i am running ip.
could there be a problem between the csu/dsu and the serial interface on teh router.
if so, the csu/dsu is an adtran. How do i do loopback check?
thanks guys- any other suggestions? C&W have already done a line test and no problem from their end.
[This message has been edited by ccnpwala (edited 12-19-2000).] | |
|
| Here is what I know regarding Input errors:
Possible Cause (according to Cisco):
- Faulty Telephone Company Equipment
- Noisy Serial Line
- Incorrect Clocking Configuration
- Incorrect Cable or cable to long
- Bad Cable or connection
- Bad CSU/DSU
- Bad MRP Hardware
- Data converter or other device being used between MRP and DSU.
Suggested Steps:
- Use a serial analyzer to isolate the source.
- Use a loopback and ping tests to isolate specific problems.
Have you ever used extended Ping testing? This is best used when you put the CSU/DSU in loopback, and execute ping from the router, and than type the following:
*Protocol IP (leave as default)
*Target IP Address: what ever you are trying to reach
*Repeat count (5): 20
*Datagram size (100): 64
*Timeout in Seconds (2): (leave as 2)
*Extended commands (n): Yes
*Source address:
*Type of service (0):
*Set DF bit in IP Header? (no):
*Validate reply data? (no):
*Data pattern (0xABCD): 0xffff
the remaining leave default.
After this test go back and change the Ping parameters again, but change the Repeat count from 20 to 100, and Datagram Size from 64 to 1500, and then change Data pattern from 0xfff to 0x000.
Keep trying different patterns, and once you have complete different Ping test, check the Serial Interface for increased Errors. If nothing has increased, then most likely your CSU/DSU, cable, and MRP are fine. It is then possible that you are dealing with a clocking issue.
One more thing to mention. I would also you Debug Serial interface to verify keepalive activity.
I hope this helps,
BigK
| |
|
| We don't use Adtrans, but I'm sure yours has options for both local and remote loopbacks. You could also put a hardloop on the end of the T1 cable and run an extended ping test to test out that end of the circuit.
Yankee | |
|
| Also look at your throughput, are you saturating the port?
Yankee |
|
|
|
|