[ovs-build] Still Failing: ovn-org/ovn#56 (master - edb2400)

[Travis CI]

Build Update for ovn-org/ovn
-------------------------------------

Build: #56
Status: Still Failing

Duration: 15 mins and 41 secs
Commit: edb2400 (master)
Author: Manoj Sharma
Message: Forwarding group to load balance l2 traffic with liveness detection

A forwarding group is an aggregation of logical switch
ports of a logical switch to load balance traffic across the ports. It also
detects the liveness if the logical switch ports are realized as OVN tunnel
ports on the physical topology.

In the below logical topology diagram, the logical switch has two ports
connected to chassis / external routers R1 and R2. The logical router needs
to send traffic to an external network that is connected through R1 and R2.

                                                    +----+
                                         +----------+ R1 |    *****
                                        /           +----+  **     **
  +----------+        +--------------+ / lsp1              *         *
  | Logical  |        |   Logical    |/                   * External  *
  | Router   +--------+   switch     X                    *  Network  *
  |          |        |              |\                   *           *
  +----------+        +--------------+ \ lsp2              *         *
                             ^          \           +----+  **     **
                             |           +----------+ R2 |    *****
                             |                      +----+
                   fwd_group -> (lsp1, lsp2)

In the absence of forwarding group, the logical router will have unicast
route to point to either R1 or R2. In case of R1 or R2 going down, it will
require control plane's intervention to update the route to point to proper
nexthop.

With forwarding group, a virtual IP (VIP) and virtual MAC (VMAC) address
are configured on the forwarding group. The logical router points to the
forwarding group's VIP as the nexthop for hosts behind R1 and R2.

[root at fwd-group]# ovn-nbctl fwd-group-add fwd ls1 VIP_1 VMAC_1 lsp1 lsp2

[root at fwd-group]# ovn-nbctl fwd-group-list
FWD_GROUP       LS            VIP             VMAC          CHILD_PORTS
fwd             ls1          VIP_1           VMAC_1         lsp1 lsp2

[root at fwd-group]# ovn-nbctl lr-route-list lr1
IPv4 Routes
external_host_prefix/prefix_len            VIP_1 dst-ip

The logical switch will install an ARP responder rule to reply with VMAC
as the MAC address for ARP requests for VIP. It will also install a MAC
lookup rule for VMAC with action to load balance across the logical switch
ports of the forwarding group.

Datapath: "ls1" Pipeline: ingress
table=10(ls_in_arp_rsp      ), priority=50   , match=(arp.tpa == VIP_1 &&
    arp.op == 1), action=(eth.dst = eth.src; eth.src = VMAC_1; arp.op = 2;
    /* ARP reply */ arp.tha = arp.sha; arp.sha = VMAC_1; arp.tpa = arp.spa;
    arp.spa = VIP; outport = inport; flags.loopback = 1; output;)

table=13(ls_in_l2_lkup      ), priority=50   , match=(eth.dst == VMAC_1),
    action=(fwd_group(childports="lsp1","lsp2");)

In the physical topology, OVN managed hypervisors are connected to R1 and
R2 through overlay tunnels. The logical flow's "fwd_group" action mentioned
above, gets translated to openflow group type "select" with one bucket for
each logical switch port.

cookie=0x0, duration=16.869s, table=29, n_packets=4, n_bytes=392, idle_age=0,
priority=111,metadata=0x9,dl_dst=VMAC_1 actions=group:1

group_id=1,type=select,selection_method=dp_hash,
    bucket=actions=load:0x2->NXM_NX_REG15[0..15], resubmit(,32),
    bucket=actions=load:0x3->NXM_NX_REG15[0..15],resubmit(,32)

where 0x2 and 0x3 are port tunnel keys of lsp1 and lsp2.

The openflow group type "select" with selection method "dp_hash" load
balances traffic based on source and destination Ethernet address, VLAN ID,
Ethernet type, IPv4/v6 source and destination address and protocol, and for
TCP and SCTP only, the source and destination ports.

To detect path failure between OVN managed hypervisors and (R1, R2), BFD is
enabled on the tunnel interfaces. The openflow group is modified to include
watch_port for liveness detection of a port. The forwarding group must be
configured with --liveness to enable it. With liveness enabled, the logical
flow changes to:
table=13(ls_in_l2_lkup      ), priority=50   , match=(eth.dst == VMAC_1),
    action=(fwd_group(liveness="true",childports="lsp1","lsp2");)

While the openflow group is:
group_id=1,type=select,selection_method=dp_hash,
  bucket=watch_port:31,actions=load:0x2->NXM_NX_REG15[0..15],resubmit(,32),
  bucket=watch_port:32,actions=load:0x3->NXM_NX_REG15[0..15],resubmit(,32)

Where 31 and 32 are ovs port numbers for the tunnel interfaces connecting
to R1 and R2.

If the BFD forwarding status is down for any of the tunnels, the
corresponding bucket will not be selected for packet forwarding.

Signed-off-by: Manoj Sharma <manoj.sharma at nutanix.com>
Signed-off-by: Numan Siddique <numans at ovn.org>

View the changeset: https://github.com/ovn-org/ovn/compare/8a872f9342ec...edb240081518

View the full build log and details: https://travis-ci.org/ovn-org/ovn/builds/641260041?utm_medium=notification&utm_source=email

--

You can unsubscribe from build emails from the ovn-org/ovn repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=24187664&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-build/attachments/20200124/6e41922b/attachment.html>