Blog Article:

New Appliances for Virtual Network Functions and Virtual Router

Petr Ospalý

Cloud Engineer at OpenNebula

Aug 6, 2020

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:

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.

Screenshot from 2020 08 06 10 13 48

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:

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:

VRouter img

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!

4 Comments

  1. Petr Ospalý

    Hi Kristian,

    Yes, load balancing and more is planned for this appliance as are other VNFs (next to DHCP, DNS, etc.). Sorry, I frankly was not aware of your contribution which you have linked above. The current appliance is a complete rewrite of the previous version and it was actually worked on since last year but then it was idly sitting for quite time in the queue :/

    Nevertheless, load balancing, VPN and other functions are planned and will be added as time will allow.

    Thanks again for your contribution – I will reexamine it.

    Reply
  2. rodrigo

    Hello please i have a question in relation to the following: Interface eth0 goes to the Internet and all traffic from private networks (eth1, eth2) goes through the Network Address Translation (NAT) mechanism

    Do I need any configuration in the MY Physical ISP ROUTER/GATEWAY?, regards,

    Reply
    • Petr Ospalý

      Hi Rodrigo,

      if you configured the VNF/Vrouter correctly (https://docs.opennebula.io/appliances/service/vnf.html#function-nat4) and set ONEAPP_VNF_NAT4_ENABLED=yes and ONEAPP_VNF_NAT4_INTERFACES_OUT=eth0 then it should work just fine for you.

      You may encounter issue with DNS resolving if your private vnets are not setting up DNS or they point to a wrong place.

      In such case try to fix affected vnets by setting correct DNS nameserver in their context or enable DNS on VNF/Vrouter itself (https://docs.opennebula.io/appliances/service/vnf.html#function-dns) – you can either leave it to just forward queries to your router or set it to use root servers (be mindful to not enable DNS on the eth0 interface!).

      All this means of course that VNF/Vrouter must itself be able to access internet on the eth0 via your router otherwise you must fix the vnet setup attached to eth0 (correct subnet, gw, dns…).

      Please if you still have trouble with the setup then open new topic on the https://forum.opennebula.io/.

      Thanks

      Reply

Submit a Comment

Your email address will not be published.

Solve : *
22 − 1 =