Reviewed: https://review.opendev.org/662999 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=ae3aa28f5a4749b4e4cb3f0ae0d009c0734db405 Submitter: Zuul Branch: master
commit ae3aa28f5a4749b4e4cb3f0ae0d009c0734db405 Author: Slawek Kaplonski <[email protected]> Date: Tue Jun 4 12:14:37 2019 +0200 [DVR] Block ARP to dvr router's port instead of subnet's gateway It may happen that subnet is connected to dvr router using IP address different than subnet's gateway_ip. So in br-tun arp to dvr router's port should be dropped instead of dropping arp to subnet's gateway_ip (or mac in case of IPv6). Change-Id: Ida6b7ae53f3fc76f54e389c5f7131b5a66f533ce Closes-bug: #1831575 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1831575 Title: br-tun gets a wrong arp drop rule when dvr is connected to a network but not used as gateway Status in neutron: Fix Released Bug description: Bug reported originally by Takashi Kajinami: https://bugzilla.redhat.com/show_bug.cgi?id=1714422 ----------- 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 - I checked on u/s master branch and it is the same 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: To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1831575/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
