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