br-tun gets a wrong arp drop rule when dvr is connected to a network but not used as gateway
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Fix Released
|
High
|
Slawek Kaplonski |
Bug Description
Bug reported originally by Takashi Kajinami: https:/
-----------
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=
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:
Changed in neutron: | |
importance: | Undecided → High |
tags: | removed: ocata-backport-potential pike-backport-potential queens-backport-potential |
Fix proposed to branch: master /review. opendev. org/662999
Review: https:/