yahoo-eng-team team mailing list archive

[David-wahlstrom <1620824@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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.

** Affects: neutron
     Importance: Undecided
     Assignee: David-wahlstrom (david-wahlstrom)
         Status: In Progress

-- 
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:
  In Progress

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