pengrus Posted April 18, 2021 Share Posted April 18, 2021 So my logs started filling up with these messages a few weeks ago. At first, it didn't seem to be causing any problems, but then my DHCP server (hosted off unRAID) started borking all the wifi clients, and BIND9 (also hosted off unRAID) started having issues. This was followed by the wired clients getting borked as well, so now almost everything is statically assigned and at least relatively stable. Think I've got that if not fixed, then worked around, but these messages remain, and are reminiscent of an ARP storm, aren't they? The messages persist even when the array is stopped, with no Dockers or VMs running. I did update to 6.9.2 yesterday, no change. System is dual E-5 2690s on an X9DR3-F. Board has two NICs, but I'm only using one on a static IP, so I don't think it's an STP issue. I am experiencing a great deal of lag and slowness both from wired and wifi media clients, as well as a remarkable delay in accessing pages like the plugins for the webUI. The Dashboard is fine though. Diagnostics attached, thanks in advance! -P tower-diagnostics-20210418-1441.zip Quote Link to comment
pengrus Posted April 23, 2021 Author Share Posted April 23, 2021 (edited) Ok, so near as I can figure from a Wireshark run, this appears to be ARP requests from the server's IP to Docker containers and VMs it's already hosting. Can anyone give me an idea how to fix this? Also, I can no longer access the plugins page at all, it just does that wave thing until it gets tired and stops. Edited April 23, 2021 by pengrus Quote Link to comment
pengrus Posted April 25, 2021 Author Share Posted April 25, 2021 An update! This is actually pretty interesting (and also frustrating), and I'm surprised no one else has had this issue, but I think I've found the cause. I run a pihole Docker on .40, and used to run (now decommissioned to reduce complexity) a SteamCacheBundle Docker on .44. Based on the rather unscientific procedure of having a terminal window tailing syslog while Wireshark runs, it seems pretty solid that ARP requests from the server to its Dockers is the cause of the entries, because the Dockers don't respond. "Who has x.x.x.40? Tell x.x.x.unraidIP." This repeats every second or so for about 7 minutes, takes a 5 minute break, then starts again. Glad I increased the log partition size... But why is it asking? I think it's because, since the server has a static IP, the network settings list the pihole and steamcache as its primary and secondary DNS entries. This would also explain why it continues happening even when Docker and VMs are shut down, or the array is stopped. On to a solution! I can probably scrounge up an actual Raspberry Pi, throw pihole on it, shut down the Dockers and call it worked around. But I feel like there's a bug here somewhere, either in unRAID's network settings, the Dockers, or something I introduced. There are other Dockers using br0, namely a Nextcloud instance and its MariaDB, as well as the unifi-controller, but those aren't seeing traffic from the server itself, at least in my testing. Any suggestions would be appreciated! -P Quote Link to comment
Vr2Io Posted April 25, 2021 Share Posted April 25, 2021 (edited) Not understand the fouding/conclusion. I setup pihole docker and sometimes will stop it due to maintainance. Then DNS resolve fail is normal. But this never affect local network (DHCP provide by router). . Unraid and Pihole have own IP address and MAC address . How come a unreachable DNS server will cause local network down. . Mass APR traffic found in a network also normal. As error state "own address as source addree", so are you capture that packet ? * I don't know anything about steamcach and I have Fing box in network to continue detect whole subnet all IP, so ARP traffic abnormal high but still no issue * Edited April 25, 2021 by Vr2Io Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.