yahoo-eng-team team mailing list archive

[OpenStack Infra <1804327@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/c/openstack/neutron/+/618208
Committed: https://opendev.org/openstack/neutron/commit/ab94c6b02116ccc24c67c1ed8e09c6840d092424
Submitter: "Zuul (22348)"
Branch:    master

commit ab94c6b02116ccc24c67c1ed8e09c6840d092424
Author: Dirk Mueller <dirk@xxxxxxxx>
Date:   Thu Nov 15 17:19:35 2018 +0100

    Enable liberal TCP connection tracking for SNAT namespaces
    
    This can avoid connections rarely hanging due to tcp window
    scaling not correctly being observed by the TCP connection
    tracking. this seems to happen when retransmits are occurring
    occassionally.
    Setting this parameter turns off validating the window scaling
    checks for the purpose of matching whether a packet matches
    an existing connection tracked flow, which avoids the SNAT
    namespace from interfering and letting the connection peers
    recover the connection via retransmits/Selective ACKs instead
    of the SNAT terminating one side of the connection and letting
    it stall permanently.
    
    Closes-Bug: #1804327
    Change-Id: I5e58bb2850bfa8e974e62215af0b4d7bc0592c13


** Changed in: neutron
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1804327

Title:
  occasional connection reset on SNATed after tcp retries

Status in neutron:
  Fix Released

Bug description:
  When neutron ports are connected to DVR routers that are without
  floating ip, the traffic is going via SNAT on the network node.

  In some cases when the tcp connections that are nat'ed end up
  retransmitting, sometimes a packet is being retransmitted by the
  remote that is outside what the Linux kernel connection tracking
  considers part of valid tcp window. When this happens, the flow is
  receiving a RST, terminating the connection on the sender side, while
  leaving the receiver side (the neutron port attached VM) hanging.

  A similar issue is described elsewhere, e.g.
  https://github.com/docker/libnetwork/issues/1090 and the workaround
  documented there of setting ip_conntrack_tcp_be_liberal seems to help
  in avoiding conntrack to dismiss packets outside the observed tcp
  window size which lets the tcp retransmit logic to eventually recover
  the connection.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1804327/+subscriptions