[ovs-build] Passed: ovsrobot/ovn#497 (series_166845 - cadfbe9)

Travis CI builds at travis-ci.com
Thu Mar 26 12:15:13 UTC 2020


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

Build: #497
Status: Passed

Duration: 16 mins and 53 secs
Commit: cadfbe9 (series_166845)
Author: Numan Siddique
Message: ovn-northd: Skip unsnat flows for load balancer vips in router ingress pipeline

Suppose there is below NAT entry with external_ip = 172.168.0.100

nat <UUID>
    external ip: "172.168.0.100"
    logical ip: "10.0.0.0/24"
    type: "snat"

And a load balancer with the VIP - 172.168.0.100

_uuid               : <UUID>
external_ids        : {}
name                : lb1
protocol            : tcp
vips                : {"172.168.0.100:8080"="10.0.0.4:8080"}

And if these are associated to a gateway logical router

Then we will see the below lflows in the router pipeline

...
table=5 (lr_in_unsnat       ), priority=90   , match=(ip && ip4.dst == 172.168.0.100), action=(ct_snat;)
...
table=6 (lr_in_dnat         ), priority=120  , match=(ct.new && ip && ip4.dst == 172.168.0.100 && tcp && tcp.dst == 8080), action=(ct_lb(10.0.0.4:8080);)
table=6 (lr_in_dnat         ), priority=120  , match=(ct.est && ip && ip4.dst == 172.168.0.100 && tcp && tcp.dst == 8080), action=(ct_dnat;)

When a new connection packet destinated for the lb vip 172.168.0.100 and tcp.dst = 8080
is received, the ct.new flow in the lr_in_dnat is hit and the packet's ip4.dst is
dnatted to 10.0.0.4 in the dnat conntrack zone.

But for the subsequent packet destined to the vip, the ct.est lflow in the lr_in_dnat
stage doesn't get hit. In this case, the packet first hits the lr_in_unsnat pri 90 flow
as mentioned above with the action ct_snat. Even though ct_snat should have no effect,
but looks like there is some issue in either ovs-vswitchd or in datapath, and the ct flags
are not set properly.

In the case of tcp, the ct.new flow is hit instead of ct.est. In the the case of sctp, neither of the above
lflows in lr_in_dnat stage hit.

This needs to be investigated further. But we can avoid this scenario in OVN
by adding the below lflow.

table=5 (lr_in_unsnat       ), priority=120  , match=(ip4 && ip4.dst == 172.168.0.100 && tcp.dst == 8080), action=(next;)

This patch adds the above lflow if the lb vip also has an entry in the NAT table.

This patch is also required to support sctp load balancers in OVN.

Reported-by: Tim Rozet <trozet at redhat.com>
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1815217
Signed-off-by: Numan Siddique <numans at ovn.org>
Signed-off-by: 0-day Robot <robot at bytheb.org>

View the changeset: https://github.com/ovsrobot/ovn/commit/cadfbe9caace

View the full build log and details: https://travis-ci.com/github/ovsrobot/ovn/builds/155506366?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/20200326/5a80c8e3/attachment.html>


More information about the build mailing list