masquerading behavior changed between queens and train

[David Hill]

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

[Lajos Katona (lajos-katona)]

Related patch (for some reason launchpad haven't noticed it):
https://review.opendev.org/c/openstack/neutron/+/854041

[OpenStack Infra (hudson-openstack)]

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 <email address hidden>
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

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/yoga
Review: https://review.opendev.org/c/openstack/neutron/+/854795

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/854795
Committed: https://opendev.org/openstack/neutron/commit/fa77abbc153dcf040a95f6a001d6661e07c25096
Submitter: "Zuul (22348)"
Branch: stable/yoga

commit fa77abbc153dcf040a95f6a001d6661e07c25096
Author: David Hill <email address hidden>
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
    (cherry picked from commit bbefe5285e7ab799422fab81488f57c9c22769b6)

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/xena
Review: https://review.opendev.org/c/openstack/neutron/+/854808

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/wallaby
Review: https://review.opendev.org/c/openstack/neutron/+/854993

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/victoria
Review: https://review.opendev.org/c/openstack/neutron/+/854994

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/ussuri
Review: https://review.opendev.org/c/openstack/neutron/+/854995

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/train
Review: https://review.opendev.org/c/openstack/neutron/+/854996

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/854808
Committed: https://opendev.org/openstack/neutron/commit/9985e7ddaf82d384336db77e93d6c46d122df39b
Submitter: "Zuul (22348)"
Branch: stable/xena

commit 9985e7ddaf82d384336db77e93d6c46d122df39b
Author: David Hill <email address hidden>
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
    (cherry picked from commit bbefe5285e7ab799422fab81488f57c9c22769b6)
    (cherry picked from commit fa77abbc153dcf040a95f6a001d6661e07c25096)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/854995
Committed: https://opendev.org/openstack/neutron/commit/e7f8b93a8a2159b59c94657400da86cebf7b450f
Submitter: "Zuul (22348)"
Branch: stable/ussuri

commit e7f8b93a8a2159b59c94657400da86cebf7b450f
Author: David Hill <email address hidden>
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
    (cherry picked from commit bbefe5285e7ab799422fab81488f57c9c22769b6)
    (cherry picked from commit fa77abbc153dcf040a95f6a001d6661e07c25096)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/854993
Committed: https://opendev.org/openstack/neutron/commit/336bb4d3fcb38770fd3965046df32471efa6269c
Submitter: "Zuul (22348)"
Branch: stable/wallaby

commit 336bb4d3fcb38770fd3965046df32471efa6269c
Author: David Hill <email address hidden>
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
    (cherry picked from commit bbefe5285e7ab799422fab81488f57c9c22769b6)
    (cherry picked from commit fa77abbc153dcf040a95f6a001d6661e07c25096)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/854996
Committed: https://opendev.org/openstack/neutron/commit/04e4a97742f0a12137fe7ae9d4f3af91a9125862
Submitter: "Zuul (22348)"
Branch: stable/train

commit 04e4a97742f0a12137fe7ae9d4f3af91a9125862
Author: David Hill <email address hidden>
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
    (cherry picked from commit bbefe5285e7ab799422fab81488f57c9c22769b6)
    (cherry picked from commit fa77abbc153dcf040a95f6a001d6661e07c25096)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 21.0.0.0rc1 release candidate.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/854994
Committed: https://opendev.org/openstack/neutron/commit/553777c52d0fbfa18a1830d41ac018d2e1dc8282
Submitter: "Zuul (22348)"
Branch: stable/victoria

commit 553777c52d0fbfa18a1830d41ac018d2e1dc8282
Author: David Hill <email address hidden>
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
    (cherry picked from commit bbefe5285e7ab799422fab81488f57c9c22769b6)
    (cherry picked from commit fa77abbc153dcf040a95f6a001d6661e07c25096)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 18.6.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 19.5.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 20.3.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron train-eol release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron ussuri-eol release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron victoria-eom release.