Bug 1077211

Summary: [RFE] Neutron Integration: Add support for VXLAN and GRE tunneling
Product: [oVirt] ovirt-engine Reporter: Nir Yechiel <nyechiel>
Component: RFEsAssignee: Nir Yechiel <nyechiel>
Status: CLOSED WONTFIX QA Contact: Meni Yakove <myakove>
Severity: medium Docs Contact:
Priority: unspecified    
Version: ---CC: bugs, ch_free, gfa, howey.vernon, lpeer, nyechiel, rbalakri, srevivo, ylavi
Target Milestone: ---Keywords: FutureFeature
Target Release: ---Flags: ylavi: ovirt-future?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-06-06 07:28:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Network RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1063716    

Description Nir Yechiel 2014-03-17 13:24:30 UTC 
Description of the feature request:
===================================

As part of the Neutron integration we would like to leverage the ability to utilize Overlay Networks with GRE and VXLAN as the encapsulation protocol, instead of using 802.1Q VLANs to isolate VM traffic.

Both GRE and VXLAN are supported by Open vSwitch, thus the Open vSwitch resides on the hypervisors can act as the software termination of the overlay tunnels. 


There are two main use cases for RHEV:

1) Isolated logical networks - The VM end-point, once configured on an overlay segment, cannot communicate with any other non-overlay network. This can be used to provision "isolated" logical network that can provide internal L2 connectivity to VMs running on different hypervisors. This is a capability we don't have today, where anything related to host-to-host communication must involve VLAN configuration and interaction with the hardware switches as well. Note that in this use case no external connectivity is required.

2) A replacement for VLAN in the DC - In this use case the overlay networks will be used instead of 802.1Q VLAN to isolate VM traffic in the environment. The main benefits here are:

- Hypervisors are no longer need to be located on the same VLAN/IP subnet
- Minimum interactions is required with the physical network infrastructure
- The 4K scale limitation of VLAN is gone

The challenge here is how to provide external connectivity to the VMs which resides within the overlay network. As stated in the first use case described above, the VM end-point, once configured on an overlay segment, cannot communicate with any other non-overlay network. This requires a GW device that should be able to encapsulate and decapsulate the overlay header and translate it to native IP/802.1Q VLAN in order to communicate with non-overlay networks/existing devices in the DC. This can be achieved by introducing virtual L3 routers that will serve as D.G for the VMs and will handle the connectivity with anything outside of the overlay.
Comment 1 Nir Yechiel 2014-03-17 13:31:35 UTC 
Preliminary info can be found in this link: 
http://www.ovirt.org/OVirt_Neutron_GRE_Integration_-_How_To 

which shows how to manually implement the first use case (isolated logical networks) using the current integration bits.

This RFE should bring full support of the feature, including the option to configure and monitor the networks from within the Web Admin UI.
Comment 2 Nir Yechiel 2014-07-17 11:12:10 UTC 
*** Bug 1061209 has been marked as a duplicate of this bug. ***
Comment 6 Yaniv Lavi 2018-06-06 07:28:39 UTC 
Closing old RFEs, please reopen if still needed.
Patches are always welcomed.