Reviewed: https://review.openstack.org/598677 Committed: https://git.openstack.org/cgit/openstack/networking-bagpipe/commit/?id=3867733d640fff4d70288ce845173c86b2b0b8af Submitter: Zuul Branch: master
commit 3867733d640fff4d70288ce845173c86b2b0b8af Author: Thomas Morin <thomas.mo...@orange.com> Date: Fri Aug 31 14:11:12 2018 +0200 bgpvpn: override NORMAL action in ACCEPTED_EGRESS_TRAFFIC_NORMAL_TABLE Bug 1789878 describes why the current implementation of traffic redirection for router fallback has been defeated by change Ib6ced838a7ec6d5c459a8475318556001c31bdf which was brought in the neutron ovs firewalling code. This change moves the place where we put a higher priority rule to override the NORMAL action to the ACCEPTED_EGRESS_TRAFFIC_NORMAL_TABLE, which is added by I60d299275effd9ef35c8007773d3c9fcabfa50fa to re-introduce a single table where NORMAL happens for egress traffic. To allow this change to pass the lower-constraints requirement check job is temporarily set to non-voting, because this job does not seem to be able to take into account the fact that the master branch needs neutron master. Change-Id: I8923ca9583b3337556aaf98b4f25732ea6b7bb1c Depends-On: https://review.openstack.org/598593 Closes-Bug: 1789878 ** Changed in: networking-bagpipe 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/1789878 Title: bgpvpn router fallback broken by change in neutron openvswitch firewall Status in networking-bgpvpn: Confirmed Status in BaGPipe: Fix Released Status in neutron: In Progress Bug description: This issue impacts current master, stable/rocky and stable/queens. The first symptom is that we have seen failures of many tests from legacy-tempest-dsvm-networking-bgpvpn-bagpipe since the merge of [1] in neutron code (August 14th). Background: networking-bagpipe code for BGPVPN has a "router fallback" mechanism: in cases where a network is at the same time connected to a Router and associated to a BGPVPN, the traffic sent by a VM to its gateway is redirected to br-mpls to attempt BGPVPN route matching, before eventually being sent, as a fallback, to the neutron netns router if it did no VPN route was matched in br-mpls. For this mechanism to work, a rule is in place in table 91 to override the NORMAL action (which would result in flood/learn) for the traffic destinated to the gateway MAC address, with a higher priority rule that sends the traffic to br-tun instead (br-tun is where the redirection to br-mpls takes place): cookie=0x8b0cf47ac991c941, duration=5371.870s, table=91, n_packets=217, n_bytes=21266, priority=2,reg6=0x18,dl_dst=fa:16:3e:c5:89:72 actions=mod_vlan_vid:24,output:"patch-tun" cookie=0x89f8a81c314f2696, duration=71265.896s, table=91, n_packets=338, n_bytes=27094, priority=1 actions=NORMAL (above, fa:16:3e:c5:89:72 is the gateway MAC address for the network with vlan_id 24) Analysis of the issue: Change [1] modified some rules that were resubmiting to table 91, to instaead use a NORMAL action, resulting in only the first packets (from a conntrack standpoint) to reach table 91. This prevents the redirection of traffic to br-tun,br-mpls. The tricky thing is that the issue does not always occurs: when there is no entry in the MAC leaning table (ovs-appctl fdb/show br-int) for the gateway MAC, the traffic is flooded and eventually reaches br-tun,br-mpls . This explains why some tests, but not all tests, fail. (not also that the tests where no Router is used in the destination network do not seem to fail.) [1] https://review.openstack.org/#/q/Ib6ced838a7ec6d5c459a8475318556001c31bdf To manage notifications about this bug go to: https://bugs.launchpad.net/bgpvpn/+bug/1789878/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp