Support for multiple VTEP in OVN

OVN uses tunnels to achieve logical network connectivity. The tunnel IP
to be used when communicating with a node is configured using an external_ids
field called "ovn-encap-ip" (and "ovn-encap-type" to indicate the type of
tunnel - geneve, vxlan, stt).

The fact that "ovn-encap-ip" is a single IP is significantly limiting when
used in certain scenarios. Primarly, if we have multiple NICs on a system and
want to assign SR-IOV VFs from different NICs to a guest (as logical ports),
then we'll still end up using the "ovn-encap-ip" to encapsulate traffic from
different VFs. This means we'll end up using only one NIC on the
physical, thereby not maintaining the VF-PF association while also not using
all the physical NICs. It is possible to bond all the NICs and use the
bond IP as the "encap-ip", but bonding multiple NICs has its own limitations,
i.e. NICs supporting OVS flows offload don't work with bonding - this
severly undermines SR-IOV use with OVS (i.e. if all the processing needs
to be done in the host despite giving VFs to guests).

    +-------------------------------------------------------+       +-------------------------~
    |Hypervisor I   (chassis-ID = HV1)                      |       |Hypervisor II
    |                                                       |       |
    |+----------------------+                               |       |
    ||      guest           |                               |       |
    ||                      |                               |       |
    |+-------|----------|---+                               |       | (ovn-chassis-id)
    |        |          |           vf0_rep +-------+       |       |               +-------+
    |        |          |      encap-ip=IP1 |       |       |       |     (HV1@IP1) |       |
    |        |------------------------------|       |-------------------------------|       |
    |        |          |                   |br-int |       |       |               |br-int |
    |        |          |           vf0_rep |       |       |       |     (HV1@IP2) |       |
    |        |          |      encap-ip=IP2 |       |-------------------------------|       |
    |        |          |-------------------|       |       |   |   |               +-------+
    |        |          |                   +-------+       |   |   |
    |        |vf0       |vf0                                |   |   |
    |   +---------+  +---------+                            |   |   |
    +---|  nic1   |--|  nic2   |----------------------------+   |   +--------------------------~
        +---------+  +---------+                                V
            |           |                                  Tunnel Ports
            |pf=IP1     |pf=IP2                         between Hypervisors.

Note: The above uses a NIC that supports OVS with SR-IOV (e.g. Mellanox CX-5) which
uses a "representor" to plug in a VF to the OVS bridge.

This patch enables a list of comma separated IP addresses to be specified in
"ovn-encap-ip", thus allowing the node to be reached via any IP combined with the
"ovn-encap-type" - assuming physical routing allows that. Additionally, it also
introduces an way to specify the encap IP to be used for a logical port (so that
the VF-PF mapping is maintained when traversing the logical path over
a tunnel). A new "encap-ip" external_ids can be configured on an
Interface to indicate this.

On the SB these changes appear as an additional column in port_bindings
as "encap". The encap record for a port points to an encap record
on its chassis. If the port is not explicitly associated with an
encap-ip (using external_ids), the encap record is empty, which
means the preferred tunnel will be used to reach the port's chassis.

The intention is also to have no functional changes in the default case, i.e
when there is only one "ovn-encap-ip".

The changes have been tested with multiple encap-ip addresses, SR-IOV and
for backwards compatibality (in the case where there is only one ovn-encap-ip)
with an OVN SB that doesn't include these changes.

1 files changed, 8 insertions, 1 deletions

diff --git a/tests/ovn-controller.at b/tests/ovn-controller.at
index 13e88a0cc..92b656a53 100644
--- a/tests/ovn-controller.at
+++ b/tests/ovn-controller.at
@@ -206,7 +206,14 @@ ovn-sbctl chassis-add fakechassis stt 192.168.0.2
 OVS_WAIT_UNTIL([check_tunnel_property type stt])
 
 # See if we switch to Geneve as the first choice when it is available
-encap_uuid=$(ovn-sbctl add chassis fakechassis encaps @encap -- --id=@encap create encap type=geneve ip="127.0.0.1")
+# With multi-VTEP support we support tunnels with different IPs to the
+# same chassis, and hence use the IP to annotate the tunnel (along with
+# the chassis-id in ovn-chassis-id); if we supply a different IP here
+# we won't be able to co-relate this to the tunnel port that was created
+# in the previous step and, as a result, will end up creating another tunnel,
+# ie. we can't just lookup using "ovn-fakech-0". So, need to use the same IP
+# as above, i.e 192.168.0.2, here.
+encap_uuid=$(ovn-sbctl add chassis fakechassis encaps @encap -- --id=@encap create encap type=geneve ip="192.168.0.2")
 OVS_WAIT_UNTIL([check_tunnel_property type geneve])
 
 # Check that changes within an encap row are propagated