lbob

Thank you so much for all your help. I really appreciate you taking your time. I will give this a go when I have some time and mark it as solved if I get it all working.

Thank you for taking your time, and thanks for the detailed list. Answers below, then a separate section with a new finding. 1. Where is everything connected? Pi-hole: OpenWrt LAN port 1 (lan1). Zyxel: OpenWrt LAN port 2 (lan2), via Zyxel port 8. Unraid is on Zyxel port 7. My PC: Wi-Fi (OpenWrt’s own radio). The ARP/ICMP capture with -e was run on the Pi (eth0). 2. Ping Unraid from the PC and from OpenWrt From my PC during a failure: 368 sent, 368 received, 0% loss (avg 2.4 ms). From OpenWrt uring a failure: Same as above 3. Captures Pi-side, during a failure (tcpdump -p -nn -e -i eth0 'host 192.168.0.190 and (arp or icmp)', 45 s): 08:54:27: the Pi pings Unraid and gets a reply. From 08:54:30 on, its pings to Unraid get no reply. 08:54:36-38: the Pi’s unicast ARP requests to Unraid’s MAC get no reply. 08:54:41: the Pi’s broadcast ARP request is answered by Unraid at once. Unraid’s pings to the Pi arrive and the Pi replies every time. At 08:55:01-03, Unraid sends the same unicast ARP request three times and the Pi answers each time, so the Pi’s replies don’t reach Unraid. So unicast frames from the Pi to Unraid’s MAC are lost, while broadcasts and everything from Unraid to the Pi arrive. 4. OpenWrt bridge fdb and config The fdb result is in the section below. ip neigh on OpenWrt shows both machines as REACHABLE in both states. The relevant parts of /etc/config/network (there is no VLAN filtering): config device option name 'br-lan' option type 'bridge' list ports 'lan1' list ports 'lan2' list ports 'lan3' config device option type '8021q' option ifname 'lan2' option vid '30' option name 'lan2.30' option ipv6 '0' config interface 'dmz' option proto 'static' option device 'br_dmz' option ipaddr '192.168.30.1' option netmask '255.255.255.0' config device option type 'bridge' option name 'br_dmz' list ports 'lan2.30' option bridge_empty '1' option ipv6 '0'(lan2.11 is another VLAN, in its own bridge br_iot.) Router model and ubus call system board: 5. Test container on br0.30 Not done yet. The finding below suggests any ipvlan container on br0.30 would do the same, since it shares the host’s MAC. 6. Zyxel MAC table / loop prevention Not checked yet. New finding: OpenWrt’s switch table moves Unraid’s MAC to VLAN 30 when ABS starts/someone interacts with. I compared bridge fdb show | grep -i a0:36:bc:a9:a1:a9 (Unraid’s MAC) on OpenWrt in the two states. The Pi’s MAC (d8:3a:dd:b1:df:8a) stays on lan1 in both. When the Pi-hole can reach Unraid: a0:36:bc:a9:a1:a9 dev lan2 master br-lan a0:36:bc:a9:a1:a9 dev lan2 selfWhen it can’t: a0:36:bc:a9:a1:a9 dev lan2 master br-lan a0:36:bc:a9:a1:a9 dev lan2.30 offload master br_dmzThen I ran a watcher that prints only when Unraid’s entries change, and started ABS on br0.30: == 10:29:25 a0:36:bc:a9:a1:a9 dev lan2 master br-lan a0:36:bc:a9:a1:a9 dev lan2 self == 10:29:38 <- ABS started a0:36:bc:a9:a1:a9 dev lan2 master br-lan a0:36:bc:a9:a1:a9 dev lan2.30 offload master br_dmzThe lan2 self entry disappears and the MAC moves to lan2.30 in br_dmz. The second state is identical to what I captured while the Pi-hole couldn’t reach Unraid. My reading, which I haven’t proven further: the ipvlan container shares Unraid’s MAC, so the router’s switch chip learns that MAC on VLAN 30 as well, and unicast frames from other devices to Unraid’s MAC no longer reach it, while broadcasts still do. That matches the captures above. Have I understood correctly that MACVLAN will sorts this out? If yes,would you recommend switch to MACVLAN or rather changing the OpenWrt side (a single br-lan with VLAN filtering instead of lan2.30 in a separate bridge)?

