1. Heitor Moraes, Marcos Vieira, Italo Cunha, Dorgival Guedes
Efficient Virtual Network Isolation in Multi-Tenant Data Centers on Commodity Ethernet Switches
Heitor Moraes, Marcos Vieira, Italo Cunha, Dorgival Guedes

2. Problem
I want IP
I want IP
commodity
switch

3. Introduction
Ideally, except for specific interconnection agreements, traffic from one tenant‘s VMs should never be visible to other tenants‘ VMs
Only that tenant‘s traffic should be able to reach his VMs
IaaS providers must provision network resources to garantee isolation between customer networks

4. Virtualization Server Virtualization Server
Data center set up
VM 1A
VM 2A
VM 3A
Open vSwitch
VM 1B
VM 2B
VM3B
Tenant 1
Tenant 2
Logical plane
Tenant 3
Users
Physical plane
commodity
switch
Virtualization Server
Host B
Virtualization Server
Host A

5. Network isolation approaches
Extra header
Packet tagging with additional packet headers
VLANs, QinQ
Tunneling
Packets transported inside other packets
Total control over transport’s packet header
Fragmentation
Packet rewriting

6. LANES We propose LANES, a system that:
Provides arbitrary virtual network topologies
Ensures isolation between tenants
Uses commodity switches
Is free of encapsulation overheads

7. LANES set up Follows SDN paradigm Requires no physical changes VM 1A
Open vSwitch
VM 1B
VM 2B
VM3B
Open vSwitch
ETHERNET NETWORK
Follows SDN paradigm
Requires no physical changes

8. How LANES works
LANES associates a flow identifier to the traffic between each pair of communicating VMs
Flow IDs are generated on demand when VMs start communicating and need to be unique only between pairs of servers
As Ethernet switches forward packets based on MAC addresses alone, LANES uses the source and destination IP addresses to store flow identifiers.

9. Packet rewriting
Traffic of VMs go through the physical network are rewritten to hide source and destination MAC and IP addresses
Each VM interface has a unique IP assigned to it that is associated with its virtual switch
It is used in the rewriting SDN rules
Openstack and its tenants are unaware of this IP because packets are modified when they leave a host and when they arrive at another

10. How LANES works Source MAC: Ms Dest MAC: Mr Source IP: 10.0.0.1
Dest IP:
MAC Addresses of
the OvS Switches
LANES Flow ID
Rewriting flow rules applied by OvS switch on source virtualization host
Source MAC: Mu
Dest MAC: Mw
Source IP:
Dest IP:
Packet sent through physical network
Source MAC: Mu
Dest MAC: Mw
Source IP:
Dest IP:
Rewriting flow rules applied by OvS switch on destination virtualization host
Source MAC: Ms
Dest MAC: Mr
Source IP:
Dest IP:

11. How LANES works

12. Types of traffic Traffic within a host
Authorized traffic between VMs located on the same host is forwarded without modification and no packet rewriting is performed

13. Types of traffic Between hosts
When LANES identifies that a packet‘s destination VM runs on a different host, LANES allocates any unused Flow ID to the pair of communicating VMs
Flow rules rewrite packet headers before they are transmited through the physical network
Flow rules in the destination server recover packet‘s original headers

14. Types of traffic ARP Queries
LANES has all information about the interfaces used by Openstack VMs, including IP, MAC and Network of each one
ARP Requests are intercepted by LANES, MAC addresses requested are looked up by the controller in its database and the response is returned only to the requester

15. Types of traffic IP broadcast
Broadcasts packets need to be delivered to all ports allocated on the network of a tenant
These networks may span across multiple hosts
LANES delivers broadcasts messages to all ports of the network inside the host and rewrites them as unicast packets to be sent to other hosts which also have VMs on the same network
Other hosts rewrite back the received packets into broadcast and deliver them to the local ports

16. Types of traffic External networks
LANES generates external flow identifiers for packets between VMs and external IP addresses
To avoid generating one flow identifier whenever a VM connects to a different external IP address, external flow identifiers overwrite the source IP address of outbound packets and the destination IP address of inbound packets
LANES keeps the external IP address untouched when rewriting inbound and outbound packets

17. Implementation
LANES prototype works on top of OpenStack using the POX SDN controller
The virtual network topologies are created using OpenStack‘s Neutron module

18. Implementation
Changes in the virtual networks topology are propagated by Neutron to LANES which can reconfigure Open vSwitches as necessary
When a virtualization host boots, its Open vSwitch instance contacts the LANES controller, which configures that instance and adds it to its database

19. And does it work? What was tested? Network isolation Latency
Physical address resolution (ARP)
Configuration latency
Communication latency after configuration
Bandwidth
Broadcast latency
Controller load under heavy load of new flows

20. System Evaluation
We considered three different software stacks for the evaluation:
LANES with POX module
L2 switch from POX, which is offered as a reference, indicated as POX+L2
OvS switch as a simple L2 switch, without isolation or an OpenFlow controller

21. System Evaluation Testing environment
A physical infrastructure corresponding to part of the infrastructure of an IaaS provider was build to validate LANE‘s operation
One switch for OpenStack control communications, to access the datacenter network, to communicate with the POX controller, and to exchange traffic with the Internet
One switch for traffic between virtual machines

22. Testing network isolation
Are the networks protected?
ICMP packets were sent to all IPs of the local area network
Bandwidth tests were executed while the network was under attack

23. Testing network isolation
LANES
OvS and POX+L2

24. Testing network isolation

25. Testing MAC address resolution latency
How much time does it take to resolve the MAC address of a VM?
And during an attack?

26. Testing MAC address resolution latency
LANES
OvS
POX+L2

27. Testing flow configuration latency
How long does it take for the first packet to leave a VM, be received by the destination and the response return?

28. Testing flow configuration latency
Same server
Between servers

29. Testing estabilished flows latency
What is the delay after the forwarding rules are installed into the switches?
This is the state where the communication will effectively occur

30. Packet latency in milliseconds
Testing estabilished flows latency
Packet latency in milliseconds

31. Testing bandwidth What is the maximum bandwidth available between VMs?
Inside the same virtualization server
When the traffic flows through the physical network

32. Available bandwidth in Gbps
Testing bandwidth
Available bandwidth in Gbps

33. Testing scalability
Evaluate the controller capacity in dealing with heavy bursts of new flows
Measurement of multiple parameters
CPU, latency, bandwidth and number of new flows

34. Testing scalability Bandwidth capacity between VM1 and VM3
Latency between VM1 and VM2
New flows bursts originated on VM4

35. Testing scalability

36. Conclusions LANES ensures isolation between virtual networks
Packet rewrite hides tenants’ traffic from the physical network
LANES can be effective in protecting the network from DoS attacks within the datacenter network

37. Conclusions
LANES does not require advanced features and works on top of commodity Ethernet switches
LANES requires no modification to hosted VMs
Puts no restrictions on VM IP addresses
Does not incur encapsulation overhead

38. Thank you.

40. OpenStack Architecture

41. OpenFlow versions
Ren, Tiantian, and Yanwei Xu. "Analysis of the New Features of OpenFlow 1.4." 2nd International Conference on Information, Electronics and Computer. Atlantis Press, 2014.

42. Packet rewriting example

43. Packet rewriting example

44. Related Work

45. Tenant’s demands Efficiency Flexibility Freedom
Isolation of other tenants
It is easy to isolate CPU, memory and storage
Network is not