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 -- 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
