Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
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.
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.
Hi, I'm seeing packet drop on a machine for the receiving end. Looking at a guide here, I have increased the RX ring buffer size. However, even then it's still reporting packet drops.
Two questions:
1) What do I do to troubleshoot or solve this?
2) The sender on the other hand isn't reporting any packet drop. Shouldn't the drop reported by the recipient reported by the sender as well as sent packet drop?
Routers will drop packets big time if they have no route for them. I'm seeing no errors, no overruns. So it looks like valid packets are going nowhere. Are you being attacked? Is there a firewall busy? Remember things like nmap scanning your open ports will send one packet per port number.Has anyone reported data loss?
Once you get answers to those questions (usually in logs, but you might find your logging inadequate for your curiosity) you will be able to tell us.
* Aren't ifconfig "dropped" packets referring to dropped frames on the link level? (Routing is higher up -- you can have, for example, loss of ping packets without increasing the drop count.) So, I would be inclined to look at the congestion issue, and then local ethernet cabling, cards, and drivers. I noticed this interesting article: http://datacenteroverlords.com/2013/...t-or-pause-it/
* I'd personally avoid enlarging network buffers... this attempt to mask the problem can cause more problems by confusing tcp flow control.
Hi, thanks for the answer. Here are some additional details ... The connection is PC -> Firewall -> NAS and the ifconfig was captured on the NAS while a transfer was happening from the PC to the NAS. Both links are 1Gbps connections and the whole thing is on a private network so no attacks here and no data loss has occurred. If the file is being transferred, just a lot slower than expected, does the routing issue still apply?
I checked the /var/log/messages log on the NAS but it's empty.
Quote:
Originally Posted by business_kid
Routers will drop packets big time if they have no route for them. I'm seeing no errors, no overruns. So it looks like valid packets are going nowhere. Are you being attacked? Is there a firewall busy? Remember things like nmap scanning your open ports will send one packet per port number.Has anyone reported data loss?
Once you get answers to those questions (usually in logs, but you might find your logging inadequate for your curiosity) you will be able to tell us.
Stateless is probably right about dropped packets being at link level --> congestion or other luink issues.
Divide and conquer.
There are a number of situations giving rise to lag. Each rule in the firewall, load on pcs, some network seeing a comms error and dropping back to 10 or 100MB. As that's a 3 machine link, you should be able to check who is seeing lost packets. Have you tried a transfer the other way on that link?
Stateless is probably right about dropped packets being at link level --> congestion or other luink issues.
Divide and conquer.
There are a number of situations giving rise to lag. Each rule in the firewall, load on pcs, some network seeing a comms error and dropping back to 10 or 100MB. As that's a 3 machine link, you should be able to check who is seeing lost packets. Have you tried a transfer the other way on that link?
Okay thanks. Stateless recommended to look at congestion issue first before anything else. If it's explained in more detail with the link he provided sorry it's not apparent what it is I have to do. So how do I check for congestion issues?
Assuming there are dropped packets on the NAS, the PC should be doing re-transmits? If yes, how can check on the PC end to verify?
To check for retransmits, send data and check the integrity with diff, sha1sum or md5sum. I would start with ifconfig, note dropped packets, make the transfer, run ifconfig again, and check data integrity.
Congestion you will find with tcpdump, or wireshark. Both are packet sniffers (wireshark needs wine iirc). Both are messy things to use, but they form large logs and you can check these for errors.
You are doing stuff that requires a good deal of network knowledge, and reading is in order if you are going to solve anything. Google is your friend.
To check for retransmits, send data and check the integrity with diff, sha1sum or md5sum. I would start with ifconfig, note dropped packets, make the transfer, run ifconfig again, and check data integrity.
Sorry I thought checksums will only check if the 2 files are identical. Even if there were re-transmits, the transferred file will ultimately be the same eventually I thought. Is this not the case?
I did run ifconfig and note the packet, and while doing the transfer, continuously doing ifconfig and saw the count increasing.
Quote:
Originally Posted by business_kid
Congestion you will find with tcpdump, or wireshark. Both are packet sniffers (wireshark needs wine iirc). Both are messy things to use, but they form large logs and you can check these for errors.
Just run wireshark but didn't find any re-transmission. In fact, wireshark reported no packet drop!! How can this be?
You can see from the attached screen shots the following:
Windows Explorer reported 10.9MByte/s
WireShark reported 71.1Mbit/s
WireShark reported no packet drop
The dropped pakets, on if config, happends when you have a conectivity problem with the cable. Every time when I had this problem it was a imperfect connection at the RJ-45, or cable fault.
You sould check this 1st. There could be CRC (Cyclic redundancy check) errors as well. Try to find out if there are CRC errors.
Hope it helps.
Beginning with kernel 2.6.37, it has been changed the meaning of dropped packet count. Before, dropped packets was most likely due to an error. Now, the rx_dropped counter shows statistics for dropped frames because of:
Softnet backlog full
Bad / Unintended VLAN tags
Unknown / Unregistered protocols
IPv6 frames when the server is not configured for IPv6
If any frames meet those conditions, they are dropped before the protocol stack and the rx_dropped counter is incremented.
Care should be taken to confirm that frames are not being legitimately dropped. A quick way to test this (WARNING: this test does not work for bonding interfaces) is to start a packet capture:
host:~# tcpdump
And then watching the rx_dropped counter. If it stops incrementing while the tcpdump is running; then it is more than likely showing drops because of the reasons listed earlier. If frames continue to be dropped while running tcpdump, investigation should take place to determine root cause.
Beginning with kernel 2.6.37, it has been changed the meaning of dropped packet count. Before, dropped packets was most likely due to an error. Now, the rx_dropped counter shows statistics for dropped frames because of:
Softnet backlog full
Bad / Unintended VLAN tags
Unknown / Unregistered protocols
IPv6 frames when the server is not configured for IPv6
If any frames meet those conditions, they are dropped before the protocol stack and the rx_dropped counter is incremented.
Care should be taken to confirm that frames are not being legitimately dropped. A quick way to test this (WARNING: this test does not work for bonding interfaces) is to start a packet capture:
host:~# tcpdump
And then watching the rx_dropped counter. If it stops incrementing while the tcpdump is running; then it is more than likely showing drops because of the reasons listed earlier. If frames continue to be dropped while running tcpdump, investigation should take place to determine root cause.
Sorry can you explain why the drop counter may or may not increment when running tcpdump? I thought tcpdump simply prints to log what's been received, regardless what the system is going to do with the packets.
Hi, okay got it. I have done the test via ifconfig. And as you have suggested no additional rx packet drop has occurred. So looks like it is due to one of the following reasons? So does this mean it's a network error or what? How can I determine what is causing this? And where can I read more about this change in behavior? I'd imagine a lot of network monitoring tools will suddenly report packet drop out of no where after a Linux OS upgrade. Isn't it?
Softnet backlog full
Bad / Unintended VLAN tags
Unknown / Unregistered protocols
IPv6 frames when the server is not configured for IPv6
1) Started iperf in server mode on the NAS.
Code:
[~] # /opt/bin/iperf -s -m
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.60.5 port 5001 connected with 192.168.60.2 port 52914
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.3 sec 42.9 MBytes 35.1 Mbits/sec
[ 4] MSS size 1160 bytes (MTU 1200 bytes, unknown interface)
2) Started tcpdump and write output to a file.
Code:
[~] # /opt/sbin/tcpdump src 192.168.60.2 -w tcpdump.log
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C39311 packets captured
39311 packets received by filter
0 packets dropped by kernel
3) Take note of the count of dropped rx packets on the NAS so far.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
