Why the physical interface attached to bridge, it can not access by Internet in my case?

Question

I have a network topology like this:

you see, the em1(1.1.8.209) is physical interface which I can communicate through Internet. and I created two vm instance: PID 8740 and PID 8817, both use the network IP1.1.8.210/29 and 1.1.8.211/29, both Public IP addresses.

now I can communicate with em1 through Internet.

but I have a requirement, I want access the two VMs directly, so I want to attach em1 to br0.

then I executed this:

brctl addif br0 em1

the topology become this:

however, after I executed this command, I get error, I cannot communicate to 1.1.8.209 any more. then I deleted the attachment brctl delif br0 em1, then I can access 1.1.8.209 now.

Why I get this issue? I don't understand, please help to explain why.

Answer 1

When the interface becomes a bridge port, it's not participating in routing anymore.

The low level details are described in this blog Proper isolation of a Linux bridge:

5. hand over the frame to a global or device-specific protocol handler (e.g. IPv4, ARP, IPv6).

   For a bridged interface, the kernel has configured a device-specific receive handler, br_handle_frame(). This function won’t allow any additional processing in the context of the incoming interface, except for STP and LLDP frames or if “brouting” is enabled. Therefore, the protocol handlers are never executed in this case.

Such bridge port's IP address becomes irrelevant for the incoming packet. Leaving it set where it is can still disrupt proper routing for outgoing packets, because those can still be sent through the bridge port directly (when they shouldn't anymore).

What must be done is move the IP address to either a system (or network namespace, or even a veth pair's other free end in the same place) having its other end connected to the bridge, or the bridge's self port, ie the bridge itself. There will always be a small time window where disruption will exist during this move, so actions done locally to change this configuration must not depend on network access (eg: must not depend on typing commands remotely through a shell using the disrupted route).

I'll use only newer tools with newer syntax below.

For example:

ip address flush dev em1
ip address add 1.1.8.209/29 dev br0

Instead, an other way leaving the bridge not participating in routing and using an extra veth pair's end (in the same network namespace) to participate in routing could be:

ip address flush dev em1
ip link add name em1twin type veth peer name br0portem1twin
ip link set br0portem1twin master br0 up
ip link set em1twin up
ip address add 1.1.8.209/29 dev em1twin

In both cases, if a default route (or other routes) depended in the existence of this address, this route must also be added again, because it disappeared.