Public bug reported:
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:
** Affects: neutron
Importance: Undecided
Assignee: Slawek Kaplonski (slaweq)
Status: Confirmed
** Tags: l3-dvr-backlog
--
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:
Confirmed
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
