VXLANs Overview

As virtualization grows driven by the “cloud revolution”, existing network technologies aren’t sufficient enough to support the growth. Advanced virtualization features are causing layer 2 boundaries to expand, which isn’t scalable in current datacenter networks. In multi-tenant environment, multiple internal and external customers require multiple overlapping subnets which further complicates the problem of network configuration and IP management. To resolve all these issues, there are overlay networks which are networks built onto of existing IP infrastructures.There are many protocols used to build overlay tunnels but In this post we will specifically talk about VXLAN.

VXLAN tunnels VM-to-VM layer 2 traffic, hence infrastructure networks are not aware of the subnets that are being routed in the tunnels, addressing the issue of overlapping subnets and minimizing the configuration changes required on the network. VXLAN contains VNI which are similar to VLAN tags. Traditional 802.1q VLAN tag contains 12-bit of space hence only 4096 VLANS can be available on the network. This limit can be easily achieved in today’s virtualization driven datacenter. Unlike VLANs, VNI contains 24-bit of space which provides approximately 16 millions networks enough to handle the growth. Since VXLAN tunnels layer 2 traffic, adjacencies can be built between the VMs to enable features like VM Mobility etc.

I have setup a simple VXLAN topology in my lab as shown below.

There are two KVM hypervisors. My infrastructure network is 10.10.30.0/24. The infrastructure gateway is not aware of the tunnelled subnet (192.168.1.0/24). I have used open vSwitch to build the VXLAN tunnel between the hypervisors. Endpoints of the tunnels are the interface IPs.

Here are the steps taken to configure the VXLAN tunnel on Open vSwitch.

1.Create a virtual bridge using Open vSwitch on hypervisor1 and hypervisor2

 ovs-vsctl add-br ovsbr0

2. Add VXLAN ports, specifying end-points of the hypervisors
On Hypervisor 1,

 ovs-vsctl add-port ovsbr0 vxlan1 -- set interface vxlan1  type=vxlan options:remote_ip=10.10.30.12 

On Hypervisor 2,

 ovs-vsctl add-port ovsbr0 vxlan1 -- set interface vxlan1  type=vxlan options:remote_ip=10.10.30.10

Once the test VMs are configured to use the Open vSwitch bridge, the output of ovs-vsctl show should be as below.
On Hypervisor 1,

root@hyper1:/# sudo ovs-vsctl show
9c496209-fc2e-4b45-a89a-9c7d49a718ee
    Bridge "ovsbr0"
        Port "vxlan1"
            Interface "vxlan1"
                type: vxlan
                options: {remote_ip="10.10.30.12"}
        Port "ovsbr0"
            Interface "ovsbr0"
                type: internal
        Port "vnet0"
            Interface "vnet0"
    ovs_version: "2.4.0"

On Hypervisor 2,

root@hyper2:/# sudo ovs-vsctl show
9c496209-fc2e-4b45-a89a-9c7d49a718ee
    Bridge "ovsbr0"
        Port "vxlan1"
            Interface "vxlan1"
                type: vxlan
                options: {remote_ip="10.10.30.10"}
        Port "ovsbr0"
       Interface "ovsbr0"
                type: internal
        Port "vnet0"
            Interface "vnet0"
    ovs_version: “2.4.0” 

Test VMs are configured to use new subnet (192.168.1.0/24). Since the tunnel is established between two VMs i am able to ping the remote-ends of the tunnelled subnet from the VMs.

$ ping 192.168.1.132
PING 192.168.1.132 (192.168.1.132): 56 data bytes
64 bytes from 192.168.1.132: seq=0 ttl=64 time=5.444 ms
64 bytes from 192.168.1.132: seq=1 ttl=64 time=3.106 ms
64 bytes from 192.168.1.132: seq=2 ttl=64 time=2.991 ms
64 bytes from 192.168.1.132: seq=3 ttl=64 time=3.223 ms
 

Mihir

 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.