Hi all, We received a bug report from the ovn-kubernetes development team: https://issues.redhat.com/browse/FDP-871
Given a gateway router with load balancers attached to it. If: - the gateway router has a router port attached to multiple IP networks and - the router is configured with lb_force_snat_ip=router_ip (SNAT to the router IP configured on the interface the traffic is sent out on _if the packet has been load balanced_ [0]) Then ovn-northd cannot know which router IP should be used when SNAT-ing the packets going out. Today ovn-northd chooses the "first" IP. E.g., in a sandbox: ovn-nbctl lr-add lr -- set logical_router lr options:chassis=chassis-1 \ -- set logical_router lr options:lb_force_snat_ip=router_ip \ -- lrp-add lr lrp 00:00:00:00:00:01 1.1.1.1/24 2.2.2.2/24 \ -- ls-add ls \ -- lsp-add ls lsp -- lsp-set-type lsp router \ -- set logical_switch_port lsp options:router-port=lrp \ -- lb-add lb 42.42.42.42:80 43.43.43.43:80 tcp \ -- lr-lb-add lr lb northd logs: 2024-10-15T13:40:02.484Z|00010|northd|WARN|Logical router port "lrp" is configured with multiple IPv4 addresses. Only the first IP [1.1.1.1] is considered as SNAT for load balancer However, the problem is that NB.Logical_Router_Port.networks is a _set_ of strings (networks). Sets are unordered (it happens that ovsdb-server sorts them lexicographically but that's no guarantee) so the "first" value is not really something that can be controlled by the CMS. The only idea I could came up with until now to fix this is to add another version of the lb_force_snat_ip option but this time on the router port. This would allow the CMS to explicitly specify the SNAT IP individually, per port. However, that's an (ugly?) feature and won't be usable by ovn-kubernetes until OVN 25.03 is released, if we implement it. Does anyone have any other simpler and cleaner ideas about how we could allow the CMS to choose one of the router port IPs? Thanks, Dumitru [0] https://github.com/ovn-org/ovn/commit/c6e21a23bd8c _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
