Hi, Dnia niedziela, 28 lutego 2021 13:06:48 CET Arnaud Morin pisze:
Hello,
What we do on our side is that we create a subnet with specific service_type on our public network. That way, neutron will take an IP from this pool instead of the "public" pool.
Yes, that is good approach and service_type is intended exactly for such use case :) The other possibility is to use ML2/OVN backend. This backend has distributed N-S traffic with DNAT (floating IPs) and also distributed E-W traffic by default and it don't needs to use additional IP address per compute node.
Extract from a script that I use:
# Add a private subnet in this public network # The service-type network:floatingip_agent_gateway # will let IPAM give IP from this subnet for FIP namespaces # This is used to reduce number of public IP on neutron DVR # Note that we still need to set a valid next-hop gateway # ($GATEWAY here) openstack subnet create \ --network public \ --subnet-range 172.31.0.0/17 \ --gateway $GATEWAY \ --no-dhcp \ --service-type 'network:floatingip_agent_gateway' \ _internal_fip_subnet
Hope it helps.
cheers,
-- Arnaud Morin
On 27.02.21 - 21:10, Satish Patel wrote:
Folks,
Many years ago I deployed DVR (distributed virtual router) with packstack and found it required public IPs on each computes node + SNAT IPs, now the question is if i have 300 compute nodes then how do i deploy DVR with /24 public subnet which i have. If my cloud computes are going to eat up my all public IP then who is going to deploy DVR?
In short, DVR is a bad idea for public clouds until IPv6 takes over the world, am I missing something?
-- Slawek Kaplonski Principal Software Engineer Red Hat