yahoo-eng-team team mailing list archive

[Sami Yessou <2123848@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Hi Everyone!

Recently we are facing an issue with octavia-ovn-provider due to our
specific setup, to give more context we are using the following:

Customer A wants to use a dedicated appliance inside his network to forward traffic to the outside world (e.g. 192.168.10.1 instead of Openstack virtual router), so they set the default gateway of the subnet to 192.168.10.1 (which is the dedicated appliance device)
The customer wants to use Octavia LBs with private VIP (192.168.10.x)

Openstack version: Caracal and Antelope (code seems the same also in master)
Can be replicated with Devstack

What we saw is that when ever we create the subnet with a specific port
here below the commands to replicate it:

```
openstack subnet create --network "shared network" --subnet-range "192.168.10.0/24" --allocation-pool start=192.168.10.10,end=192.168.10.200 --dhcp subnet 

openstack port create --fixed-ip subnet=subnet,ip-address=192.168.10.2
--network "shared network" internal_port_router_workaround

openstack router add port router-terraform internal_port_router_workaround
```


The created loadbalancer would not be reachable due to a specific condition on the codebase which requires that the port IP is equivalent to the subnet gateway IP, here below the reference of it:

https://github.com/openstack/ovn-octavia-
provider/commit/feb5ac89af684f724ccda0c74a908438ce1f48e7#diff-e533b994f9a708045fefd5ef3b897fa16acc209a460572c3b9af80d712ce9433R799


Thus creating a load balancer we get the following:
```
openstack loadbalancer create --provider ovn  --name lb1 --vip-subnet-id subnet

ovn-nbctl find logical_router  "name=neutron-2d35e699-6fd0-428d-a0d1-b15fd8c4828f" | grep load_balancer
load_balancer       : []
load_balancer_group : []
```


The field load_balancer is empty on the nb database making unreachable
the loadbalancer, in order to fix that potential work arounds are:

Set default static route on the virtual router 192.168.10.2 to point to the firewall 192.168.10.1, and use 192.168.10.2 as default gateway for the subnet
Set static routes on each VM inside the shared network so VMs can reach directly the firewall (requires automation or cloud-init integration)


Later on to make the loadbalancer creation work again we did the following:
```
openstack subnet set --gateway 192.168.10.2 subnet

openstack loadbalancer create --provider ovn  --name lb2 --vip-subnet-id
subnet

ovn-nbctl find logical_router  "name=neutron-2d35e699-6fd0-428d-a0d1-b15fd8c4828f" | grep load_balancer
load_balancer       : [a6fd8537-eff3-4def-a5e3-e6dacb8bb901]
load_balancer_group : [] 
```

We were discussing internally if that is the expected behaviour of
Openstack or if this can be potentially improved to allow this specific
use-case

Thank you for your time!

** Affects: neutron
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2123848

Title:
  [ovn-octavia-provider] Octavia LB not reachable with custom firewall
  appliance

Status in neutron:
  New

Bug description:
  Hi Everyone!

  Recently we are facing an issue with octavia-ovn-provider due to our
  specific setup, to give more context we are using the following:

  Customer A wants to use a dedicated appliance inside his network to forward traffic to the outside world (e.g. 192.168.10.1 instead of Openstack virtual router), so they set the default gateway of the subnet to 192.168.10.1 (which is the dedicated appliance device)
  The customer wants to use Octavia LBs with private VIP (192.168.10.x)

  Openstack version: Caracal and Antelope (code seems the same also in master)
  Can be replicated with Devstack

  What we saw is that when ever we create the subnet with a specific
  port here below the commands to replicate it:

  ```
  openstack subnet create --network "shared network" --subnet-range "192.168.10.0/24" --allocation-pool start=192.168.10.10,end=192.168.10.200 --dhcp subnet 

  openstack port create --fixed-ip subnet=subnet,ip-address=192.168.10.2
  --network "shared network" internal_port_router_workaround

  openstack router add port router-terraform internal_port_router_workaround
  ```

  
  The created loadbalancer would not be reachable due to a specific condition on the codebase which requires that the port IP is equivalent to the subnet gateway IP, here below the reference of it:

  https://github.com/openstack/ovn-octavia-
  provider/commit/feb5ac89af684f724ccda0c74a908438ce1f48e7#diff-e533b994f9a708045fefd5ef3b897fa16acc209a460572c3b9af80d712ce9433R799

  
  Thus creating a load balancer we get the following:
  ```
  openstack loadbalancer create --provider ovn  --name lb1 --vip-subnet-id subnet

  ovn-nbctl find logical_router  "name=neutron-2d35e699-6fd0-428d-a0d1-b15fd8c4828f" | grep load_balancer
  load_balancer       : []
  load_balancer_group : []
  ```


  The field load_balancer is empty on the nb database making unreachable
  the loadbalancer, in order to fix that potential work arounds are:

  Set default static route on the virtual router 192.168.10.2 to point to the firewall 192.168.10.1, and use 192.168.10.2 as default gateway for the subnet
  Set static routes on each VM inside the shared network so VMs can reach directly the firewall (requires automation or cloud-init integration)

  
  Later on to make the loadbalancer creation work again we did the following:
  ```
  openstack subnet set --gateway 192.168.10.2 subnet

  openstack loadbalancer create --provider ovn  --name lb2 --vip-subnet-
  id subnet

  ovn-nbctl find logical_router  "name=neutron-2d35e699-6fd0-428d-a0d1-b15fd8c4828f" | grep load_balancer
  load_balancer       : [a6fd8537-eff3-4def-a5e3-e6dacb8bb901]
  load_balancer_group : [] 
  ```

  We were discussing internally if that is the expected behaviour of
  Openstack or if this can be potentially improved to allow this
  specific use-case

  Thank you for your time!

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