Re: CVS commit: src/sys/net

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

    Date:        Mon, 28 Sep 2020 03:12:00 +0100
    From:        Roy Marples <roy%marples.name@localhost>
    Message-ID:  <6ab8c52e-9524-c777-d0fa-ec39fc691d75%marples.name@localhost>

  | I have no idea what this "oft stated design aim of the bridge interface" is.
  | Where is this documented?

Hunt the mailing lists for queries about bridge config, where people have
tried to config an IP addr on bridge0 and had it not work, and asked why.

That's the answer that's always given.

  | Also, what is this difference between an external bridge vs being one?
  | A bridge is a bridge, virtual or otherwise.

I think I agree, but then I've always believed that it should be
possible to config addrs on bridge interfaces, rather than the
nonsense of requiring a tap (or now vether) interface in addition
to whatever other (packet transmitting) interfaces are actually
attached.

What would you think about making a vbridge interface (or some name
like that) that would be a combined bridge and vether in one driver?
And simply not giving the vether a name (or an actual attachment) ...


  | You're reading far too much into this.
  | Let's break it down to brass tacks.
  |
  | The bridge is a glory hole.
  | Should it try to protect it's members identities (local addresses) or not?

No.   How can it?   It is the member's job to protect their identities,
not the network infrastructure.  That's all it can possibly be, bridges
and hubs ae (supposedly) dumb L2 devices that know nothing about the
network layer protocols that sit above them.   Some bridges know that
most traffic they see is IP, and attempt to optomise that (sending
frames only to the link where the destination is known to be ...) but
that's always done in the failsafe way, where packets for unknown
destinations are sent everywhere, so the presence of the bridge is 
undetectable.

  | Now that you mention it though, the whole link should be taken down
  | on bridge join (and then link state restored). It's the only way to be sure.
  | Some might view as too agressive.

Some might, probably most might, but even if not, that is not enough.

I quite often use a dumb hub for link splitting - those things tend not
to pass on lost carrier on one link to other links (if they did they'd
never work when not all ports were connected to powered up devices).

It is simply impossible to actually achieve what you'd like to do,
there never has been a way to ensure that there's no address duplication
(even doing DAD on a fully connected link does not promise that, as a
reply packet might be lost/corrupted - even perhaps several times if the
owner of the about to be duplicated addr is on the wrong side of a
poor physical connection).

kre