bbefe5285e7ab799422fab81488f57c9c22769b6

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
OpenStack Neutron
Neutron is an OpenStack project to provide "network connectivity as a service" between interface devices (e.g., vNICs) managed by other OpenStack services (e.g., Nova).
To learn more about neutron:
- Documentation: https://docs.openstack.org/neutron/latest/
- Features: https://specs.openstack.org/openstack/neutron-specs
- Defects: https://launchpad.net/neutron
- Release notes: https://docs.openstack.org/releasenotes/neutron/index.html
- Source: https://opendev.org/openstack/neutron
If you would like to contribute to Neutron, please read the file CONTRIBUTING.rst or see the Neutron contributor guide:
https://docs.openstack.org/neutron/latest/contributor/contributing.html
Get in touch via email. Use [Neutron] in your subject.
Description
Languages
Python
99.7%
Shell
0.3%