Bug 1700043 - [RHOSP13] OVN-DVR Floating IP is not distributed in each compute nodes and external_mac column not binded with MAC address
Summary: [RHOSP13] OVN-DVR Floating IP is not distributed in each compute nodes and ex...
Keywords:
Status: CLOSED DUPLICATE of bug 1674560
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-networking-ovn
Version: 13.0 (Queens)
Hardware: x86_64
OS: All
urgent
urgent
Target Milestone: ---
: ---
Assignee: Assaf Muller
QA Contact: Eran Kuris
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-15 16:35 UTC by Pradipta Kumar Sahoo
Modified: 2019-09-09 14:30 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-07 10:00:55 UTC
Target Upstream Version:
Embargoed:
rsafrono: automate_bug+


Attachments (Terms of Use)

Description Pradipta Kumar Sahoo 2019-04-15 16:35:50 UTC
Description of problem:
	OVN-DVR Floating IP is not distributed in each compute nodes and external_mac column not bind with MAC address

Version-Release number of selected component (if applicable):
Red Hat OpenStack 13

How reproducible: 100% in lab and customer environment


Steps to Reproduce:
1. In RHOSP13, OVN-DVR-HA scenario, by default the external gw chassis set to controller nodes for SNAT and DNAT communication floating IP communication. To achive the DVR 

	$ grep -B1 OVNCMSOptions /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-ovn-dvr-ha.yaml
	  ControllerParameters:
	    OVNCMSOptions: "enable-chassis-as-gw"

2. To acomplish the DVR usecase in compute, I explictly forced my external gw chassis to compute nodes and it works as expected where in the post deployment my compute chasis has set to external gw.

	Ex: Currently br-ex is serving the external network(FIP).
	@ovn-compute-1 ~]# ovs-vsctl get open . external_ids
	{hostname="ovn-compute-1.localdomain", ovn-bridge=br-int, ovn-bridge-mappings="provider1:br-provider1,provider2:br-provider2,provider3:br-provider3,external:br-ex", ovn-cms-options=enable-chassis-as-gw, ovn-encap-ip="10.74.167.41", ovn-encap-type=geneve, ovn-remote="tcp:10.74.167.47:6642", rundir="/var/run/openvswitch", system-id="c53ed2be-e2f9-4008-9eaa-4211641d0f00"}

	# ovs-vsctl get open . external_ids
	{hostname="ovn-compute-0.localdomain", ovn-bridge=br-int, ovn-bridge-mappings="provider1:br-provider1,provider2:br-provider2,provider3:br-provider3,external:br-ex", ovn-cms-options=enable-chassis-as-gw, ovn-encap-ip="10.74.167.42", ovn-encap-type=geneve, ovn-remote="tcp:10.74.167.47:6642", rundir="/var/run/openvswitch", system-id="fdf219ac-1cab-434b-8bfe-0b3560c23b1c"}


3. In OVN north db the gateway chassis with below priority.

# ovn-sbctl --db=$SB list Gateway_Chassis
_uuid               : c4d4bffe-0bd8-4f63-962a-80e6a127d670
chassis             : 44487aae-e792-4b03-ae63-7fa601e62415
external_ids        : {}
name                : "lrp-ef37243a-ac26-4c00-8c84-ebd90d6bb373_c53ed2be-e2f9-4008-9eaa-4211641d0f00"
options             : {}
priority            : 2

_uuid               : 50556ad3-050c-4764-b8b8-484b6d7fad50
chassis             : 7538a2bc-6224-436c-a80b-7128bcfc92f3
external_ids        : {}
name                : "lrp-ef37243a-ac26-4c00-8c84-ebd90d6bb373_fdf219ac-1cab-434b-8bfe-0b3560c23b1c"
options             : {}
priority            : 1


4. I spawned two instance and attach floating IP network into it. Since the compute chassis "44487aae-e792-4b03-ae63-7fa601e62415" set with priority 2, all external traffic included other vm(with FIP) running on another compute chassis "7538a2bc-6224-436c-a80b-7128bcfc92f3" is also redirected to following gateway chassis "lrp-ef37243a-ac26-4c00-8c84-ebd90d6bb373_c53ed2be-e2f9-4008-9eaa-4211641d0f00". which is not accomplish the DVR scenario.

