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?

Thanks,
Abhiram
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to