07-18-2004 07:27 PM - edited 03-02-2019 05:09 PM
Dear all :
I just have a problem that I can not explain the reason:
PC--cat6500(gw)---Rt1_7507(atm)---(atm)Rt2_7507.The two routers are connected by ATM line (each router hase a PA-A3-OC3SMI). On Rt1_7507 ,I ping the Rt2_7507's directly connected port address(extend ping ) ,and I find about 2% packets lost during ping .The packet size is 18024 .But when I ping Rt2_7507's wan interface on PC with same packet size ,no packet is lost .
the IOS version of two router is 12.1.19e6 . why ?
07-22-2004 01:23 PM
Typically when you test packet loss with ping don't ping the router itself because it consider the processing of ICMP echo reply a low task and if the box is loaded it will simply discard them. However try to ping a device that is beyond the router. This is a more reliable test.
07-23-2004 12:42 AM
but,the router is light load (almost no load ) and the bandwidth of the wan link is 10M .So I think there lies in othe reason .
07-23-2004 07:53 AM
What type of ATM circuit do you have, what is the exact bandwidth the ISP is providing and what is your config state. I would first decrease the bandwidth alloted in your routers to 9Mbs and see if that fixes your problem. You might just be over the limit a little which will cause problems. Let me know if that works and please provide your configs on both sides.
Jason Smith
07-23-2004 09:18 AM
The big difference between the ping from the PC and the router is the size of the packet. When you ping from the PC it will be a 1500-byte packet, which is around 32 ATM cells. When you ping from the router you've said it's an 18,024-byte packet which is around 376 cells.
If you over-subscribe the service that the carrier has provided they will drop cells. One dropped cell is a lost ping.
The chances of cell loss for the large packet is much greater.
Drop the ping size on the router and see if you loose any packets. Also check the output of the "sh int" and look to see if you're getting any CRCs. On ATM these are typically caused by dropped cells within the service provider.
Regards
07-23-2004 10:06 AM
If you do a sh atm pvc vpi/vci look for CRC error in this command , this indicates you are exceeding your contracted rate . Watch for it incrementing while pinging. If you ping and drop while below the size of your PVC then the provider has something misconfigured.
sh atm pvc vpi/vci
VBR-NRT, PeakRate: 2000, Average Rate: 2000, Burst Cells: 32
AAL5-LLC/SNAP, etype:0x0, Flags: 0x20, VCmode: 0x0
OAM frequency: 0 second(s), OAM retry frequency: 1 second(s), OAM retry frequency: 1 second(s)
OAM up retry count: 3, OAM down retry count: 5
OAM Loopback status: OAM Disabled
OAM VC status: Not Managed
ILMI VC status: Not Managed
VC TxRingLimit: 78 particles
VC Rx Limit: 23 particles
InARP frequency: 15 minutes(s)
Transmit priority 4
InPkts: 65274143, OutPkts: 122803702, InBytes: 2202883304, OutBytes: 2608861576
InPRoc: 343425, OutPRoc: 481284
InFast: 64930718, OutFast: 122322494, InAS: 0, OutAS: 0
InPktDrops: 0, OutPktDrops: 7319001/0/7319001 (holdq/outputq/total)
InByteDrops: 0, OutByteDrops: 0
CrcErrors: 1954, SarTimeOuts: 0, OverSizedSDUs: 528, LengthViolation: 0, CPIErrors: 0
Out CLP=1 Pkts: 0
OAM cells received: 81
F5 InEndloop: 0, F5 InSegloop: 0, F5 InAIS: 81, F5 InRDI: 0
F4 InEndloop: 0, F4 InSegloop: 0, F4 InAIS: 0, F4 InRDI: 0
OAM cells sent: 81
F5 OutEndloop: 0, F5 OutSegloop: 0, F5 OutRDI: 81
F4 OutEndloop: 0, F4 OutSegloop: 0, F4 OutRDI: 0
OAM cell drops: 0
Status: UP
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide