OpenVirtex (OVX) Tutorial

OpenVirtex (OVX) Tutorial

• 1.
  1/47 Dongho Son Dept. ofCSE, POSTECH [email protected] http://dpnm.postech.ac.kr 2016. 11. 07
• 2.
  2/47 Outline  Introduction  Usecases  Previous work  Architecture  Features  Results  Conclusion & Future work  OVX Tutorial  References
• 3.
  3/47 Introduction  Virtual Networks To provide virtualized network resource, the network is decoupled from its physical manifestation  Network virtualization has emerged as one of the key capabilities of computing and networking infrastructure • Why?  These virtual networks can offer strong isolation, migration, snapshot and customize topology • So..?  Infrastructure providers are focusing on network virtualization using SDN to better utilize their network resources  OpenVirteX(OVX)  A network virtualization platform that can … • Provide address virtualization to keep tenant traffic separate • Provide topology virtualization to enable tenants to specify their topology • Deliver each virtual network to the tenants’ NOS as Infrastructure  OVX is a network hypervisor that manage network virtualization
• 4.
  4/47 Use Cases  NFV Nowadays network function, such as firewall, DPI, load-balancing and authentication, are implemented in dedicated H/W appliances  NFV offers such network functions in S/W and VMs to reduce CAPEX/OPEX and allow more flexibility  NFV will require dynamic virtual networks management
• 5.
  5/47 Previous Work(1/2)  FlowVisor A S/W platform for slicing an OpenFlow network into multiple resource pools, or slices  All slices share the same flow or address space, and thus a slice doesn’t have a completely separate and independent address space  FlowVisor also doesn’t allow a slice to have an arbitrary virtual network topology. It only offer a subset of the physical topology
• 6.
  6/47 Previous Work(2/2)  VeRTIGO An extension to FlowVisor which provides topology virtualization  Each tenant can specify virtual links in the network slice  Since VeRTIGO is based on FlowVisor it is unable to provide each tenant with a full isolated address space  FlowN  Add a database storage system to maintain a mapping between the physical and virtual realms  Since each tenant’s logic must be embedded in the FlowN controller, a tenant is constrained to developing their application with the FlowN framework
• 7.
  7/47 Architecture(1/3)  Network virtualizationplatform  OVX is a network virtualization platform capable of spawning virtual networks with OpenFlow semantics  These virtual networks may have arbitrary topology and addressing schemes, configured as per tenant request  Requests are conveyed via API calls to OVX with a tool such as a network embedder
• 8.
  8/47 Architecture(2/3)  Internal OVXarchitecture  Internally, OVX relies on a loose decoupling of virtual elements from physical counterparts  OVX models all virtual and physical elements and maintains the mapping between them  All virtual network elements are mapped to at least one physical element
• 9.
  9/47 Architecture(3/3)  Topology virtualization OVX allows the tenants to specify their own arbitrary topology  These topologies don’t have to correspond to the actual physical network, but exactly match what the tenants desire  Address virtualization  OVX grants tenants the ability to choose address assignments for their end hosts, allowing multiple, potentially over-lapping IP address blocks to exist in the same physical network  To differentiate hosts, OVX generates unique tenant IDs for each tenant  Control function virtualization  Each virtual network can have its own NOS and applications that can program the virtual network switches  OVX is responsible for mapping various control functions for the virtual network on to the corresponding physical network
• 10.
  10/47 Features(1/2)  Loose couplingof virtual and physical components introduces significant amounts of flexibility  Topology customization • A virtual link may encompass multiple contiguous hops, and virtual switches may abstract away parts or all of a network  Resiliency • A resilient virtual link is characterized by multiple physical paths between the points corresponding to the virtual link endpoints  Dynamic vSDN reconfiguration • Since the mappings themselves don’t store any network state, these can be changed at runtime.
• 11.
  11/47 Features(2/2)  Persistence  Eachnetwork and network element maintains a collection of preservable attributes • It allows OVX to record and store information in storage • vSDNs can be torn down and re-created at a later time • It gives OVX the ability to save and recover vSDN configuration, persistence which can enable to snapshot tenant networks  Troubleshooting  Extensive rewriting of control messages complicates the already difficult process of troubleshooting networks  OVX enables it to integrate with network debuggers by providing connection into vSDNs
• 12.
  12/47 Results(1/2)  Control channeloverhead and virtual network generation time  A figure shows the latency introduced by OVX, FlowVisor, and FlowN and the reference case where no virtualization software is used and the packets are sent directly from the switch to the controller  Compared with other platforms, OVX offers better performance than similar virtualization platforms  It just adds around 0.2 ms latency to the control channel
• 13.
  13/47 Results(2/2)  Control channeloverhead and virtual network generation time  A Table shows the time needed to create and configure a virtual network up to the point where the network OS has connected  Virtual networks can be created through the API or loaded from persistent storage(DB)  OVX clearly can offer with provisioning times in the order of several (tens of) seconds
• 14.
  14/47 Conclusion & FutureWork  OVX provides programmable vSDNs  These vSDNs are customizable in terms of topology and addressing scheme used, and each tenant can control his virtual SDN with the NOS of his choice  Three additional functionalities  Snapshotting and migration of vSDNs • The ability to preserve the state and data of VM at a specific point in time has become a key functionality • This allows not only fast recovery in case of failure, but also eases the migration and duplication of a working VM in other location  Evolving beyond OF1.0 • Replace the standard java openflowj library, strictly tied to OF1.0, with LOXI • Plan to implement OF1.3 in the southbound interface  vSDN-based QoS • OVX will use flow-based meters to enforce QoS for the virtual networks, thus offering to the tenants a fully isolated environment with performance guarantees
• 15.
  15/47 OVX Tutorial
• 16.
  16/47 Introduction  Pre-requisites  Needa computer with at least 2GB of RAM & at least 5GB of free hard disk space  Windows, Mac OS X or Linux – all work fine with VirtualBox  Download two files  VirtualBox (https://www.virtualbox.org/)  Tutorial VM (http://ovx.wpengine.com/wp- content/uploads/ovx-vm-x86_64-2014-10-14.zip) • Unzip it! Then you can see vmdk file.
• 17.
  17/47 Setup Your Environment Create Virtual Machine(VM)  Start up VirtualBox  Select Machine>New, give it a name, and select Linux as type and Ubuntu(64bit) as version.  Configure the VM with 2GB of memory.  Select ‘Use an existing virtual hard drive file’, and point it to the vmdk file you download. Select create.  Start VM  Login with user ovx and password ovx
• 18.
  18/47 Setup Your Environment Important Command Prompt Notes  Terminal command prompt  Mininet console  OVX log message
• 19.
  19/47 Setup Your Environment Scenario  11 core switches  Each core switch has 4 hosts attached  Hosts connect to their core switch on ports 1 through 4  Other port number are shown in the topology image.
• 20.
  20/47 Setup Your Environment Scenario  DPIDs are listed in the table  Host MAC addresses are the last 6 bytes of the DPIDs, with the last byte equal to host number Example) DPID of SFO  00:00:00:00:00:00:02:00 MAC of the 3rd host on SFO  00:00:00:00:02:03
• 21.
  21/47 Setup Your Environment Start Mininet  Start a terminal and run internet2.py • $ sudo python internet2.py • It will run Mininet and construct topology  It will point all switches to connect to OVX OVX
• 22.
  22/47 Setup Your Environment Start OVX  Start another terminal and run OVX • $ cd OpenVirtex/scripts • $ sh ovx.sh  OVX connect to all switches and links in the network OVX
• 23.
  23/47 Learning to Fly Introduction  Try to create a simple virtual network composed out of two hosts, h_SEA_1 and h_LAX_2  Final virtual network will look like figure h_SEA_1 h_LAX_2
