search

MatrixAI / Emergence

Distributed Infrastructure Orchestration
Apache License 2.0
1 stars 0 forks source link

Create a demonstration of the networking knowledge #1

Closed CMCDragonkai closed 6 years ago

CMCDragonkai commented 6 years ago

Given that you have a couple notes, if you could create a VPN within a VM, via a shell script.

Let's think about it.

Let's get NAT working, VETH communicating between 3 containers. 1 is routable publically. The other 2 can only talk to each other.

TUN/TAP.

So see if you can create this with a shell script.

CMCDragonkai commented 6 years ago

@mokuki082 Hey can you update this issue with the recent container experiment you have and if it is done, make sure to close this issue.

mokuki082 commented 6 years ago

I got NAT working between two containers with two different subnets, with a DHCP server running in one of them.

However there is still an unexpected delay in DHCPREQUEST, I noticed that it may be related to my DHCP Client installation (verbose mode shows that I have corrupted lease files which may lead to data loss). I have yet to get kea working because of its chain of dependencies, but now that I've got my main task done I can experiment with different tweaks to make this prototype more efficient.

Next step:

Current Commit Link

mokuki082 commented 6 years ago

I have replaced all net-tools commands with iproute2. (except for iptables commands since it is considered to be more efficient when dealing with ip address translation).

The problem with dhclient lease file is documented here

mokuki082 commented 6 years ago

After doing some readings and experiments, my fix to the current code is to send a DHCPRELEASE message to the server before acquiring a new IP address.

Originally, the timeout caused by the DHCP server not responding to the DHCPREQUEST leads to very slow IP allocation. Ideally if the process uses the same network interface, this would actually save time (since we discard the first two messages needed to send). However, in this script we always create new interfaces (bridges, veths), hence the link/ether parameter is always different. This is why the DHCP server refuses to allocate the same IP address to the new namespace.

There are couple of ways to resolve this issue. First, we can assign a static MAC address to the veth pair that we use for the A-node namespace, but this is complicated and I do not know how mac addresses are generated for virtual interfaces such as bridge and veth, since they aren't bound to an actual hardware. However, if we can have a static MAC for certain interfaces, it could essentially speed up our DHCP process. This is definitely one of my next things to research.

The simpler approach is to unicast a DHCPRELEASE message before killing the interface and namespaces created previously. DHCP Client will look into the lease file stored locally, and tell the DHCP server which lease we want to release. This effectively speed up the process by avoiding the timeout.

Performance comparison: Old script with failing DHCPREQUEST: 14 seconds First time running the script: 2 seconds Sending DHCPRELEASE at the start of the script: 3 seconds