[ovs-git] [openvswitch/ovs] 38a85a: ovn: Add a new logical switch port type - 'virtual'

numansiddique noreply at github.com
Fri Aug 2 00:49:30 UTC 2019

  Branch: refs/heads/branch-2.12
  Home:   https://github.com/openvswitch/ovs
  Commit: 38a85a041dd89933850f52a84d3896c9b602536a
  Author: Numan Siddique <nusiddiq at redhat.com>
  Date:   2019-08-01 (Thu, 01 Aug 2019)

  Changed paths:
    M NEWS
    M include/ovn/actions.h
    M ovn/controller/binding.c
    M ovn/controller/pinctrl.c
    M ovn/lib/actions.c
    M ovn/lib/ovn-util.c
    M ovn/northd/ovn-northd.8.xml
    M ovn/northd/ovn-northd.c
    M ovn/ovn-nb.xml
    M ovn/ovn-sb.ovsschema
    M ovn/ovn-sb.xml
    M ovn/utilities/ovn-trace.c
    M tests/ovn.at
    M tests/test-ovn.c

  Log Message:
  ovn: Add a new logical switch port type - 'virtual'

This new type is added for the following reasons:

  - When a load balancer is created in an OpenStack deployment with Octavia
    service, it creates a logical port 'VIP' for the virtual ip.

  - This logical port is not bound to any VIF.

  - Octavia service creates a service VM (with another logical port 'P' which
    belongs to the same logical switch)

  - The virtual ip 'VIP' is configured on this service VM.

  - This service VM provides the load balancing for the VIP with the configured
    backend IPs.

  - Octavia service can be configured to create few service VMs with active-standby mode
    with the active VM configured with the VIP.  The VIP can move between
    these service nodes.

Presently there are few problems:

  - When a floating ip (externally reachable IP) is associated to the VIP and if
    the compute nodes have external connectivity then the external traffic cannot
    reach the VIP using the floating ip as the VIP logical port would be down.
    dnat_and_snat entry in NAT table for this vip will have 'external_mac' and
    'logical_port' configured.

  - The only way to make it work is to clear the 'external_mac' entry so that
    the gateway chassis does the DNAT for the VIP.

To solve these problems, this patch proposes a new logical port type - virtual.
CMS when creating the logical port for the VIP, should

 - set the type as 'virtual'

 - configure the VIP in the options - Logical_Switch_Port.options:virtual-ip

 - And set the virtual parents in the options
   These virtual parents are the one which can be configured with the VIP.

If suppose the virtual_ip is configured to on a virtual logical port 'sw0-vip'
and the virtual_parents are set to - [sw0-p1, sw0-p2] then below logical flows are added in the
lsp_in_arp_rsp logical switch pipeline

 - table=11(ls_in_arp_rsp), priority=100,
   match=(inport == "sw0-p1" && !is_chassis_resident("sw0-vip") &&
          ((arp.op == 1 && arp.spa == && arp.tpa == ||
           (arp.op == 2 && arp.spa ==,
   action=(bind_vport("sw0-vip", inport); next;)
- table=11(ls_in_arp_rsp), priority=100,
   match=(inport == "sw0-p2" && !is_chassis_resident("sw0-vip") &&
          ((arp.op == 1 && arp.spa == && arp.tpa == ||
           (arp.op == 2 && arp.spa ==,
   action=(bind_vport("sw0-vip", inport); next;)

The action bind_vport will claim the logical port - sw0-vip on the chassis where this action
is executed. Since the port - sw0-vip is claimed by a chassis, the dnat_and_snat rule for
the VIP will be handled by the compute node.

Co-authored-by: Ben Pfaff <blp at ovn.org>
Signed-off-by: Ben Pfaff <blp at ovn.org>
Acked-by: Gurucharan Shetty <guru at ovn.org>
Acked-by: Mark Michelson <mmichels at redhat.com>
Signed-off-by: Numan Siddique <nusiddiq at redhat.com>

(cherry picked from ovn commit 054f4c85c413e20d893e10ba053ec52ac15db49c)

Signed-off-by: Gurucharan Shetty <guru at ovn.org>

More information about the git mailing list