When an OpenStack Havana cluster is deployed on hardware rented from OVH and Hetzner, IPv4 are rented by the month and are either isolated ( just one IP, not a proper subnet ) or made of a collection of disjoint subnets of various sizes.
188.8.131.52/32 184.108.40.206/30 ...
OpenStack does not provide a way to deal with this situation and a hack involving a double nat using a subnet of floating IP is proposed.
A L3 agent runs on an OVH machine and pretends that 10.88.15.0/24 is a subnet of floating IPs, although they are not publicly available. Another L3 agent is setup on a Hetzner machine and uses the 10.88.16.0/24 subnet.
When an instance is created, it may chose a Hetzner private subnet, which is connected to a Hetzner router for which the gateway has been set to a network providing the Hetzner floating IPs. And the same is done for OVH.
A few floating IP are rented from OVH and Hetzner. On the host running the L3 agent dedicated to the OVH AS, a 1 to 1 nat is established between each IP in the 10.88.15.0/24 subnet and the OVH floating IPs. For instance the following /etc/init/nat.conf upstart script associates 10.88.15.3 with the 220.127.116.11 floating IP.
description "OVH nat hack" start on neutron-l3-agent script iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE ip addr add 10.88.15.1/24 dev br-ex while read private public ; do test "$public" || continue iptables -t nat -A POSTROUTING -s $private/32 -j SNAT --to-source $public iptables -t nat -A PREROUTING -d $public/32 -j DNAT --to-destination $private done <<EOF 10.88.15.3 18.104.22.168 EOF end script