• 24.
  24/47 Learning to Fly Virtual Network Configuration  Create virtual network • Start a new terminal • $ python ovxctl.py –n createNetwork tcp:localhost:10000 10.0.0.0 16 • A virtual network will have a controller speaking tcp protocol and running on localhost port 10000. Virtual network’s hosts will be using Ips in the 10.0.0.0/16 range. • Above command returns a tenant ID (ex. ‘tenantId’:1 )  Create virtual switches • $ python ovxctl.py –n createSwitch 1 00:00:00:00:00:00:01:00  SEA • $ python ovxctl.py –n createSwitch 1 00:00:00:00:00:00:02:00  SFO • $ python ovxctl.py –n createSwitch 1 00:00:00:00:00:00:03:00  LAX • Each time we create a virtual switch, we get a virtual switch DPID. • Virtual DPID of SEA : 00:a4:23:05:00:00:00:01 • Virtual DPID of SFO : 00:a4:23:05:00:00:00:02 • Virtual DPID of LAX : 00:a4:23:05:00:00:00:03 tenantId Physical DPID
• 25.
  25/47 Learning to Fly Virtual Network Configuration OVX 1) Create virtual network 2) Create virtual switches SEA SFO LAX 00:a4:23:05:00:00:00:01 00:a4:23:05:00:00:00:02 00:a4:23:05:00:00:00:03
• 26.
  26/47 Learning to Fly Virtual Network Configuration  Create virtual ports • $ python ovxctl.py –n createPort 1 00:00:00:00:00:00:01:00 1  return port 1 • $ python ovxctl.py –n createPort 1 00:00:00:00:00:00:01:00 5  return port 2 • $ python ovxctl.py –n createPort 1 00:00:00:00:00:00:02:00 5  return port 1 • $ python ovxctl.py –n createPort 1 00:00:00:00:00:00:02:00 6  return port 2 • $ python ovxctl.py –n createPort 1 00:00:00:00:00:00:03:00 5  return port 1 • $ python ovxctl.py –n createPort 1 00:00:00:00:00:00:03:00 2  return port 2 tenantId Physical DPID Physical port Get virtual port SEA  SFO  LAX 
• 27.
  27/47 Learning to Fly Virtual Network Configuration  Create virtual links • $ python ovxctl –n connectLink 1 00:a4:23:05:00:00:00:01 2 00:a4:23:05:00:00:00:02 1 spf 1 • $ python ovxctl –n connectLink 1 00:a4:23:05:00:00:00:01 2 00:a4:23:05:00:00:00:02 1 spf 1 • The call returns the virtual link ID. Note that OVX will automatically create the reverse link as well, which has the same link ID.  Connect hosts • $ python ovxctl –n connectHost 1 00:a4:23:05:00:00:00:01 1 00:00:00:00:01:01 • $ python ovxctl –n connectHost 1 00:a4:23:05:00:00:00:03 2 00:00:00:00:03:02 • Connect h_SEA_1 to port 1 on the first virtual switch • Connect h_LAX_2 to port 2 on the third virtual switch tenantId src virtual DPID dst virtual DPID src port dst port tenantId virtual switch DPID virtual switch port Host MAC address
• 28.
  28/47 Learning to Fly Virtual Network Configuration OVX 3) Create virtual ports 4) Create virtual links ① ② SEA SFO LAX 00:a4:23:05:00:00:00:01 00:a4:23:05:00:00:00:02 00:a4:23:05:00:00:00:03 ② ② ① ① h_SEA_1 00:00:00:00:01:01 h_LAX_2 00:00:00:00:03:02 5) Connect hosts
• 29.
  29/47 Learning to Fly Starting a virtual network  Our virtual network is ready to be booted • $ python ovxctl.py –n startNetwork 1 • The virtual switches connect to the controller(Floodlight) • From the controller’s point of view, OVX will look and behave exactly like a physical network. • OVX looks like a controller from the physical switches’ perspective tenantId That is a physical network! That is a controller! OVX
• 30.
  30/47 Learning to Fly Starting a virtual network  Ping between two hosts • Try to ping between h_SEA_1 and h_LAX_2  Everything works fine!  Floodlight’s GUI • http://localhost:10001/ui/index.html
