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:
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) ~~~
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