Bug 1700043
| Summary: | [RHOSP13] OVN-DVR Floating IP is not distributed in each compute nodes and external_mac column not binded with MAC address | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Pradipta Kumar Sahoo <psahoo> |
| Component: | python-networking-ovn | Assignee: | Assaf Muller <amuller> |
| Status: | CLOSED DUPLICATE | QA Contact: | Eran Kuris <ekuris> |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 13.0 (Queens) | CC: | apevec, dalvarez, lhh, lmartins, majopela, nusiddiq, psahoo, rsafrono, scohen |
| Target Milestone: | --- | Flags: | rsafrono:
automate_bug+
|
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-05-07 10:00:55 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: | |||
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 *** |
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