I have a Linux device (Raspberry Pi/Ubuntu) that I am using as a network bridge between a physical eth0 network interface and a virtual tap0 interface. On boot, the device stands up br0 which consumes eth0 automatically. A system service (call it serviceA) then runs that creates and manages a tap0 interface. The tap0 interface is also automatically consumed by br0. I need this device to also be addressable directly over IP, so I have given br0 a static IP address. All of this works (using systemd-networkd configuration files to manage the interface properties). As expected, I can SSH etc. onto the device using the IP of br0.
Whenever I stop serviceA (for example to tweak some configuration settings of the service before starting it again), it automatically destroys tap0 (this is expected). What I did not expect was for the device to no longer respond to IP of br0.
Example: From a host machine plugged into eth0 of the device, with serviceA running, I can SSH onto the device. Running systemctl stop serviceA makes my SSH session unresponsive. Plugging a keyboard and mouse into the device shows that the service stopped cleanly, and it is in the state that I would expect, but if serviceA is stopped (i.e. tap0 does not exist), I cannot SSH onto the device using the IP address of br0. Possibly of note: even if tap0 is down, I can ping <IP of br0> just fine, and the device receives requests from curl (but does not respond to them).
Question #1: Should I expect a network bridge with exactly 1 network interface and a static IP address to respond to that IP address? Obviously it won’t do any actual bridging, but I was expecting the device to still be addressable with that IP.
Question #2: If the answer to the first question is yes (I hope it is), any hypotheses for what could be going wrong? I’ll happily blame any part of this networking configuration, including, but not limited to, IP routing/subnets on the host/device.
