yahoo-eng-team team mailing list archive

[Slawek Kaplonski <1831575@xxxxxxxxxxxxxxxxxx>]

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