[Bug 221122] Attatching vxlan interfaces to a bridge stops all traffic on it

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122

Heinz N. Gies <heinz at project-fifo.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|Works As Intended           |---
             Status|Closed                      |Open

--- Comment #4 from Heinz N. Gies <heinz at project-fifo.net> ---
I understand that it acts as implemented i.e. is not a code bug. Before we
close this I'd like to make a case that is not working as intended but rather
working as accepted.

The VNET system is rather new in FreeBSD, bridges, on the other hand, exist for
a lot longer.

Historically bridges were used in a rather static manner, to bridge physical
interfaces (they don't change often), or bridge between physical interfaces and
tunnels or other virtual but too rather static interfaces.

This kind of use is often a one-time configuration that happens on system
startup or in the case of tunnels in an incredibly rare basis. At those times
the loss of connectivity for a few seconds either has no impact (during
startup), or the impact is neglectable (i.e. adding tunnel interfaces as no one
is connected to a nonexisting interface anyway).

I suspect that when the decision was made to implement it this way all that was
taken into consideration and (rightfully so) it wasn't worth the work for
finding an alternative as it was working good enough for its use.

VNET and more so VNET jails change things a bit, they make network
configuration more dynamic. It becomes required to add and remove interfaces to
a bridge dynamically - something that I suspect wasn't foreseen.

Features do not exist in a void, they exist in relation to their environment.
The environment for bridges changed and while it was fine before it becomes
problematic in this changed environment.

I agree it's not a 'bug' in the bridge driver. But we can not look at a single
component in isolation and on a system level, I'm sure that 'starting/stopping
a vnet jail means all other vnet jails loose connectivity' is intended
behavior.

-- 
You are receiving this mail because:
You are the assignee for the bug.