tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys/net



    Date:        Sun, 27 Sep 2020 19:16:28 +0000
    From:        "Roy Marples" <roy%netbsd.org@localhost>
    Message-ID:  <20200927191628.837A6FB28%cvs.NetBSD.org@localhost>

  | This ensures that Duplicate Address Detection for the joining interface
  | are performed across all members of the bridge.

This sounds like a good idea, but I believe it is breaking (or ignoring)
the oft stated design aim of the bridge interface, which is to emulate an
external bridge - not to emulate being one.

That's the justification for not allowing the local address for the
(combined) network to be configured on the bridge interface itself,
but to require that it be on one of the connected interfaces (or on a
tap or vether interface instead, so it remains if the selected real
interface goes down).

With an external bridge, unless the connection to the bridge is making
the link come up (ie: there was no carrier before), the interface will
not redo DAD just because its link has become attached to a bridge,
however appealing it might be if that were to happen.   (If the interface
had no carrier, was down, before being attached to the bridge, then when
it comes up it will do DAD in the normal way).

If we're giving up on the "external bridge" model (even partially) then
we should give up on the "no addresses on the bridge interface" as well,
and so remove the need for a tap/vether interface to be connected to the
bridge fpr the sole purpose of holding a stable address.

kre

ps: Was the change to the tap interface, which makes it no longer work as
the bridge address holder discussed anywhere?   That one sounds like it
is likely to break people's configurations.



Home | Main Index | Thread Index | Old Index