yahoo-eng-team team mailing list archive

[Akihiro Motoki <1964901@xxxxxxxxxxxxxxxxxx>]

The patch in the master branch has been merged. We usually mark it as
"Fix Released" when a fix in the master branch is merged.

** Tags added: ovn

** Changed in: neutron
       Status: Fix Committed => 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/1964901

Title:
  Wrong addition of VIPs to all logical router pods leading to
  triggering GARP on different locations

Status in neutron:
  Fix Released

Bug description:
  When a loadbalancer is created in an OSP tenant network (VIP and
  members), and that tenant networks is connected to a router, which in
  turns is connected to the provider network, the ovn loadbalancer gets
  associated to the ovn logical router. This includes also the cr-lrp
  port (patch port connecting the router and the provider network, in
  OSP world, the router gateway port), and it can be seen by the entry
  on the nat_address of that port, which includes the VIP of the
  loadbalalancer.

  This may cause problems as that means ovn-controller will send GARPs
  for that (internal, tenant network) IP. There is nothing blocking
  different tenants in OSP to create a subnet with the same CIDR and
  then a loadbalancer with the same VIP. If that is the case, there may
  be several ovn-controllers generating GARPs on the provider network
  for the same IP, each one with the MAC of the logical router port
  belonging to each user. This could be a problem for the physical
  network infrastructure.

  
  Steps to Reproduce:
  1. Create a router in OSP and attach it to the provider network
  2. Create a tenant network/subnet and connect it to the router
  3. Create a Load Balancer in OSP, with the VIP in  that tenant network

  Actual results:
  Check the VIP of the loadbalancer is on the OVN SB Port_Binding table, at the nat_addresses of the patch port connecting the router to the provider network:

  datapath            : e3a0a334-9a02-41c7-a64d-6ea747839808
  external_ids        : {"neutron:cidrs"="172.24.100.181/24 2001:db8::f816:3eff:fe77:7f9c/64", "neutron:device_id"="335cd008-216f-4571-a685-b0de5a7ffe50", "neutron:device_owner"="network:router_gateway", "neutron:network_name"=neutron-d923b3db-500d-4241-95be-c3869c72b36a, "neutron:port_name"="", "neutron:project_id"="", "neutron:revision_number"="6", "neutron:security_group_ids"=""}                                                                                                                            
  logical_port        : "add962d2-21ab-4733-b6ef-35538eff25a8"
  mac                 : [router]
  nat_addresses       : ["fa:16:3e:77:7f:9c 172.24.100.181 is_chassis_resident(\"cr-lrp-add962d2-21ab-4733-b6ef-35538eff25a8\")", "fa:16:3e:77:7f:9c 172.24.100.229 *20.0.0.98* 172.24.100.112 is_chassis_resident(\"cr-lrp-add962d2-21ab-4733-b6ef-35538eff25a8\")"]
  options             : {peer=lrp-add962d2-21ab-4733-b6ef-35538eff25a8}
  parent_port         : []
  tag                 : []
  tunnel_key          : 4
  type                : patch
  up                  : false
  virtual_parent      : []

  
  Expected results:
  In the example, ip 20.0.0.98 should not be there as that belongs to an IP in a tenant network that should not be advertized (GARP) in the provider network.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1964901/+subscriptions