Configuring 6WIND vRouter For Multi-Cloud Networks

Modern datacenters are adopting the cloud and its benefits at a high speed. The need for agility and competition pushes IT executives to work with multiple cloud providers and propose different services to their users. Working concurrently with two or more cloud providers such as Amazon AWS, Microsoft Azure or Google Cloud Platform brings operational challenges for routers to handle.

If we focus on the networking aspect of the multi-cloud strategy, each cloud provider dictates its own specific rules that routers need to comply with. Building an infrastructure to work in such an environment with different peering and security models could quickly become a headache for Network Engineers. This blog is intended to share a couple solutions that are known to facilitate multi-cloud deployments within datacenters using 6WIND vRouter.

 

Solution 1: Virtualization

A simple vRouter solution to solve the multi-cloud challenge is to take advantage of virtualized infrastructure running on a hypervisor such as VMware ESXi or Linux KVM. The straightforward configuration is to run one instance of a vRouter per cloud provider. Each vRouter would peer (BGP) with a dedicated cloud provider using the required security (VPN) and networking configurations (ACL, NAT, VLAN, GRE, etc.).

The figure below shows how this architecture looks if we take the example of the three major public providers mentioned in this blog:

Figure 1

 

Solution 2: Virtual Routing and Forwarding (VRF)

The multi-cloud strategy could also be addressed by one powerful instance of vRouter, running either bare metal or as a virtual instance. In this case, the vRouter provides a specific technology called VRF to isolate and cluster the networking features of the router. Each VRF will have its own routing table along with its own network configuration allowing a one-on-one peering with each cloud provider. It is up to the Network Engineers to decide whether they want to configure leaking from one VRF to another, which is also known as cross-VRF communication.

The figure below shows how this architecture looks if we take the example of the three major public providers mentioned in this blog:

Figure 2

 

Pros and Cons

Both solutions described in this blog address multi-cloud challenges using the same 6WIND vRouter software regardless of whether it is running on a COTS server in bare-metal mode or in a virtualized environment. However, there are certain areas such as performance, resource consumption and operation complexity that may influence your deployment.

 

  • Performance

6WIND vRouter products can run both bare metal and in virtual platforms. However, virtualization is adding one more layer of configuration for Network Engineers. While allocation of resources are one-to-one in a bare metal environment, there are several options you will have to consider in virtualization that may change the performance of your router. While the functionality of the router won’t be affected due to the virtual platform, performance can be impacted. In this case, running a single instance of the vRouter on a bare metal platform would prevent the hassle of additional virtualization details and the impact on network performance.

 

  • Resource consumption

Let us consider a standard 6WIND vRouter, which typically requires 8GB of memory per instance.

Solution 1 uses as many vRouter instances as the cloud providers we have to peer with. In Solution 1, three vRouter instances are deployed, which requires a minimum of 3×8 = 24GB of memory (not including the memory consumed by the hypervisor environment).

Solution 2 uses one vRouter instance, thus requiring 8GB of memory (not including the memory consumed by the hypervisor environment if running in a virtual instance).

It is clear that Solution 2 is the most memory-efficient solution.

 

  • Operation complexity

6WIND vRouter provides a NETCONF/YANG-based management framework. Both solutions using the vRouter instance are managed by NETCONF clients. However, managing one vRouter instance and having all configurations centralized could be more effective compared to managing multiple configuration files for multiple vRouter instances. While NETCONF/YANG management helps reduce vRouter operational costs, sometimes it can be preferable to use one configuration file to manage all routing configurations.

 

As with any networking challenge, there are multiple ways to solve problems and no one size fits all. To continue this discussion, we welcome you to contact us. We would be happy to provide feedback on how 6WIND’s vRouter can help your multi-cloud architecture.


 

Emre Eraltan is Lead Solutions Architect for 6WIND.