Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1939563

Summary:	[OVN] Geneve interfaces are created instead of VXLAN when VXLAN is configured
Product:	Red Hat OpenStack	Reporter:	Eduardo Olivares <eolivare>
Component:	openstack-tripleo-heat-templates	Assignee:	Jakub Libosvar <jlibosva>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Eduardo Olivares <eolivare>
Severity:	high	Docs Contact:
Priority:	high
Version:	16.2 (Train)	CC:	apevec, ekuris, ihrachys, jlibosva, kgilliga, lhh, majopela, mburns, rsafrono, scohen, skaplons
Target Milestone:	z3	Keywords:	TestOnly, Triaged
Target Release:	16.2 (Train on RHEL 8.4)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openstack-tripleo-heat-templates-11.5.1-2.20210601074514.90b5312.el8ost.1	Doc Type:	Enhancement
Doc Text:	You can now use the `OVNEncapType` option in TripleO Heat templates. With this enhancement, you can set the VXLAN tunnel protocol for the Networking service (neutron), instead of the default, Geneve. When you specify VXLAN in the `OVNEncapType` option, Open Virtual Network (OVN) uses VXLAN for OpenStack Networking tenant networks.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-02-24 11:42:41 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Eduardo Olivares 2021-03-16 16:08:56 UTC

Description of problem:
A new ovn osp16.2 vxlan job has been created to validate this functionality. Some tests failed on this job, such as test_bw_limit_east_west (see [1]). IMPORTANT: this test verifies qos bw limit functionality, but the test failed before any qos rule was created - it failed with no bw limit configured yet.


We reproduced the issue on an osp virt setup, using two servers connected to a tenant network with icmp, tcp and udp traffic allowed between them (required sec group rules had been created):
- icmp traffic works fine between the two servers
- iperf3 was installed on the servers and both udp and tcp traffic is limited between them - the traffic is not 100% blocked but high packet loss is observed
- same with http traffic between servers
- on the other side, both http and iperf3 from the undercloud (north-south traffic) worked perfectly


Ongoing: running these tests on ovn 16.2 geneve job at [2]



[1] https://rhos-ci-staging-jenkins.lab.eng.tlv2.redhat.com/view/DFG/view/network/view/networking-ovn/job/DFG-network-networking-ovn-16.2_director-rhel-virthost-3cont_2comp-ipv4-vxlan/2/
[2] https://rhos-ci-jenkins.lab.eng.tlv2.redhat.com/view/DFG/view/network/view/networking-ovn/job/DFG-network-networking-ovn-16.2_director-rhel-virthost-3cont_2comp-ipv4-geneve/96/

Version-Release number of selected component (if applicable):
RHOS-16.2-RHEL-8-20210310.n.1

How reproducible:
100%

Steps to Reproduce:
1. create vxlan tenant network
2. create two rhel servers connected to it and add security groups allowing http traffic
3. start httpd on one of them
4. try to download a file from the other one - it fails (awaiting response forever)

Comment 5 Ihar Hrachyshka 2021-04-22 17:10:41 UTC

From an email thread:

Looks like we don't set external-ids:ovn-encap-type anywhere in tripleo-heat-templates, and it defaults to geneve as per puppet-ovn README. We do set ovn::controller::ovn_encap_ip to "get_param:[ServiceNetMap, NeutronTenantNetwork]" in ./deployment/ovn/ovn-controller-container-puppet.yaml though. So probably what's missing is setting ovn-encap-type to something like:

ovn::controller::ovn_encap_type: {get_param: NeutronNetworkType}

though I am not sure if in this environment, NeutronNetworkType is multi-value comma-separated or just 'vxlan' as ovn-controller would expect. If it's multi-value, we may need to convert/strip the value before writing into tripleo config.

So this is probably a tripleo-heat-templates bug where the fix is to set / allow-to-set ovn::controller::ovn_encap_type via a heat option.

Comment 10 OSP Team 2022-02-21 11:41:43 UTC

According to our records, this should be resolved by openstack-tripleo-heat-templates-11.5.1-2.20210603174830.el8ost.10.  This build is available now.