On 1/7/22 09:26, Abhiram Sangana wrote:
Hi Mark,
Thanks for looking into this patch.
On 5 Jan 2022, at 22:01, Mark Michelson <[email protected]> wrote:
Hi,
I haven't done a full review of this patch, but I have noticed a problem pretty
early on when I started looking.
The new ip_in_lrp_networks() function that is added here is intended to
determine which l3dgw port to use for a particular NAT external address. The
problem is that there are configurations, especially from OpenStack, where this
will cause problems.
In current OpenStack configurations, they might set up a router with a gateway
port that serves the 10.0.0.0/8 network. But they might set up a DNAT with
external address 192.168.0.1 on that router. They expect that traffic sent to
192.168.0.1 will be NATted correctly on that router, even though the router
port network does not include that IP address.
Yeah, this makes sense. I was thinking about this case for Load balancer rules
but it’s true for DNAT in general.
If you run `make check-system-userspace` with your series, you'll find that the
"Floating IP outside router subnet IPv4" test fails.
How could this be fixed?
One idea is to configure the external port explicitly either on the NAT itself or on the
router. This way, even if the IP address is outside the subnet of the DGP, you can still
know which DGP is the "correct" one.
Another idea would be to differentiate behavior between SNAT and DNAT. For
DNAT, you could treat all DGPs as equals, so it doesn't matter on which DGP the
traffic is received, it will get translated properly. For SNAT or
DNAT-and-SNAT, you'd probably need to explicitly specify which DGP to use,
though.
I was thinking of the second approach for Load balancer rules. I could do the
same for DNAT rules. The first approach gives more control but expects the user
to configure correctly. Which approach would you suggest?
I think the second approach should be good as well.
Thanks,
Abhiram
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
