NGNET-Development (2004.11.01 03:00:07)

We currently migrate to MediaWiki from our old installation, but not all content has been migrated yet. Take a look at the Wiki Team page for instructions how to help or browse through our new wiki at wiki.linux-vserver.org to find the information already migrated.

NGNET is the Next-Generation Networking in Linux-VServer. This is the so long awaited network virtualisation which lacks Linux-VServer. There is an actual testing code for NGNET, but it is just a working prototype from which we learnt a lot of stuff.

Prerequires

• Study FIB (Forward Information Base) stuff in mainline.

• Study the old NGNET patch.

• Study the network virtualisations of OVZ and FreeVPS?.

Goals

• Make a network device (or adapt existing ones) to be dual-homed, i.e. belonging to the host context as well as a guest context. This is needed, because we want to use namespace virtualisation.

• Make the network stack take the XID as hash-key for all routing decisions and/or network entries.

• 'Reflect' packets on the 'special' vnet devices into a different XID (similar to loopback, just with a magic XID change at the turnpoint), combined with a network device namespace virtualization, which we require anyways, this will give us routeable 'virtual' interfaces which appear inside and outside a guest, as well as network connections between guests, and guest loopback.

This is not like that in the actual ngnet code: special vnet interfaces are not visible outside the guest (on the host) and netfilter magic applies to link them to the host. Those dirty netfilter tricks will disappear.

Required steps for VServer kernel code

• Make the routing and routing caches XID aware.

• Make the interface information XID aware.

• Make netfilter/iptables XID aware (including limits).

• Create the dual-homed network interface.

• Integrate all the new toys into the guest setup.

• Make NGNET selectable at compile time. As this version of NGNET will not be as fast as the 'original' NGNET idea (because of the additional 'routing' part) we should keep the current non-virtualised networking as an option. Maybe we can find a way to have both concurrently!