Source pod ip is not preserved when contacting a cluster ip service

[marun]

A kube e2e test was added to validate preservation of the pod source ip when contacting a service:

kubernetes/kubernetes#30739

This test currently fails when run against origin. According to @danwinship, this is due to docker adding a rule ensuring that anything with a source IP in lbr0's network and destination IP outside of lbr0's network is masqueraded. The result is that a pod IP (e.g. x.x.x.5) would appear to the service ip as the lbr0 gateway (e.g. x.x.x.1).

The e2e in question will be skipped until this issue is resolved.

cc: @openshift/networking

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[danwinship]

Not clear if we're going to fix this before migrating everyone to OVN, but we don't want the issue auto-closed

/remove-lifecycle rotten
/lifecycle frozen

[danwinship]

This works for ovs-networkpolicy, and is not going to be fixed for ovs-multitenant.
/close

[openshift-ci-robot]

@danwinship: Closing this issue.

In response to this:

This works for ovs-networkpolicy, and is not going to be fixed for ovs-multitenant.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.