Re: xen networking

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

    Date:        Sat, 06 Jun 2020 07:33:55 -0400
    From:        Greg Troxel <gdt%lexort.com@localhost>
    Message-ID:  <rmipnacpgws.fsf%s1.lexort.com@localhost>

  | 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.

But we're not, brconfig simply uses ioctls to talk directly to the
bridge code - we know it isn't an external switch, it is a part of
the kernel.

What makes this even more sad, is the "create a tap0 and configure it
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.

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.

kre

ps: to make this slightly relevant to the original issue - I'd also
suggest not moving the mac addr from wm0 on the Dom0 to the DomU, but
the first thing I'd try would be asking whoever runs the service (and
the dhcp server) for a 2nd IP address (to be assigned to the mac addr you're
using as the router DomU).   Simply assuming that there will
only be 1 possible seems like it is unlikely to be true, your case is
unlikely tobe the first time anyone has made a setup where a system needs
more than a single address.

Alternatively, doing the NAT/router function in the Dom0 really should work.
(and definitely saves overheads, though it can reduce parallelism).