Measurement of packet drops

Unanswered Question
Sep 16th, 2008


How to measure the packet drop between two routers?..Is there any specific formula for this?....The source and destination router is geographically located...

Kindly help me urgently...

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Calin Chiorean Tue, 09/16/2008 - 03:40


SNMP and extract the data with some network management tool like CiscoWorks for example.

Also with

show interface gi0/0 sum

you can see if there are packet drops from input and output queue on one interface.

* gi0/0 is only example

Does this info help you?



minimintu Tue, 09/16/2008 - 03:53

I have not been given telnet access so i cannot check on there any other way out?...say if i know RTT, throughput and TCP window size, can i calculate the packet drop?..if yes, then how?

Joseph W. Doherty Tue, 09/16/2008 - 04:24

If you knew all the varibles, in theory I believe you could calculate expected packet drop, but I've never seen it done in practice. The number of variables to consider is quite extensive.

For TCP, you can precompute the BDP (bandwidth delay product). Having this value provides for optimal TCP transmission rate, but won't provide information about what drops you might see in actual practice. Again, many other variables.

For actual traffic, like with routers, you could record the packets sent/received at the end hosts. However, even if they match, the sending TCP host could have thought there were drops when there were not. So you need to also look at TCP retransmissions.

e.g. (From a Windows host)

C:\>netstat -s

IPv4 Statistics

Packets Received = 66730

Received Header Errors = 0

Received Address Errors = 3

Datagrams Forwarded = 0

Unknown Protocols Received = 0

Received Packets Discarded = 274

Received Packets Delivered = 66456

Output Requests = 52088

Routing Discards = 0

Discarded Output Packets = 0

Output Packet No Route = 0

Reassembly Required = 0

Reassembly Successful = 0

Reassembly Failures = 0

Datagrams Successfully Fragmented = 0

Datagrams Failing Fragmentation = 0

Fragments Created = 0

ICMPv4 Statistics

Received Sent

Messages 8 15

Errors 0 0

Destination Unreachable 0 0

Time Exceeded 0 0

Parameter Problems 0 0

Source Quenches 0 0

Redirects 0 0

Echos 0 12

Echo Replies 8 0

Timestamps 0 0

Timestamp Replies 0 0

Address Masks 0 0

Address Mask Replies 0 0

TCP Statistics for IPv4

Active Opens = 1622

Passive Opens = 42

Failed Connection Attempts = 32

Reset Connections = 742

Current Connections = 1

Segments Received = 43329

Segments Sent = 30755

Segments Retransmitted = 37

UDP Statistics for IPv4

Datagrams Received = 21272

No Ports = 3702

Receive Errors = 0

Datagrams Sent = 21273

Joseph W. Doherty Tue, 09/16/2008 - 04:06

Between two routers, the one place you're likely to see drops, is on the interface's drop counter. You can compare that value to the counter for output packets, also on the interface.

Another place for drops, when using WAN "cloud" technolgies, are drops within the WAN cloud. Assuming you have counters that register packets sent (on the outgoing router) and counters that register packets received (on the receiving router), the difference will be drops within the WAN cloud. (NB: do keep in mind you need to compare counters for the same time period.)

For presentation of drops, they're often presented as a drop percentage during some time periods; i.e. packet drops divided by packets sent multiplied by 100.


The impact of drops varies per traffic type. For instance, TCP usually continues to perform fairly well up to about a 1% drop rate. Much above that, TCP will usually continue to transfer packets, but possibly at a highly reduced transmission rate, and possibly with loss of usable bandwidth due to retransmissions.


This Discussion