Bug 2118373
| Summary: | Support LR.options.lb_force_snat_ip on distributed routers with gateway port. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux Fast Datapath | Reporter: | Dumitru Ceara <dceara> |
| Component: | OVN | Assignee: | lorenzo bianconi <lorenzo.bianconi> |
| Status: | CLOSED WONTFIX | QA Contact: | Jianlin Shi <jishi> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | FDP 22.E | CC: | ctrautma, jiji, lorenzo.bianconi, mmichels |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-07-13 14:28:13 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Dumitru Ceara
2022-08-15 15:42:51 UTC
(In reply to Dumitru Ceara from comment #0) > Description of problem: > > The logical router "lb_force_snat_ip" option is currently supported only on > gateway routers. > > Load balancers are however also supported on distributed routers with > exactly one distributed gateway port. This BZ tracks adding support for > "lb_force_snat_ip" for distributed routers. > > Originally reported upstream at: > https://github.com/ovn-org/ovn/issues/144 @decera looking at the code it seems a bit hard to introduce lb_force_snat_ip on distributed router since the incoming traffic is "snatted" on the hv running the distributed gw router port (lr_out_snat - table 3 of router egress pipeline) while the reverse traffic is "unsnatted" in lr_in_unsnat stage (table 4) of logical router ingress pipeline. Since lr_in_unsnat is executed before routing stage (lr_in_ip_routing - table 11) and lr_in_gw_redirect stage (table 18) the traffic will not be sent to the hv running the distributed gw router port before forwarding it to connection tracking. Moreover lr_in_unsnat must be executed before lr_in_ip_routing stage so it is not possible to decide in advance if the packet must be sent to the hv running the distributed gw router port. As discussed offline, it might be possible to perform the SNAT in the original direction on the remote hypervisor (the one where the backend resides). If so, then we'd ensure that both SNAT and unSNAT happen on the same host. close this bz since we did not received any reply from the requester for almost 1y. Feel free to open it again if we receive any feedback. |