[ovs-build] Errored: ovsrobot/ovn#72 (series_125697 - 0cd5cc6)

Travis CI builds at travis-ci.com
Tue Aug 20 15:26:05 UTC 2019


Build Update for ovsrobot/ovn
-------------------------------------

Build: #72
Status: Errored

Duration: 1 hr, 4 mins, and 19 secs
Commit: 0cd5cc6 (series_125697)
Author: Ankur Sharma
Message: OVN: Vlan backed DVR N-S, avoid get_arp on non redirect chassis.

Background:
With c0974331b7a19a87ab8f1f2cec8fbe366af92fa2, we have added
support for E-W workflow for vlan backed DVRs.

This series enables N-S workflow for vlan backed DVRs.

Key difference between E-W and N-S traffic flow is that
N-S flow requires a gateway chassis. A gateway chassis
will be respondible for following:
a. Doing Network Address Translation (NAT).
b. Becoming entry and exit point for North->South
   and South->North traffic respectively.

OVN by default always uses overlay encapsulation to redirect
the packet to gateway chassis. This series will enable
the redirection to gateway chassis in the absence of encapsulation.

This patch:
a. Make sure that ARP request for endpoint behind the gateway
   router port is sent from gateway chassis only and not from
   host(compute) chassis.

b. This is achieved by adding a new logical flow in
   lr_in_arp_resolve at priority=50.

c. This flow run on non gateway chassis and sets the destination
   mac to router port mac, if outport is a gateway chassis attached
   router port and redirect-type is set as "vlan".
   Example logical flow:
   table=9 (lr_in_arp_resolve  ), priority=50   , match=(outport == "router-to-underlay" && !is_chassis_resident("cr-router-to-underlay")), action=(eth.dst = 00:00:01:01:02:04; next;)

d. This change is needed because other wise for non resolved ARPs,
   we will end up doing get_arp in host chassis. Doing so will
   have following issues:
   i. We want all the interation with North bound endpoints via
      gateway chassis only, doing so on host chassis will violate
      that.

  ii. With get_arp, ovn-controller will generate the ARP using router
      port's mac as source mac, which will lead us to the same issue,
      where router port mac will be going through continous mac moves
      in physical network. Worst, it would affect the redirection,
      since it uses router port mac as destination mac.

Signed-off-by: Ankur Sharma <ankur.sharma at nutanix.com>
Signed-off-by: 0-day Robot <robot at bytheb.org>

View the changeset: https://github.com/ovsrobot/ovn/compare/ca704d3efd29...0cd5cc66508f

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

--

You can unsubscribe from build emails from the ovsrobot/ovn repository going to https://travis-ci.com/account/preferences/unsubscribe?repository=9136199&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at https://travis-ci.com/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/20190820/b93b4c1f/attachment-0001.html>


More information about the build mailing list