Linux - Networking This forum is for any issue related to networks or networking.
Notices
Welcome to
LinuxQuestions.org , a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free.
Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please
contact us . If you need to reset your password,
click here .
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a
virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month.
Click here for more info.
#1
LQ Newbie
Registered: May 2012
Posts: 5
Rep:
Troubleshooting Packet Loss Fedora 16 RX Packets
Hey all,
I'm racking my brain trying to figure this one out. I have an install of Fedora 16 and I consistently get a ~20% RX packet loss and I've tried everything I know to figure out what's causing it.
Quote:
p2p1 Link encap:Ethernet HWaddr 00:11:43:C1:89:6E
It seems as though the packets are being lost between the NIC and kernel.
My NIC is Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 01).
It fails ethtool -t p2p1
Quote:
The test result is FAIL
Before I waste all my breath though what do you normally do to troubleshoot a problem like this?
#2
Member
Registered: Nov 2004
Location: San Bernardino, CA
Distribution: Gentoo, Arch, (RedHat4.x-9.x, FedoraCore 1.x-4.x, Debian Potato-Sarge, LFS 6.0, etc.)
Posts: 261
Rep:
Well, ping -R <ip address>
#3
LQ Newbie
Registered: May 2012
Posts: 5
Original Poster
Rep:
Thanks for the reply ShadowCat8, This is the reply I received from ping -R mira.cs.memphis.edu (The computer in question)
Quote:
PING mira.cs.memphis.edu (141.225.8.92): 56 data bytes
#4
Member
Registered: Nov 2004
Location: San Bernardino, CA
Distribution: Gentoo, Arch, (RedHat4.x-9.x, FedoraCore 1.x-4.x, Debian Potato-Sarge, LFS 6.0, etc.)
Posts: 261
Rep:
Hmmm...
Well, as a note, I don't see any point where it seems to actually be hitting and/or routing on the memphis.edu network block. As an example, when I try running it from my office, the last 6 hops are as follows:
Code:
...<snip>...
bboi.net.any2ix.coresite.com (206.223.143.33)
lsan0.tr-cps.internet2.edu (64.57.20.202)
paix0.tr-cps.internet2.edu (64.57.20.203)
sttl0.tr-cps.internet2.edu (64.57.20.211)
64.57.21.97
jo100-r4.memphis.edu (141.225.244.24)
64 bytes from mira.cs.memphis.edu (141.225.8.92): icmp_req=2 ttl=52 time=132 ms(same route)
64 bytes from mira.cs.memphis.edu (141.225.8.92): icmp_req=3 ttl=52 time=153 ms(same route)^C
So, I'm wondering how your packets are getting routed to the 'mira' system... Are you on a VPN to connect to their network? I ran all those IP addresses that your packets hopped through and not one of them came back with a hostname from the sbcglobal.net DNS server in L.A.:
Code:
~ $ for i in 99.15.205.21 99.15.205.15 99.15.205.9 70.159.236.247 12.83.16.65 12.83.10.20 12.122.71.16 ; do echo "Checking ${i}..." ; nslookup ${i} 206.13.30.12 ; done
Checking 99.15.205.21...
Server: 206.13.30.12
Address: 206.13.30.12#53
** server can't find 21.205.15.99.in-addr.arpa.: NXDOMAIN
Checking 99.15.205.15...
Server: 206.13.30.12
Address: 206.13.30.12#53
** server can't find 15.205.15.99.in-addr.arpa.: NXDOMAIN
Checking 99.15.205.9...
Server: 206.13.30.12
Address: 206.13.30.12#53
** server can't find 9.205.15.99.in-addr.arpa.: NXDOMAIN
Checking 70.159.236.247...
Server: 206.13.30.12
Address: 206.13.30.12#53
** server can't find 247.236.159.70.in-addr.arpa.: NXDOMAIN
Checking 12.83.16.65...
Server: 206.13.30.12
Address: 206.13.30.12#53
** server can't find 65.16.83.12.in-addr.arpa.: NXDOMAIN
Checking 12.83.10.20...
Server: 206.13.30.12
Address: 206.13.30.12#53
** server can't find 20.10.83.12.in-addr.arpa.: NXDOMAIN
Checking 12.122.71.16...
Server: 206.13.30.12
Address: 206.13.30.12#53
** server can't find 16.71.122.12.in-addr.arpa.: NXDOMAIN
Also, noting the difference between the initial ping time versus the successive pings does indicate that there is
*something* going on with your routing:
Quote:
Originally Posted by andrewhood125
Code:
PING mira.cs.memphis.edu (141.225.8.92): 56 data bytes
64 bytes from 141.225.8.92: icmp_seq=0 ttl=44 time=558.207 ms
...<snip>...
64 bytes from 141.225.8.92: icmp_seq=1 ttl=44 time=78.591 ms (same route)
So, I'm not sure I understand what exactly is happening in your case... It looks like we aren't getting the full story here (from the network output, that is). So, are you running on a VPN? Or using a private proxy?
Let us know. HTH.
Last edited by ShadowCat8; 05-23-2012 at 01:44 PM .
Reason: Noting ping time differences
#5
LQ Newbie
Registered: May 2012
Posts: 5
Original Poster
Rep:
ShadowCat8 Thanks very much for your help. I wish I knew more about it. The memphis.edu is locked down pretty tight. I'm not real hot at network stuff (if you couldn't tell) so I may know something important but may not realize it. As far as I know though this computer is connected to our internal network. All traffic in and out of the network goes through a border where a lot of stuff is snuffed out. They only allow certain traffic in and out at that point but I'm not having problems with any of the other computers here. I'll attatch some output from on of the others just as a baseline I don't know if it will help or not.
This is netlogic.cs.memphis.edu
Quote:
eth0 Link encap:Ethernet HWaddr 00:06:5b:ce:5e:fe
I got more interesting data from netlogic on it's route. It's kind of alot sorry about that. It seemed to switch almost every time. Alternating between two different routes. I'm inside the memphis.edu network at the moment you may get a different result.
Quote:
PING netlogic.cs.memphis.edu (141.225.11.150): 56 data bytes
#6
LQ Newbie
Registered: May 2012
Posts: 5
Original Poster
Rep:
ping -R mira.cs.memphis.edu from inside the memphis.edu network
Quote:
PING mira.cs.memphis.edu (141.225.8.92): 56 data bytes
#7
LQ Newbie
Registered: May 2012
Posts: 5
Original Poster
Rep:
Any ideas on what the next step I should take is? I really appreciate the help so far.
#8
Member
Registered: Nov 2004
Location: San Bernardino, CA
Distribution: Gentoo, Arch, (RedHat4.x-9.x, FedoraCore 1.x-4.x, Debian Potato-Sarge, LFS 6.0, etc.)
Posts: 261
Rep:
Sorry about the delay, but I got *real* busy at the office getting the next generation of our server product ready for release.
Are you running any firewall (e.g. ufw, iptables or shorewall) or routing software on the one that's getting the packet-loss?
Looking over what we have above, I noted that you said about 20% packet loss... I also notice that you had ~13% of the received packets dropped at the p2p1 interface. Something is telling the p2p1 interface to ignore ~15% of the packets it receives. We need to figure out what that is... Chances are good that one file or another under /var/log should tell us why. You may want to start with /var/log/messages and see if it's in there.
As a side note, I find it funny that one of the hops that the ping had to go through was called 'adhood-7'. You get this mental image of a system passing packets until it sees one that looks like a possible customer and goes, "Hey... Slow down, man. You look like you're in a rush. You're looking for something, huh? Well, I got what you need!"
Hehe
HTH. Let us know.
Last edited by ShadowCat8; 06-05-2012 at 11:46 AM .
All times are GMT -5. The time now is 10:42 AM .
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know .
Hehe 
