On Mon, 7 Sep 2020 at 12:09, Paul Wouters <[email protected]> wrote: > > On Sat, 5 Sep 2020, Andrew Cagney wrote: > > >> We removed the extra unused interfaces a few years ago that were in > >> 192.1.9.0/24. Those were eth2 and could be used but never were. Except > >> on nic where it can hook up to the real internet. > > > > (Hm, what's 192.1.9.0/24? Perhaps you ment 192.1.4.0/24 which seems unused? > > No it was 192.1.9 i believe. But it was removed like two years ago along > with the unused eth2's on most machines.
So what is, or was 192.1.4.0/24? > > This leads to the second reason for adding <swandefault>. Currently, > > for east et.al. to get access to the real world it needs to go through > > hoops. NIC needs to be up and re-configured; east's routing tables > > need to be fixed, ... All secret sauce that no one can quite remember > > how to get working. Having direct access to <swandefault> NAT should > > simplify all that. > > The "hoop" was "fire up nic and run /testing/guestbin/nic-internet" until > it got broken :) > > It was pretty simple and since every machines routes default gw through > nic, it only requires a single custom interface on nic. ... DNS would need configuring for instance, anything else? > > What we're talking about here is a _natted_ bridge that multiple > > instances of obsde, say, can use to simultaneously access the host. > > Until now, all test cases are run in isolation. Hooking up the virtual > networks together so in theory test cases can affect each other seems > unwise? I don't understand. Each test group still uses a dedicated and isolated network. That hasn't changed. The swandefault network, unless it is misconfigured, should be isolating any attached domains - all each domain can see is the host (we've already got nic on the swandefault network without problems?). > > This means the VMs do not, and cannot, have pre-assigned ethernet / ip > > addresses. And this is what <swandefault> provides. > > nic's eth2 is connected to the host libvirt dhcp and you can already > have multiple of those at once (although having "uplink" for test > machines should really be a manual human action and not a regular > occurance or else having internet becomes a requirement to run tests, > which it currently is not. We even run shadow DNS for a number of > zones to avoid needing real world internt. > > > Now we get to renumbering/renaming. If you really think eth0 should > > be a real interface, then <swandefault> can go last - knowing the last > > interface is always the NAT is almost as easy as knowing it is the > > first. > > That would be better than being the first. Although my preference would > still be to use nic for this and not add another network to all virtual > machines and namespaces. So all openbsd tests need to boot NIC and use it as a GW to route NFS traffic. Ewww. > > (speaking of which, why do east and west - our most common test > > exchange talk through the counter intuitive eth1 and not eth0?) > > I don't know. It goes back to the uml days. Same as why it uses > 192.1.2. 23 and 45 and not 1 or 2 or 3. > > > Two things to keep in mind: > > > > - shuffling interfaces is incremental > > one domain at a time (and personally I don't tend to push changes > > affecting all test output without updating the output first) > > - updating is transparent: > > gmake kvm-clean kvm-install kvm-test > > rebuilds all the test VMs and their interfaces already > > I'm more concerned about keeping it managable to have kvm and namespaces > produce the same output. Adding interfaces will just make that a little > harder. Having something unique for just the openbsd machines seems the > least painful now. > > Paul _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
