There are two, related proposals. Lets go through each carefully. First there's <swandefault>:
On Sat, 5 Sep 2020 at 19:47, Paul Wouters <[email protected]> wrote: > > On Fri, 4 Sep 2020, Andrew Cagney wrote: > > >>> this makes getting to the real domain and host much exier (OpenBSD > >>> is already using swandefault when NFS mounting /testing) > >> > >> But then eth0 is never used in tests ? > > > > OpenBSD is using its dedicated <swandefault> interface to directly NFS > > mount /testing. It doesn't need nic. We think it will work when > > there are multiple instances of obsde et.al. > > > > I don't see why we shouldn't make this pervasive, and use <interface>0 > > so it is memorable. > > 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? Based on the XML, OpenBSD's west has: 0: 192_1_2 1: 192_0_1 2: swandefault while linux's west has: 0: 192_0_1 1: 192_1_2 If we really are going to shoot for the holy grail where generic tests work with arbitrary OSs on east/west then I think well be better off having linux and bsd sharing a single machine definition. If nothing else it would fix what looks like a bug in the above, but would mean <swandefault> is present on linux systems. 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. > >> But we want east and west with eth0 in the same network and with eth1 not > >> on the same network ? > > > > So don't enable the network. It's one thing to have the network > > wired, another to have it enabled. > > I don't see the gain of breaking 700 test cases and their output just > for using a different interface in openbsd. Just let openbsd use a > new named interface ? What we're talking about here is a _natted_ bridge that multiple instances of obsde, say, can use to simultaneously access the host. This means the VMs do not, and cannot, have pre-assigned ethernet / ip addresses. And this is what <swandefault> provides. > > east 192_0_2 192_1_2 > > nic 192_1_2 192_1_3 swandefault > > north 192_0_3 192_1_3 > > openbsde 192_1_2 192_0_2 swandefault > > openbsdw 192_1_2 192_0_1 swandefault > > road 192_1_3 > > west 192_0_1 192_1_2 (this is the first time I've been able to reliably see how the interfaces are laid out) > > we could at least have east, west, and nic use the same interface for > > 192_1_2, for instance: > > 0: swandefault > > 1: 192_1_2 > > 2: the other interface > > 3: and more random interfaces > > But almost no test would use eth0. I'd rather stick to eth0 for machines > with "one real" interface, like road and north, and eth0 and eth1 for > west and east that have to have "two real" interfaces. 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. (speaking of which, why do east and west - our most common test exchange talk through the counter intuitive eth1 and not eth0?) 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 _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