• 31.
  31/47 Learning to Fly Starting a virtual network  Inspecting the flow tables on the physical switches • cookie=0x100000002, … , dl_src=00:00:00:00:01:01, dl_dst=00:00:00:00:03:02 actions=mod_nw_dst:1.0.0.4, mod_nw_src:1.0.0.3, mod_dl_src:a4:23:05:01:00:00,mod_dl_dst:a4:23:05:10:00:04 • cookie=0x100000003, … ,dl_src=a4:23:05:01:00:00,dl_dst=a4:23:05:10:00:02 actions=mod_nw_dst:10.0.0.2,mod_nw_src:10.0.0.1,mod_dl_src:00:00:00:00:03:02,mod_dl_dst:00:00:00:00:01:01 • cookie=0x100000002, … , dl_src=a4:23:05:01:00:00, dl_dst=a4:23:05:10:00:04 actions=mod_dl_src:a4:23:05:01:00:00,mod_dl_dst:a4:23:05:10:00:04 • cookie=0x100000003, … ,dl_src=a4:23:05:01:00:00,dl_dst=a4:23:05:20:00:02 actions=mod_dl_src:a4:23:05:01:00:00,mod_dl_dst:a4:23:05:10:00:02 • cookie=0x100000002, … , dl_src=00:00:00:00:03:02, dl_dst=00:00:00:00:01:01 actions=mod_nw_dst:1.0.0.3, mod_nw_src:1.0.0.4, mod_dl_src:a4:23:05:01:00:00,mod_dl_dst:a4:23:05:20:00:02 • cookie=0x100000003, … ,dl_src=a4:23:05:01:00:00,dl_dst=a4:23:05:20:00:04 actions=mod_nw_dst:10.0.0.1,mod_nw_src:10.0.0.2,mod_dl_src:00:00:00:00:01:01,mod_dl_dst:00:00:00:00:03:02  OVX rewrites packets at the edge of the network • IP address of h_SEA_1 and h_LAX_2 get rewritten from 10.0.0.x to 1.0.0.x and back • MAC address of packets are also rewritten • The controller is unaware of all this rewriting. It only deals with packets that have their original IP (in the 10.0/16 range) and MAC address SEA  SFO  LAX 
• 32.
  32/47 Learning to Fly SEA LAX SFO MAC=00:00:00:00:01:01 IP: 10.0.0.1 Host2 Host1 MAC=00:00:00:00:03:02 IP : 10.0.0.2 dl_src=a4:23:05:01:00:00 dl_dst=a4:23:05:20:00:04 mod_dl_src=00:00:00:0:01:01 mod_dl_dst=00:00:00:0:03:02 mod_nw_src=10.0.0.1 mod_nw_dst=10.0.0.2 dl_src=00:00:00:00:01:01 dl_dst=00:00:00:00:03:02 mod_dl_src=a4:23:05:01:00:00 mod_dl_dst=a4:23:05:10:00:04 mod_nw_src=1.0.0.3 mod_nw_dst=1.0.0.4 MACs are changed! IPs are changed! dl_src=a4:23:05:01:00:00 dl_dst=a4:23:05:10:00:04 mod_dl_src=a4:23:05:01:00:00 mod_dl_dst=a4:23:05:10:00:04
• 33.
  33/47 Learning to Fly SEA LAX SFO MAC=00:00:00:00:01:01 IP: 10.0.0.1 Host2 Host1 MAC=00:00:00:00:03:02 IP : 10.0.0.2 dl_src=a4:23:05:01:00:00 dl_dst=a4:23:05:10:00:02 mod_dl_src=00:00:00:00:03:02 mod_dl_dst=00:00:00:00:01:01 mod_nw_src=10.0.0.2 mod_nw_dst=10.0.0.1 dl_src=00:00:00:0:03:02 dl_dst=00:00:00:0:01:01 mod_dl_src=a4:23:05:01:00:00 mod_dl_dst=a4:23:05:20:00:02 mod_nw_src=1.0.0.4 mod_nw_dst=1.0.0.3 MACs are changed! IPs are changed! dl_src=a4:23:05:01:00:00 dl_dst=a4:23:05:20:00:02 mod_dl_src=a4:23:05:01:00:00 mod_dl_dst=a4:23:05:10:00:02
