Comment 2 for bug 1655224

To address why I think this happens.

In most deployments, there is a local-only 'lxdbr0' bridge, that often gets an unroutable address (10.0.0.1, for example). There is a similar issue for 'virbr0' which always gets 192.168.122.1 (or something very similar to that).

When Juju introspects the machine to find out what addresses it should advertise to the outside world, we intentionally filter out those addresses, because for most people they are concretely wrong, and actually actively harmful. (Specifically for 'virbr0' because it always gets the same 192.168.122.1 address, that means that if you install 'libvirt' on your laptop and it is installed on the remote machine, *both* machines have a valid 192.168.122.1 address, but they are most definitely not the same.)

In the case of 'lxdbr0' we run into a similar issue. The default rules for IP address ranges that Juju assigns exacerbate this (we default to 10.0.0.X for lxdbr0, which is a different bug.)

I have the feeling that in your case, you are changing lxdbr0 to put 'eth0' onto the lxdbr0 bridge, which means the *bridge* device no longer has a '.1' address, but lxdbr0 now actually has the remotely assigned address that eth0 used to have. Which means that we're now filtering one of the addresses that the host machine *was* using for things in the outside world to talk to it. And especially if you only have one network interface (ie, no eth1/ens4/etc), then there is no other address that we could associate and have the containers find us. (And even if we have an eth1, it may be intentional that the address that containers that are attached to eth0 can't route to the address on eth1).

For now, the answer is to not use lxdbr0 for the name of a bridge that you want connected to the host network. Our standard convention is to use "br-DEVICENAME", so "br-eth0" or "br-ens3".