Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I started monitoring our network using SmokePing. Users occasionally complain about bad network connections, but the problems went away after some minutes usually. I now wanted to get some more quantitative information about those problems.

SmokePing regularly pings servers inside our network, in a connected network and outside hosts. I only have a limited amount of control over our internal network and none at all for the connection to the outside and to the second network.

I now see quite often (2-4 times a day) that packets to the second network and the outside are dropped. Most of the times it is 1-2 packets out of 20, sometimes more. Inside our internal network no packets are dropped.

Is this an expected amount of packet loss, or does it indicate that something is wrong? I'm mainly wondering if I should bother the university IT department about it, or if I should just accept it as it is.

share|improve this question
3  
Your question is more or less impossible to answer. The rate of packet loss will depend on hardware, software and load in the network. If your users are complaining about the performance you probably have a network problem and should ask somebody with the access and tools if they can locate it. –  pehrs Jan 5 '11 at 12:48
1  
If your program to ping things sees the occasional ping get dropped then that means your program to ping things sees the occasional dropped ping and that's pretty much it. This doesn't by itself indicate the presence or absence or type or severity of any problems the network may have. Ping is a very useful tool within its limits –  RobM Jan 5 '11 at 13:34

2 Answers 2

Inside your network you can deal with packet loss, but outside it's another world.

Packet loss should be avoided, but TCP/IP (well IP is :-) ) is build a way packet loss can be managed.

2 packets out of 20, four times a day is not a issue, but you can call the IT department and see if you can check with them, but probably the answer will be: "It's not a problem". :-)

Have a nice day.

share|improve this answer

I'm agree with FrancoR (+1), but I think it's better to use an approach more from the ground up.

A packet loss means normally an issue... Cables, routers, LAG (a bench of users uploading on flickr)

In this cases, sometimes, it's enough to do an inventory to find the issue.

I'd create an Excel sheet, with the users in the rows (application/services included) and the amount of bandwidth in the columns. At the beginning you can just use imaginary numbers or just Big, Medium, Small (if your users download movies from internet is big, don't under-evaluate).

Then you can choose some victims and use some simple network monitor applets (the task manager or the windows performance monitor, netstat on *nix server/workstations) and add some numbers in the excel sheet, you can then graph it to see if there is something strange.

Other important data to collect:

  1. The time of the incident
  2. The time of scheduled jobs (using the network).
  3. The available bandwidth for your network (you should ask I guess).
  4. .....

Then, again, you add and correct the numbers in your excel sheet, as you have the time you see the variation, as you have the maximum bandwidth available you see if you reach the maximum available, and so forth...

If you did a good job and If none of the above reveal you the root cause, it means there is an hardware issue somewhere, or the issue it's outside your network.

To identify network issues you can use some extremely expensive and proprietary monitoring solutions or do some tailoring jobs with some free good ones:

http://www.makeuseof.com/tag/top-3-portable-network-analysis-and-diagnostics-tools/

Hope it helps

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.