Re: xen networking (offtopic)

[Dima Veselov <kab00m%lich.phys.spbu.ru@localhost>]

On Sat, Jun 06, 2020 at 10:32:18PM +0700, Robert Elz wrote:
>  | I think it's good that you can't put an address on a bridge.  Ethernet
>  | switches do not have addresses (except for management).   So create a
>  | tap0 and configure it with an address and put it in the bridge.
>
> I've never understood this reasoning.   I understand the intended
> model - no IP address is needed for operating a switch (it is all
> L2 functionality) but that qualification "except for management"
> gets in the way, as a switch needs management - unless it is to
> be configured via a com port or similar, which would be bizarre for
> networking equipment, there needs to be a way to communicate with
> it, and other than what is possible with some IEEE L2 management
> protocol (not a lot) that means it must have a network address.
>
> This might be different if bridge(4) actually implemented an old
> fashioned bridge/hub type function, but it doesn't, it implements
> a much more modern (and useful) switch function instead.
>
> In netbsd, if we were faithful to the model, of a bridge interface
> emulating an external switch, to which we just happen to be connected,
> then we'd need it to have an IP address in order for brconfig to be
> able to communicate with it, to configure it.

Sorry for off-topic but I always wondered why NetBSD network card
is able to talk to others on same bridge? I am asking because in Linux
if you assign an IP to interface - it won't and explanation is fare enough:
bridge code is "listening" for interface input and put packets in 
interface output queue, therefore if kernel TCP/IP stack inserts packet
to eth0 it goes straight on the wire. So you have to assign IP to virtual 
br0 interface instead and then any packet from host will go into bridge
code and bridge decide where it goes.

That costs - real host is connected to real network through device
which can take time to raise (because of STP, learning, etc). NetBSD do not
have this problem, but that also means processing differs between putting
packet into wm0 and into wm0 with bridge on it, because packet going through
bridge should not appear on the wire.

And that confuse me - we do switching, but it seem to be different for VM
and for real host. 

> with an address ..." advice, which is actually the right way to run
> a bridge in the netbsd model.   We could (and if we were faithfully
> following the model, would) assign the address using one of the real
> (physical or virtual) interfaces that are connected to the bridge - we
> don't want to do that, as things then break badly if that particular
> interface goes down while all the others remain up, and should be able
> to keep functioning, ignoring the dead one ... but we can't as when the
> blessed interface fails, we lose all network level config (including
> the addr).   The "use a tap" (obviously doesn't have to be tap0)
> pseudo interface simply provides a bridge connected interface which
> will never go down (it is never actually connected to anything) on
> which to hang the IP configuration.

I don't fully understand mechanics of intercepting packets from output queue
of network card, but from the user side of big virtualization system I find
much more appropriate to have an IP address on br0 and living switch when wm0
fail even if it cost me some time of raising it.

> A better solution would be to include this notional tap (or as much
> of it as is needed - which is really almost nothing of the tap interface)
> as part of the bridge interface (and really, it is almost all there
> already) since we know we need this info, always, to be useful (no-one
> runs pure L2 switches on NetBSD that I'm aware of - the NetBSD system
> is always connected to it at the L3 level, somehow) which would vastly
> simplify the model.

> A bridge interface would be the logical interface (acting as the tap
> in current configs) for the network of switched links, and would provide
> the stable connection point that the tap interface would no longer be
> required for (reducing complexity and overheads) and making a model
> that perhaps is not quite as "pure" as the current netbsd bridge model,
> is much closer to the way most other systems which implement switches
> (eg: cisco, etc ... not just linux) work, and so more familiar to most
> users / network managers.

Totally agree, because there should be straight way to create bridge
with no (or not working) real interface where anyone is able to interact
with host holding the bridge.

--
Sincerely yours,
Dima Veselov
Physics R&D Establishment of Saint-Petersburg University