We are happy to announce a new addition to our Public Marketplace: the service appliance with several Virtual Network Functions (VNFs), the virtualized network services including the Virtual Router. Based on Alpine Linux, it comes with a number of useful network functions:

• DHCPv4 server
• DNS recursor
• IPv4 Network Address Translator (i.e. NAT, IP Masquerade)
• Virtual Router

A High Availability option is provided by Keepalived. If you are (or were) using the OpenNebula Virtual Routers, it might be interesting for you to know that the new appliance is an improved version built upon the old (and now legacy) VRouter appliance, which implemented only virtual routing functionality.

You’ll find two new virtual appliances available on our Public Marketplace. They are based on the same image, but with different (Virtual Machine) templates and designed for different purposes:

• Service VNF – exposing all features, but runs as regular Virtual Machine,
• Service Virtual Router – runs as OpenNebula Virtual Router.

As of now the list of implemented VNFs is a bit limited, but it’s expected to grow in the future with other VNF services, so let us know your preferences! Some possibilities include load balancing, port forwarding, VPN, and others…

This new appliance is a little bit different from previous ones. It supports recontextualization and can adjust the behavior during run-time. You don’t need to start a brand new instance if your configuration requirements for a particular virtual network function change. Naturally, it will also react and reconfigure itself when network interfaces are dynamically added or removed.

Let’s see how this new functionality works when implementing a typical network router:

As displayed on the picture, we have an instance of VNF/Virtual Router appliance with 3 connected NICs, each into a different virtual network. Interfaces eth1 and eth2 are connected to the distinct private networks and instance provides there DHCP and DNS services and routes between networks. Interface eth0 goes to the Internet and all traffic from private networks (eth1, eth2) goes through the Network Address Translation (NAT) mechanism, which means that clients on private networks can reach the public Internet “hidden” behind the IP address of the VNF/Virtual Router instance.

Here is an example of how to contextualize such VNF/Virtual Router instance in OpenNebula:

We enable DHCPv4, NAT, and DNS VNFs (routing is enabled by default when the appliance is started as OpenNebula Virtual Router) and use a special syntax to define on which network interfaces is a particular function active. For both DHCP and DNS, we requested to run on every attached network interface except the public Internet-facing one (!eth0 – notice the exclamation mark). We usually do not want to provide these services to the public Internet, both are dangerous if not used properly and could disrupt someone else’s infrastructure or become a victim of DDoS. On the contrary, for the NAT VNF, we select that outgoing traffic will be NATed on the eth0 interface, and nowhere else.

Now we can just simply attach (and detach) NICs into particular virtual networks and the VNF/Virtual Router will automatically reconfigure itself to provide the desired services with the requested constraints. It does not matter if it has two, three, or more NICs attached to it. NAT will be enabled only on the first interface (eth0), with the other DHCP and DNS services active on all other interfaces.

Hopefully, this short example clarifies some of the key feature of the new VNF/Virtual Router appliances. As usual, you can find out more about them in our documentation section.

And as always, we would love to hear from you about your experience using this appliance, and please send us your suggestions for future improvements!