Bring up OpenVPN tunnels between CMU Lab and ProtoGENI

[hdempsey@bbn.com]

Dave Andersen to provide revised date for when GRE tunnels will be established between ProtoGENI and CMU Lab.

[Aaron Falk]

Dave on Jan 15:

If you don't mind me giving a conservative estimate, let's say three weeks on GRE tunneling.

I.e., expected complete date: Feb 6, 2009

[Aaron Falk]

Dave on 1/16:

To provide a roughly more accurate answer to the GRE milestone update: Now that our update is complete, the Utah folks are having other sites update to the CVS HEAD of the ProtoGENI code on Monday, and then they'll be starting to activate the GRE tunnels.

I'm not sure how long that process will take, but "it's underway".

[Aaron Falk]

Dave on 2/2:

update to -HEAD ProtoGENI code is complete and now happy; tunnels are pending Utah activating them

So, owner of this ticket changes to Ricci.

[ricci@cs.utah.edu]

We've made significant progress on getting GRE tunnels working, just need to finish it up. Will be done by Leigh Stoller, hence the owner change.

[Leigh Stoller]

GRE tunnels are now working between federates and in fact have been demonstrated. Utah is currently waiting on CMU to install the ProtoGeni code on their Emulab and join the federation so that GRE tunnels can be constructed between their Emulab and others in the federation.

[pgunn@cs.cmu.edu]

GRE tunnels do not work when a testbed's nodes do not have public IP addresses - there's no way for them to talk to foreign testbeds. This type of federation will take a different approach.

I am mostly done with a piece of software (which I am calling metavpn) that wraps OpenVPN to dynamically create/configure/manage/teardown a per-network layer2 VPN within a testbed - when this type of federation is necessary, networks in an experiment will be composed of one OpenVPN instance in each private testbed plus another OpenVPN instance to glue together each such testbed. Right now this will run on ops, although if/as it scales upwards, we should be prepared to move it to a dedicated vpn server (or a pool of them).

When metavpn is done, two more bits of work will be done: 1) Clients must be told to fetch an OpenVPN config and use it (and later to stop doing so and remove it). This code largely exists (for the homenet controlplane I have to do a reasonable subset of this) but will need refinement. 2) snmpit/control framework integration. I will likely neet help from Utah on this (or Utah might want to do this entirely, depending on how effective I can be working on snmpit).

I gave afalk the design document for metavpn as it stands now - I will put it up somewhere soon.

[pgunn@cs.cmu.edu]

Current design document for metavpn is ​here