Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210228/0cb17103/attachment.sig>