• 34.
  34/47 Air Traffic Control Add another virtual network  This network uses the same IP addresses space as the first  Traffic is completely isolated among tenants  mininet> h_SEA_3 ping –c3 h_LAX_4  works fine. • h_SEA_3 and h_LAX_4 are in the second virtual network  mininet> h_SEA_1 ping –c3 h_LAX_4  No ping. • h_SEA_1 is in the first virtual network but h_LAX_4 is in the second virtual network ① ② SEA SFO LAX 00:a4:23:05:00:00:00:01 00:a4:23:05:00:00:00:02 00:a4:23:05:00:00:00:03 ② ② ① ① h_SEA_3 00:00:00:00:01:03 h_LAX_4 00:00:00:00:03:04
• 35.
  35/47 Build Your OwnTopology  Big switches  Create a single virtual switch that is composed out of multiple physical switches • $ pyhon ovxctl.py –n createSwitch 3 00:00:00:00:00:00:05:00,00:00:00:00:00:00:06:00,00:00:00:00:00:00:0A:00 • It returns switch_id 00:a4:23:05:00:00:00:01 CLE IAD EWR h_CLE_3 h_EWR_2 h_IAD_1 CLE IAD EWR 00:a4:23:05:00:00:00:01
• 36.
  36/47 Build Your OwnTopology  Big switches  It’s interesting to see that, from the controller’s perspective, traffic is forwarded between ports on a single switch  It makes controller’s job so easier, as all it has to do is forward traffic between ports on a switch  Multiple physical switches can be aggregated into a virtual switch. But it cannot partition a single physical switch into multiple virtual switches.
• 37.
  37/47 Build Your OwnTopology  Virtual links  A virtual link is simply a link between two virtual switches  OVX calculate the routing automatically for the virtual link • User can specify a manual route by configuring the routing algorithm I don’t care here. I just want to connect MCI to Big switch h_CLE_3 h_EWR_2 h_IAD_1 CLE IAD EWR 00:a4:23:05:00:00:00:01 MCI h_MCI_4 00:a4:23:05:00:00:00:02 ③ ④ ① ② ② ①
• 38.
  38/47 Automagic Networks  Bigswitch  All we want is to connect hosts over a single big switch automatically h_SFO_1 h_IAD_2 h_EWR_3 h_ORD_4
• 39.
  39/47 Automagic Network  Bigswitch  Using json file, it can automatically create virtual switch h_SFO_1 h_IAD_2 h_EWR_3 h_ORD_4 ORD EWR IAD SFO ② ④ ③ ①
• 40.
  40/47 Automagic Networks  Physicalclone  We want a clone of the physical network  Using json file, it can automatically copy physical network h_SEA_1 h_MCI_3 h_IAH_4 h_ATL_2
• 41.
  41/47 Networking. Uninterrupted.  OVXensures user’s network is there and operating as expected  If a physical link fails, OVX can automatically switch over to the backup path without the controller noticing a thing  OVX calculated both a primary and backup path
• 42.
  42/47 Networking. Uninterrupted.  Fastreroute  As soon as OVX detects that a link has gone down, it finds out which flows are currently using that link, and shifts traffic away onto the backup path Time for ping sequence number 9 is much higher than the rest. Since OVX pre-calculated the path, it could push down the new rules over the full path very quickly Original path Backup path
• 43.
  43/47 Networking. Uninterrupted.  Morebackups  OVX calculates a single backup path by default  If user want to have more then user can ask OVX to calculate more backups  After a link failure, OVX automatically switches to a backup path. After the link comes back up, OVX will revert to the original situation  Taking control of routing  OVX calculates shortest path routes by default  But user also can configure the routes
• 44.
  44/47 What goes upmust come down  Start and stop  How to stop and start the switch • A ping between h_ATL_2 & h_MCI_3 • $ python ovxctl.py –n stopSwitch 2 00:00:00:00:00:00:04:00 • $ python ovxctl.py –n startSwitch 2 00:00:00:00:00:00:04:00
• 45.
  45/47 What goes upmust come down  Clean up  How to remove the host • Want to remove host h_IAH_4 • $ python ovxctl.py –n disconnectHost 2 4 h_SEA_1 h_MCI_3 h_IAH_4 h_ATL_2
• 46.
  46/47 References  http://ovx.onlab.us/getting-started/tutorial/  http://dl.acm.org/citation.cfm?id=2620741
• 47.
  47/47 Q&A  Any Question?