1. Pi-hole Query Log / FTL.log sudo grep -i "rate-limit" /var/log/pihole/FTL.log returns nothing. I ran tcpdump -ni eth0 host <192.168.0.190> and port 53 on the Pi at the start of a failure. About 19 queries in 5.6 s (roughly 200 per minute). Each query gets an answer within 1-2 ms, and none is REFUSED. Example: 20:22:09.602997 IP <Unraid>.46051 > <Pi-hole>.53: 13185+ A? ljud.<my site>. 20:22:09.603589 IP <Pi-hole>.53 > <Unraid>.46051: 13185 1/0/0 A <VPS IP> 20:22:10.241427 IP <Unraid>.33327 > <Pi-hole>.53: 3931+ [1au] A? google.com. 20:22:10.242781 IP <Pi-hole>.53 > <Unraid>.33327: 3931 6/0/1 A 64.233.161.139, ...Some queries repeat with the same ID a few seconds apart (for example 13185 at :09.6, :13.6 and :14.6), which looks like retransmission. The Pi’s own ICMP echo requests to Unraid (20:22:12 and 20:22:15) show no echo reply in the capture. 2. Commands on Unraid during the problem dig @192.168.0.165 google.com: ;; communications error to 192.168.0.165#53: timed out ;; communications error to 192.168.0.165#53: timed out ;; communications error to 192.168.0.165#53: timed out ; <<>> DiG 9.20.22 <<>> @192.168.0.165 google.com ; (1 server found) ;; global options: +cmd ;; no servers could be reachedSo it times out, not REFUSED. dig @9.9.9.9 google.com: works, status: NOERROR, query time 7 msec. ping -c 10 192.168.0.165: 10 transmitted, 0 received, +3 errors, 100% loss. The errors are “Destination Host Unreachable” and come from the Unraid IP itself (icmp_seq 4-6). /etc/resolv.conf: three identical lines, nameserver 192.168.0.165. Taken at the same time: load 0.29, 88% idle, 5% wait, conntrack count 354 of 262144. My watch loop (ping + dig to the Pi-hole every 5 s) shows ip neigh staying REACHABLE when it starts: all ok at 20:21:57, ping and dig both FAIL at 20:22:02. 3. Does anything refer to ABS by name or its old bridge IP/port? NPM forwards ljud.<my site> to 192.168.30.11:80. It was recreated without the old ABS network, and it is not on br0.30. With NPM stopped (compose down), ping and dig to the Pi-hole still failed. I did and got the following during the lag: tcpdump -ni eth0 'arp and host 192.168.0.190' Respone: 20:07:53.051314 ARP, Request who-has 192.168.0.190 tell 192.168.0.165 20:07:54.075315 ARP, Request who-has 192.168.0.190 tell 192.168.0.165 20:07:55.099301 ARP, Request who-has 192.168.0.190 tell 192.168.0.165 ... 20:08:06.011242 ARP, Reply 192.168.0.190 is-at a0:36:bc:a9:a1:a9 I sent you my .zip file privately if thats OK.

Thanks, this helped a lot. The NOTRACK rule fixed it. A bridge container now gets 200 from the container on br0.30, where it was 000 before. I’m adding the rule to /boot/config/go. 1. Which container, and does it connect back to bridge containers? It’s Audiobookshelf, a media server, not a reverse proxy. This is the compose file: yaml services: audiobookshelf: container_name: audiobookshelf image: ghcr.io/advplyr/audiobookshelf:latest user: "99:100" restart: unless-stopped volumes: - /mnt/user/data/media/audiobooks:/audiobooks - /mnt/user/data/media/books:/books - /mnt/user/appdata/audiobookshelf/config:/config - /mnt/user/appdata/audiobookshelf/metadata:/metadata environment: - TZ=Europe/Stockholm dns: - 9.9.9.9 - 1.1.1.1 networks: dmz: ipv4_address: 192.168.30.11 networks: dmz: external: true name: br0.302. Does the Pi-hole restart, and where do the alerts come from? The alerts come from Uptime Kuma (I said Upsnap earlier, that was wrong, sorry), which runs on the Unraid server. The Pi-hole monitor is a DNS check (A query for google.com against 192.168.0.165, port 53), and the error is queryA ETIMEOUT. A continuous ping from my PC to the Pi-hole shows no gaps. The Kuma monitors for the Unraid WebUI and OpenWrt never go down. I ran dig +time=2 +tries=1 @192.168.0.165 google.com in a loop (every 5 seconds) on both machines. My Fedora PC printed no failures. Unraid failed on every attempt (6 in a row, 21:15:51 to 21:16:26), and these failures happened while Unraid was lagging. So the Pi-hole’s DNS answers my PC while Unraid’s queries to it time out, which matches the Kuma alerts. 3. With NOTRACK applied and ABS on br0.30, does the lag still happen? Yes, the lag still happens with the NOTRACK rule active, so that rule doesn’t affect it. The lag stops when I remove ABS from br0.30 (either compose down, or moving it back to its old bridge network), and Unraid and Docker are normal and fast again at once. A top snapshot shows nothing out of the ordinary.

