The earlier mentioned fact you have that using tcpdump causes the drops to disappear indicates that whatever the packets are the nic believes they aren't destined for your host. Use this to see all packets not going to your local node. tcpdump -i <yournetinterface> ! host <youripaddress> If those packets are close to the number of the drops/min those are likely the drops. The issue with "drops" is they aren't what most people think are drops (ie packets my host does not care about) most of the time. I about the only time real drops happen involve the nic interface running > 25% rated and/or the host being under extreme cpu or paging stress. On Mon, Jun 5, 2023 at 6:41 AM Alex <mysqlstudent@xxxxxxxxx> wrote: > > Hi, > >> >> I have an E3-1240 fedora37 postfix system using SSDs connected to a cable modem that's having problems with dropped packets. There is one other fedora37 server (E5-1650) directly connected to the cable modem that is not having the same problem, although it's just routing packets, not really doing much processing of data. The server with the problem is using libreswan to create a VPN between itself and an i7-7700K with fedora37 managed at OVH, thinking it would be more resilient than the cable connection itself. The problem also happens without the VPN, but perhaps not to the same degree. >> >> I think the server is certainly powerful enough to process the amount of DNS queries, but there's also a lot of timeouts. >> >> How do I troubleshoot this? It's the bridge experiencing the dropped packets, not the interface itself, it seems? >> >> They're not packet errors - just dropped packets. Perhaps the processor can't handle the traffic? >> >> Do you have a server connected to a cable modem? Is there something about it being a cable connection that could be causing this? >> >> There's about 27k dropped packets in about 12 hours of uptime. >> >> br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 >> inet 68.195.111.45 netmask 255.255.255.248 broadcast 68.195.111.47 >> ether ae:64:2c:25:b5:44 txqueuelen 1000 (Ethernet) >> RX packets 11355786 bytes 21634260431 (20.1 GiB) >> RX errors 0 dropped 26349 overruns 0 frame 0 >> TX packets 7374430 bytes 993860294 (947.8 MiB) >> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >> >> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 >> ether 14:da:e9:97:ab:72 txqueuelen 1000 (Ethernet) >> RX packets 16224042 bytes 22179550934 (20.6 GiB) >> RX errors 0 dropped 165 overruns 0 frame 0 >> TX packets 7493927 bytes 1031987928 (984.1 MiB) >> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >> device interrupt 17 memory 0xdf100000-df120000 >> >> Perhaps it’s not relevant in your case, >> But many of my colleagues have also problems with their cable modem. >> While turning it on, it claims it can handle an MTU of 1500 bytes, while in reality all above 1472 causes vague problems. >> This should have been handled through auto-probing of ICMP-protocol, but it isn’t. >> But your might be a different issue…. > > > Thanks so much for the thought. Just tried this, and the problem persists :-( > > Thanks, > Alex > > > > > _______________________________________________ > users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
