Network Function Virtualization (NFV) is gaining momentum, and many Managed Service Providers (MSP) and enterprises in Europe and US are evaluating NFV as a means to provide connectivity and offer services at the branch offices. Both MSPs and enterprises are excited about the agility, operational simplicity and service velocity (speed at which services are enabled) that NFV enables, while reducing the costs of deployment and operation.
A couple of years back MSPs had to deploy a Layer 3 network device (e.g. Router) that ran firewall, NAT, deep packet inspection, traffic control, intrusion prevention on-site to offer services to each customer. This approach was expensive, and as number of services increased – performance suffered and rollout became slow. Today, MSPs can deploy a ‘thin’ Layer 2 device (e.g. a switch) at branch that forwards all the traffic to MSP’s Point of Presence (POP) or enterprise Data Center (DC) where all the services heavy lifting occurs. In such a deployment, MSPs need to tunnel the data from branch to the virtual machine instances in their POP/enterprise DC offering services, while maintaining clear separation between data from different customers. Enter VXLAN – a network virtualization technology that allows for Layer 2 adjacency across IP Networks – to rescue.
Implementing VXLAN on AWS EC2 using Ravello
Ravello operates an overlay cloud service that enables enterprises to run complex data center application environments in AWS and Google, and it makes it very simple to deploy VXLAN across multiple sites. A typical use-case is testing the network architecture ahead of a production deployment. Using Ravello, one can quickly create a VXLAN deployment in AWS or Google Cloud, test the architecture ahead of a production deployment – without waiting for any physical infrastructure setup – saving time and resources. It really is as easy as 1-2-3!
- Create a node with two network interfaces on LAN at each end – MSP Data Center and branch. We will call these bridge nodes
- Create a VXLAN pointing to the remote bridge node peer’s address. Create a bridge with VXLAN as one leg and one of the two network interfaces (say eth1) as the other
- Configure second interface (say eth0) of the bridge node to tunnel the VXLAN packets across the internet
And voila – we are done!
Now, in more detail –
Step 1 – Create Bridge Node & Hosts on LAN
To demonstrate how easy it is to test the VXLAN deployments using Ravello, I have created a two application environments – each running on a different public cloud provider – Amazon Web Services (AWS) and Google Cloud. Each application environment has three Ubuntu linux virtual machines – one VM for bridge node (vxlan1 for AWS and vxlan2 for Google Cloud), and two VMs (lan1_1 & lan1_2 for AWS and lan2_1 & lan2_2 for Google Cloud) representing two hosts on the LAN. The eventual goal is to create a VXLAN tunnel between the two environments, and use the bridge nodes (vxlan1 and vxlan2) to communicate between the two (see figure below).
Here is how each Ravello environment looks on canvas –
To keep things simple for this tutorial, I have defined static IPs for each of the LAN hosts. I have also included in the MAC address for each of the LAN hosts as we will need it later to show that traffic is traversing between the two LANs using VXLAN.
LAN 1 – On AWS
|vxlan1 (Bridge node)||eth0||184.108.40.206/24|
LAN 2 – On Google Cloud
|vxlan2 (Bridge node)||eth0||220.127.116.11/24|
The second interface (eth1) on the bridge node is configured to get a DHCP Public IP address for each of the two Application Environments (AWS and Google Cloud).
One can also look at the network configuration by clicking on Network tab in the Ravello environment, and add NICs or edit the network configuration by clicking on the VM and making changes in the panel on right.
In the diagram above, 18.104.22.168/24 is the LAN Network, and 10.0.0.0/24 is the external network that will be used for VXLAN bridging later.
Step 2 – Create a VXLAN
We need to enable VXLAN at each of the bridge nodes. The first step is to load the VXLAN module – we will do it using the modprobe command.
$ sudo modprobe vxlan
Next, we create a VXLAN interface and set MTU & VXLAN ID
$ sudo ip link add mtu 65000 vxlan1 type vxlan id 1
Finally, we append the forwarding entry pointing to the remote peer
$ sudo bridge fdb append 00:00:00:00:00:00 dev vxlan1 dst
Step 3 – Add VXLAN and second interface to the Bridge
We need to create a bridge at each of the bridge nodes (vxlan1 & vxlan2).
First, we add a bridge at each of the bridge nodes –
$ sudo brctl addbr br0
Next, we add both the interfaces vxlan0 and eth1 to the bridge
$ sudo brctl addif vxlan1 eth1
Finally, we bring the bridge interface up
$ sudo ifconfig br0 up
One can confirm that the interfaces are bridged by doing
$ sudo brctl show br0
Let’s confirm that VXLAN works
To test – ping the lan2_1 (22.214.171.124) from lan1_2 (126.96.36.199) – which works!
Looking at the ARP table on the lan1_2 host we can see it points to the MAC address of lan2_1 as well (refer to the table with MAC addresses for LAN hosts above)
Ravello provides a straightforward and easy way to set up a VXLAN on public cloud, whether it is to enable your NFV infrastructure or test your deployment scenario ahead of production placement. We can share this pre-configured blueprint (template) with you if you want to give it a try. Just sign up for a free Ravello trial, and drop us a note asking for it.
About Ravello Systems
Ravello is the industry’s leading nested virtualization and software-defined networking SaaS. It enables enterprises to create cloud-based development, test, UAT, integration and staging environments by automatically cloning their VMware-based applications in AWS. Ravello is built by the same team that developed the KVM hypervisor in Linux.