I recently purchased a switch which supports VLAN tagging so I decided to try to isolate my internet-facing containers to secure it up even further. But I am struggling with some unexpected issues and looking for help. I have tried looking for the answer on the OpenWRT community without success. I have tried sending my logs to Claude but without success there as well. I'm now asking here if I have misconfigurated something on Unraid. I have tried to summarize as much as possible. Setup Unraid (v. 7.3.0), one NIC (eth0). Bonding is enabled but bond0 has only eth0 in it (active-backup). Bridging is on (br0). VLAN 30 is added in Network Settings with IPv4 set to None, so the host has no address on it (br0.30 and bond0.30 are UP with no IP). Docker custom network type: ipvlan. Network br0.30 created with subnet 192.168.30.0/24, gateway 192.168.30.1, range 192.168.30.128/25. “Preserve user defined networks” is on. Containers get fixed IPs (Example = 192.168.30.11). Switch (Zyxel GS1200-8HPv3): Unraid port is VLAN 1 untagged, VLAN 30 tagged, PVID 1. Uplink to OpenWrt (lan2) carries VLAN 1 untagged and VLANs 11 and 30 tagged. OpenWrt: lan2.30 device, interface 192.168.30.1/24 (no DHCP), zone dmz with input/forward reject, forwarding dmz → wan and lan → dmz. First problem: bridge containers can’t reach the VLAN containers My PC and the Unraid host both get 200 from http://192.168.30.11. Containers on any Docker bridge network (docker0, authentik_default) time out. A container with --network host gets 200. OpenWrt tcpdump on lan2.30: SYN goes out from 192.168.0.190:57068, but the SYN-ACK from container comes back to 192.168.0.190:29489, a different port, and Unraid then sends a RST. Conntrack on Unraid shows two [UNREPLIED] entries per attempt. So the source port is rewritten somewhere on Unraid, after OpenWrt, on the path Unraid → router → back into Unraid via VLAN 30. Already ruled out: rp_filter is 0 everywhere, DOCKER-USER is empty, and raw/DOCKER-FORWARD have no rules for 192.168.30.0/24. Problem two: lag and Pi-hole restarts With container on br0.30, Unraid and Docker become slow, and Upsnap reports my Pi-hole (a separate Raspberry Pi, 192.168.0.165) going offline and coming back. docker compose down on container makes everything normal at once. After moving container back to its old bridge network, the lag and the Pi-hole restarts stopped. Questions Why does traffic from bridge containers to an ipvlan container on the same host get its source port rewritten, and how do I make it work (or is this unsupported)? Could a container on an ipvlan child of br0.30 cause a MAC/FDB flap or loop that disrupts other devices on the LAN (like the Pi-hole)? What should I check on the switch and router? Is it better to use macvlan, a second NIC with an untagged DMZ port, or a different design for this? Thanks!

Thank you. And I guess the option "Enable Manual Configuration:" should be Yes when adding something to the config? When changing to yes a lot of options disappear from the GUI, that's why I am asking. Also, can I use Peanut (https://github.com/Brandawg93/PeaNUT) together with the NUT instance and show it on my Homepage instance? Or do you recommend anything else?

Sorry to bump an old thread like this but I'm having the same problem on a new BX ups. Is this still the solution to these error messages?

Is there an old image of readarr that we can use? I wanted to use the last release before retirement to match it up with rreading-glasses. Havent found it anywhere..

Thank you

Doing my first pre-clear. What settings are recommended to use? When choosing "Clear Disk" I'm able to choose 1-3 cycles. When choosing "Erase and Clear Disk", theres no option for cycles. The disk is brand new. Thanks