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

Bug 1714422

Summary: br-tun gets a wrong arp drop rule when dvr is connected to a network but not used as gateway
Product: Red Hat OpenStack Reporter: Takashi Kajinami <tkajinam>
Component: openstack-neutronAssignee: Slawek Kaplonski <skaplons>
Status: CLOSED ERRATA QA Contact: Candido Campos <ccamposr>
Severity: urgent Docs Contact:
Priority: medium    
Version: 13.0 (Queens)CC: amuller, chrisw, nate.johnston, scohen, skaplons
Target Milestone: z8Keywords: Triaged, ZStream
Target Release: 13.0 (Queens)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openstack-neutron-12.0.6-4.el7ost Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1718360 (view as bug list) Environment:
Last Closed: 2019-09-03 16:53:02 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:
Bug Depends On:    
Bug Blocks: 1718360    

Description Takashi Kajinami 2019-05-28 05:18:34 UTC 
Description of problem:

When we have dvr connected to a network, br-tun get a filter rule in ovs flow,
to drop arp packet going to router gateway.

cookie=0x..., duration=...s, table=1, n_packets=..., n_bytes=..., idle_age=..., priority=3,arp,dl_vlan=...,arp_tpa=<gateway ip> actions=drop

However, the target ip that filter is not decided based on the real interface ip in dvr,
but based on gateway ip specified for the network.

When you have one non-dvr and dvr in the same network, with using non-dvr as the gateway
of the network, this causes issue on connectivity via non-dvr as the said ovs flow
block arp packet to the gateway ip.
For example, in the following case, we should have a filter about arp for 192.168.0.10
on br-tun, but in fact we have the one for 192.168.0.1.

 non-dvr - [192.168.0.1] - network(with gateway 192.168.0.1) - [192.168.0.10] - dvr
 

Version-Release number of selected component (if applicable):
RHOSP13z4

How reproducible:
Always

Steps to Reproduce:
1. Create a network and subnet
2. Create a virtual router with distributed=False and connect it to the subnet as gateway
3. Create a virtual router with distributed=True and connect it to the subnet
4. Launch a instance connected to the instance, and try ping to gateway on non-dvr

Actual results:

All ping packets are lost

Expected results:

Ping succeeds without any error

Additional info:
Comment 1 Takashi Kajinami 2019-05-28 08:48:11 UTC 
I checked current neutron code in stable/queens and see that when dvr is connected to
a subnet, it installs filter rule about arp going for subnet gateway.

neutron/plugins/ml2/drivers/openvswitch/agent/ovs_dvr_neutron_agent.py
~~~
346     def _bind_distributed_router_interface_port(self, port, lvm,
347                                                 fixed_ips, device_owner):
...
418         # TODO(vivek) remove the IPv6 related flows once SNAT is not
419         # used for IPv6 DVR.
420         if ip_version == 4:
421             if subnet_info['gateway_ip']:
422                 br.install_dvr_process_ipv4(
423                     vlan_tag=lvm.vlan, gateway_ip=subnet_info['gateway_ip']) <===HERE
424         else:
425             br.install_dvr_process_ipv6(
426                 vlan_tag=lvm.vlan, gateway_mac=subnet_info['gateway_mac'])
427         br.install_dvr_process(
428             vlan_tag=lvm.vlan, vif_mac=port.vif_mac,
429             dvr_mac_address=self.dvr_mac_address)
~~~
Comment 18 errata-xmlrpc 2019-09-03 16:53:02 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2629