yahoo-eng-team team mailing list archive

[OpenStack Infra <1620824@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/366297
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=299d08ed3f3f170a129fb2096df73fd5af7e647d
Submitter: Jenkins
Branch:    master

commit 299d08ed3f3f170a129fb2096df73fd5af7e647d
Author: David Wahlstrom <david.wahlstrom@xxxxxxxxxxxxx>
Date:   Tue Sep 6 12:11:41 2016 -0700

    DVR: properly track SNAT traffic
    
    When running DVR, it's possible for traffic to get confused and sent
    through SNAT thanks to the way conntrack tracks "new" connections.  This
    patch sets "nf_connctrack_tcp_loose" inside the SNAT namespace to more
    intelligently handle SNAT traffic (and ignore what should be FIP
    traffic) - basically, don't track a connection where we didn't
    see the initial SYN.
    
    https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt
    
    Change-Id: Ia5b8bd3794d22808ee1718d429f0bbdbe61e94ec
    Closes-Bug: 1620824


** 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/1620824

Title:
  Neutron DVR(SNAT) steals FIP traffic

Status in neutron:
  Fix Released

Bug description:
  Setup:

  We have 40+ compute nodes, all running neutron-l3-agent in DVR mode.
  We also have 1 node running neutron-l3-agent in DVR_SNAT mode.  L2
  population is happening with VXFLD
  (https://github.com/CumulusNetworks/vxfld).

  Steps to reproduce:

  After following the setup above, we noticed that traffic going to/from
  a floating IP was randomly going out the SNAT namespace (and thus
  getting connection resets).  Further investigation showed this was
  related/correlated to traffic load, meaning, the more traffic, the
  more likely the return path would go out the SNAT namespace instead of
  back out the FIP namespace.  After some searching, we found that
  conntrack was marking in-transit connections as "new" connections
  (losing their state, essentially) and thus the SNAT namespace would
  see this as new traffic and setup a new return path.

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