yahoo-eng-team team mailing list archive

[OpenStack Infra <1987396@xxxxxxxxxxxxxxxxxx>]

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

commit bbefe5285e7ab799422fab81488f57c9c22769b6
Author: David Hill <dhill@xxxxxxxxxx>
Date:   Mon Aug 22 17:03:49 2022 -0400

    Allow operator to disable usage of random-fully
    
    In some specific use case, the cloud operator expects the source port
    of a packet to stay the same across all masquerading layer up to the
    destination host.   With the implementation of the random-fully code,
    this behavior was changed as source_port is always rewritten no matter
    which type of architecture / network CIDRs is being used in the backend.
    This setting allows a user to fallback to the original behavior of the
    masquerading process which is to keep the source_port consistent across
    all layers.  The initial random-fully fix  prevents packet drops when
    duplicate tuples are generated from two different namespace when the
    source_ip:source_port goes toward the same destination so enabling this
    setting would allow this issue to show again.   Perhaps a right approach
    here would be to fix this "racey" situation in the kernel by perhaps
    using the mac address as a seed to the tuple ...
    
    Change-Id: Idfe5e51007b9a3eaa48779cd01edbca2f586eee5
    Closes-bug: #1987396


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

Title:
  masquerading behavior changed between queens and train

Status in neutron:
  Fix Released

Bug description:
  masquerading behavior changed beteen queens and train following [1]
  implementation of random-fully to solve another issue.   Now, the
  source port is remapped randomly to some undeterminisitc value in
  order to avoid a racy tuple generation in the kernel but this has for
  effect that a firewall between openstack routers and the destination
  service that relies on source_ip:source_port for this no longer works.
  There're many other custom applications that could be using that
  information in their internal functions

  
  [1] https://review.opendev.org/c/openstack/neutron/+/636473

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