5. For intial level of troubleshooting, I verified floating IP mapping dnat_and_snat cloumn in NAT tables and I noticed the "external_mac" address is not binded with any mac addess here.

	# ovn-nbctl --db=$NB find NAT type=dnat_and_snat
	_uuid               : c5a70d78-781b-4ae3-ac52-792f174194d1
	external_ids        : {"neutron:fip_external_mac"="fa:16:3e:b6:b2:1f", "neutron:fip_id"="5f8ceca6-3689-4fd9-b2d9-5fdbf2e406c5", "neutron:fip_port_id"="a7bdf440-4a37-4ffc-a4da-9a5896fafa55", "neutron:revision_number"="2", "neutron:router_name"="neutron-075ef62e-34d2-4c65-86f7-6862bec89321"}
	external_ip         : "10.74.167.212"
	external_mac        : []
	logical_ip          : "192.168.2.28"
	logical_port        : "a7bdf440-4a37-4ffc-a4da-9a5896fafa55"
	type                : dnat_and_snat

	_uuid               : dbee445f-8556-41df-b97d-7057c3edbe1f
	external_ids        : {"neutron:fip_external_mac"="fa:16:3e:98:db:2d", "neutron:fip_id"="db57ea85-8d48-433f-8ad2-e32edad325d8", "neutron:fip_port_id"="45b37972-88ad-4f9f-884d-50120fcebc39", "neutron:revision_number"="2", "neutron:router_name"="neutron-075ef62e-34d2-4c65-86f7-6862bec89321"}
	external_ip         : "10.74.167.210"
	external_mac        : []
	logical_ip          : "192.168.1.6"
	logical_port        : "45b37972-88ad-4f9f-884d-50120fcebc39"
	type                : dnat_and_snat


	# ovn-nbctl --db=$NB lr-nat-list neutron-075ef62e-34d2-4c65-86f7-6862bec89321
	TYPE             EXTERNAL_IP        LOGICAL_IP            EXTERNAL_MAC         LOGICAL_PORT
	dnat_and_snat    10.74.167.210      192.168.1.6
	dnat_and_snat    10.74.167.212      192.168.2.28
	snat             10.74.167.213      192.168.2.0/24
	snat             10.74.167.213      192.168.1.0/24

6. As a troubleshooting procedure, I assigned a random mac address to external_mac. After do this the DNAT is not function and I am unable to ping the floating IP from outside.

	# ovn-nbctl --db=$NB set nat c5a70d78-781b-4ae3-ac52-792f174194d1 external_mac=\"fb:17:3e:b6:b2:1f\"

	# ovn-nbctl --db=$NB find NAT type=dnat_and_snat
	_uuid               : c5a70d78-781b-4ae3-ac52-792f174194d1
	external_ids        : {"neutron:fip_external_mac"="fa:16:3e:b6:b2:1f", "neutron:fip_id"="5f8ceca6-3689-4fd9-b2d9-5fdbf2e406c5", "neutron:fip_port_id"="a7bdf440-4a37-4ffc-a4da-9a5896fafa55", "neutron:revision_number"="2", "neutron:router_name"="neutron-075ef62e-34d2-4c65-86f7-6862bec89321"}
	external_ip         : "10.74.167.212"
	external_mac        : "fb:17:3e:b6:b2:1f"
	logical_ip          : "192.168.2.28"
	logical_port        : "a7bdf440-4a37-4ffc-a4da-9a5896fafa55"
	type                : dnat_and_snat

	# ovn-nbctl --db=$NB lr-nat-list neutron-075ef62e-34d2-4c65-86f7-6862bec89321
	TYPE             EXTERNAL_IP        LOGICAL_IP            EXTERNAL_MAC         LOGICAL_PORT
	dnat_and_snat    10.74.167.210      192.168.1.6
	dnat_and_snat    10.74.167.212      192.168.2.28          fb:17:3e:b6:b2:1f    a7bdf440-4a37-4ffc-a4da-9a5896fafa55
	snat             10.74.167.213      192.168.2.0/24
	snat             10.74.167.213      192.168.1.0/24


Actual results:
The lrp port scheduled on one compute chassis whcih will not acmplish the DVR usecase if the instance has spawned in different compute chassis and binded with FIP.

Expected results:
The SNAT & DNAT should work on the same compute where the instance has spawnned, and the external traffic should route to other compute chassis.

Additional info:

Also, please clarify below pointers.

1. What could be the reason the default external gateway chassis set to controller node in neutron-ml2-ovn-dvr-ha.yaml enviroment file?
2. Why external_mac column has not binded with MAC addres, If it bind then what MAC it should bind or any random MAC address should work.
3. What is recommondation to configure OVN-DVR in Compute node and how lrp-xx port should distributed to respective compute where associated VMs are running.


PS: Please let me know if you need any additional information on it.

Regards,
Pradipta

Comment 10 Pradipta Kumar Sahoo 2019-05-09 04:28:40 UTC
Hi Daniel,

Thank you for the update. Now I upgraded the OSP13 environment to z6 with updated "python2-ovsdbapp-0.10.3-1.el7ost.noarch" and verified that default OVN-DVR-HA integration the floating IP (snat_dnat) communicated via compute node and Without Fip the SNAT traffic traversed by Controller node. 

# ovn-nbctl lr-nat-list neutron-5cc4530a-23b3-4c3a-973e-52c3531ef55a
TYPE             EXTERNAL_IP        LOGICAL_IP            EXTERNAL_MAC         LOGICAL_PORT
dnat_and_snat    10.74.167.211      192.168.1.6           fa:16:3e:94:8e:89    755413fa-fd8d-4e4f-bcdb-bd9e69b12268
snat             10.74.167.218      192.168.2.0/24
snat             10.74.167.218      192.168.1.0/24


Regards,
Pradipta

*** This bug has been marked as a duplicate of bug 1674560 ***


Note You need to log in before you can comment on or make changes to this bug.