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.
Regarding the four possibilities that were mentioned:
1. softnet backlog: no idea what that is
2. Unintended vlan tags: Quite unlikely, unless you had connected your system to a trunking port on the switch.
3. Unknown protocols: Quite unlikely.
4. IPv6 frames your not supposed to be getting: How would this happen?
For my part, I think this is just a congestion issue... perhaps at some part of the day (or time in the past) you got a burst of NAS-related traffic higher than your system can handle.
Dropped frames are not necessarily a bad thing. The traffic gets too high... the receiving end drops some frames... TCP realizes it needs to slow down... the data transfer gets throttled back to reasonable rates. 2% loss does seem rather high, but if it is a busy server... Maybe you'll want to configure some kind of network or application-level logging system and find out when exactly it is the system is getting hammered the worst.
Yes, it is problem. The question is whether the drop is harmless or critical. There are four reasons in list. If you want to know what reason cause the drop, it could take you some time to find out. You can check the sniffer result, about IPv6 packet, VLAN tag and IP protocol. If there is any this kind of packet in sniffer result, you will know reason. If no, it could be buffer full.
stateless, I have isolated the NAS, network device, and PC to be doing nothing but the test. There are no VLAN and IPv6 setup.
Quote:
Originally Posted by nini09
Yes, it is problem. The question is whether the drop is harmless or critical. There are four reasons in list. If you want to know what reason cause the drop, it could take you some time to find out. You can check the sniffer result, about IPv6 packet, VLAN tag and IP protocol. If there is any this kind of packet in sniffer result, you will know reason. If no, it could be buffer full.
Don't ignore testing. If you use testing tool to test something, testing tool could generate unknown packet, such as unknown IP protocol and unintended VLAN.
How about IP protocol? NAS access could use layer 2 packet.
It is hardly to check buffer status because so many buffer in software module.
For me the resolution to this problem was noticing that ESX reassigned ethX across the virtual NICs. After reassigning the port groups, all was well. I believe this was due to a vmxnet NIC being added after 3 E1000 NICs were added and configured. The vmxnet adapter took eth0 and shifted everything else.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.