Re: CVS commit: src/sys/net

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 1 Oct 2020 08:46:56 +0100
    From:        Roy Marples <roy%marples.name@localhost>
    Message-ID:  <74c16ff9-ec57-410c-27b6-8edeb60b0256%marples.name@localhost>

  | Then we loose the ability to have a virtual network yes?
  | server -> vether0 -> bridge0 -> vether1 -> client

No, why would you?   If that's what you want to configure, then
configure it that way.   The aim is flexibility, with minimum
restrictions.

Nothing of what I've been saying has anything to do with the addition
of the vether interface to the system, that's fine - the closest
comment to that was on the change to the way the tap interface works
once vether was able to replace it as a bridge address hanging interface.

You'd still be able to bridge together as many interfaces (real or virtual)
as the bridge code can handle (probably no real limit, other than what
performance dictates, but I have never been tempted to go beyond a few,
so I'm not sure).   The only difference in what I'm suggesting is that
you'd be able to, if you desired, configure L3 addresses on the bridge
interface, as well as elsewhere - for the diagram above you probably
wouldn't need, or want, to do that.

  | If we change to the model
  | server -> bridge_ether0 -> client

I'm not sure how that would work, no matter what bridge allows.

kre