336bb4d3fc
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 (cherry picked from commitbbefe5285e) (cherry picked from commitfa77abbc15)
16 lines
681 B
YAML
16 lines
681 B
YAML
---
|
|
features:
|
|
- |
|
|
Add ``use_random_fully`` setting to allow an operator to disable
|
|
the iptables random-fully property on an iptable rules.
|
|
issues:
|
|
- |
|
|
If the ``use_random_fully`` setting is disabled, it will prevent
|
|
random fully from being used and if there're 2 guests in different
|
|
networks using the same source_ip and source_port and they try to
|
|
reach the same dest_ip and dest_port, packets might be dropped in
|
|
the kernel do to the racy tuple generation . Disabling this
|
|
setting should only be done if source_port is really important such
|
|
as in network firewall ACLs and that the source_ip are never repeating
|
|
within the platform.
|