[ovn-octavia-provider] hairpin_snat_ip not set

[Mohammed Naser]

At the moment, the OVN octavia provider does not set `hairpin_snat_ip` out of the box which means that if a backend server is sending requests to a load balancer which it is also a backend server of, it will get that request where the source IP of the request is the floating IP of the service.

The issue here is that there are two backend IPs, one floating and one fixed and there is non-deterministic behaviour if `hairpin_snat_ip` is not set.

We should ideally set `hairpin_snat_ip` to the internal IP so that it always hairpins from that IP as opposed to many other IPs which will make it easier to manage security groups as well.

[Mohammed Naser (mnaser)]

This feels more like a bug rather than a wishlist because the source IP that the backends get traffic from can be unpredictable, as opposed to just being the VIP which would be predictable..

[Max (ratte1313)]

I would also like to signal that we are affected by this limitation.

In our case this becomes especially problematic when using the OVN Octavia provider to expose the Kubernetes API (for RKE2/Kubernetes clusters). Without `hairpin_snat_ip`, nodes in the same subnet as the VIP cannot reliably reach the API endpoint through the load balancer.

At the moment the only workaround is to place the VIP into a different subnet and use a Neutron router to reach it, but this adds unnecessary complexity and latency. Having `hairpin_snat_ip` properly supported and set out of the box would make OVN-LB a much more viable and efficient choice for Kubernetes clusters, where the API-VIP is expected to be accessible from all control plane nodes in the same subnet.

I would strongly support treating this as a bug rather than just a wishlist, since without it the behaviour is inconsistent and the OVN provider is harder to use in real-world HA scenarios.