TL;DR: Is there a way to force a bridge to forward anything and
everything on all ports (except the ingress port) *regardles* of
any permanent FDB entries (such as the MAC addresses of interfaces
acting as bridge ports)?
For context, I'm using a network-namespace (container) based simulator
(think GNS3 or CORE), which allow me to run multiple FRR instances
in their own dedicated netns, connected together by veth pairs and
bridges.
To bridge this simulation outside the machine hosting it, the
simulators allow host machine interfaces to be bridged to bridges
and veth pairs that belong to the simulation, e.g.:
-----------------------------
VM running simulation |
|
sim. node, |
(container), |
dflt gateway |
----------- - br0 - | -----------------
| / \ | inter-VM | External VM |
eth0 + veth0 ens32 +-- vswitch --+ using in-sim |
Sim.MAC | VM.MAC | | dflt. gateway |
----------- | -----------------
-----------------------------
This requires the vswitch outside of the vm hosting the simulation to
allow promiscuous mode (so that containers can send/receive Ethernet
frames through the hosting VM's interface (e.g., ens32).
It turns out that at least on one "cloudy" hosted solution the guest
VMs are forbidden from sending "spoofed" ethernet traffic, i.e. the
ens32 "vm.mac" address is strictly enforced outside the VM (on the
inter-vm vswitch).
The obvious solution would be to assign ens32's VM.MAC as the mac
address of eth0 inside the container, which would allow it to talk
on the ethernet broadcast domain bridged via br0 and the inter-vm
vswitch (assuming we only have *one* such container on the "inside").
Trouble is, br0 won't forward frames *to* VM.MAC received from
external sources, since that is a permanent FDB entry associated
with the "ingress interface".
I'm looking to turn br0 into a "dumb hub". Typically, the closest
approximation to "hub behavior" is accomplished by disabling MAC
learning on the bridge interface(s), which will force permanent
flooding.
Turns out, the exception to that is if a mac address associated with
one of the bridge ports is involved -- no "hub" behavior in that case,
because those FDB entries aren't learned, but rather permanently
installed during bridge set-up.
Any way to override that (and ignore permanent FDB) entries would save
me a lot of effort to "hack" my way around this restriction using
multiple bridges and ebtables NAT :)
Thanks for any clue, pointers, or advice.
--Gabriel
