packet loss question

[rleung2001]

ATM circuit has packet loss. I have 2 question According to the atm 0/0/0 result, how come abort is 0.

The 2nd question is what is Total output drops: 60 respresent?

ATM0/0/0 is up, line protocol is up

Hardware is HWIC-DSLSAR (with Alcatel ADSL Module)

Description: AHEC 638385_22.ACFS.707.542.4141_10.154.218.1_255.255.255.252

Internet address is 10.154.218.2/30

MTU 4470 bytes, sub MTU 4470, BW 512 Kbit, DLY 1000 usec,

reliability 255/255, txload 4/255, rxload 4/255

Last clearing of "show interface" counters 5d23h

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 60

Queueing strategy: Per VC Queueing

30 second input rate 9000 bits/sec, 8 packets/sec

30 second output rate 20000 bits/sec, 9 packets/sec

812621 packets input, 358035342 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 37 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

693317 packets output, 87984642 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

=====================

Sending 500, 4470-byte ICMP Echos to 10.154.218.1, timeout is 2 seconds:

Packet sent with a source address of 10.154.218.2

Packet has data pattern 0xAAAA

!!!..!..!.....!!.!.!!....!...!!!!.!.!!!!!.!.!!!!..!.!!!.!!.!

Success rate is 55 percent (33/60), round-trip min/avg/max = 124/128/148 ms

[lamav]

Leung:

0 aborts is good. You dont want aborted packets.

But you are dropping packets, thats what the 60 output drops means.

You have 37 CRC errors, too. I would do the simplest thing first and open a ticket with the carrier and have them test the circuit, especially if this used to work but doesnt now.

HTH

Victor

[Joseph W. Doherty]

Normally output drops indicate packets that were dropped due to outbound queue overflow. E.g. if a queue is size for 40 packets, and any more packets arrive while there are 40 packets in the queue, they are dropped and the count is incremented.

You only show 60 drops out of 693317 packets output. A very small percentage. How important the percentage is varies based on the type of traffic, but a very rough rule of thumb, usually anything less than 1% is acceptable.

The 45% loss you've noted, where you ping the next hop on the ATM link, could indicate a major problem, or not. Not enough information to say, by ordinarily, worth further investigation.

[marikakis]

Hello,

I quite agree with Joseph. Just wanted to draw your attention to the fact that the peer IP address can (and normally is) several "hops" away inside the ATM network. You see ping drops in this VC, which can cross a number of ATM switches until it is terminated at the peer IP address. There is no indication of a major physical layer issue between your equipment and the DSLAM port that terminates your physical layer connection. The few CRC's do not explain the drops you saw, unless all of those CRC's happened exactly at the time you pinged the peer IP address. So, it could be some physical problem further away from your assigned DSLAM port. It could be a congestion issue inside the carrier network. The congestion issue could also be due to your VC exceeding its traffic contract. Your router might allow higher burst than the provider is willing to allow during times of congestion in its own network. Sometimes your burst might not be an issue, but others it can be. If the output that you posted is indicative of the traffic levels during the time you pinged, then VC congestion is not very likely, because your traffic levels are pretty low.

In conclusion, I would check about either a general physical layer issue inside the provider network or a congestion issue there (I mean further away from your local loop).

Kind Regards,

M.