Re: [Openstack-operators] DVR and public IP consumption

[Tomas Vondra]

Fox, Kevin M  writes:

> 
> Hi Tomas,
> 
> The using external addresses per tenant router is a feature to a lot of
sites, like ours. We want to know for
> sure, at minimum, which tenant was responsible for bad activity on the
external network. Having the
> external address tied to a tenant router allows you to track bad activity
back at least to the ip, then to the
> tenant router. You won't be able to tell which vm's of the tenant
performed the bad activity because of the
> snat, but you at least have some to talk to about it, instead of your
local security friends asking you to
> unplug the whole cloud.
> 
> Thanks,
> Kevin

Hi Kevin!
Don't worry, I also had this in mind. We do traffic logging at the
datacenter's firewall, so using a private IP per tenant router would still
satisfy this requirement.
Tomas




___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] DVR and public IP consumption

[Robert Starmer]

I don't think there's anything wrong with your suggestion, as I can't find
a path where the extra address is actually used (it doesn't get used in any
NAT mapping, so it is really vestigial). The question now is, will anyone
in the community be interested in extending the DVR code in this fashion
(interested in writing a spec?).

I personally am a bigger proponent of dropping the whole Floating IP
charade, and moving wholesale to v6 and routing right to the VM/container
endpoint.  But maybe that's just my own odd view.


On Thu, Jan 28, 2016 at 10:10 AM, Fox, Kevin M  wrote:

> Ah. so it was done just to make it simple to reuse lots of existing code
> to get DVR working quickly and thus a current requirement, but there is
> nothing stopping further enhancements to be made to eliminate it in the
> future?
>
> What about a step in between what's there now, and eliminating it
> completely. If the router code expects there to be an ip allocated for it
> on every compute node, could you share one external ip between all the
> compute node routers? Since the network will never actually use it, it
> probably doesn't matter if its conflicting but it would still allow the
> existing code to function the way it always has, greatly simplifying
> implementation?
>
> Thanks,
> Kevin
>
> --
> *From:* Robert Starmer [rob...@kumul.us]
> *Sent:* Wednesday, January 27, 2016 8:34 PM
> *To:* Fox, Kevin M
> *Cc:* Carl Baldwin; OpenStack Operators; Tomas Vondra
>
> *Subject:* Re: [Openstack-operators] DVR and public IP consumption
>
> I think I've created a bit of confusion, because I forgot that DVR still
> does SNAT (generic non Floating IP tied NAT) on a central network node just
> like in the non-DVR model.  The extra address that is consumed is allocated
> to a FIP specific namespace when a DVR is made responsible for supporting a
> tenant's floating IP, and the question then is: Why do I need this _extra_
> external address from the floating IP pool for the FIP namespace, since
> it's the allocation of a tenant requested floating IP to a tenant VM that
> triggers the DVR to implement the FIP namespace function in the first
> place.
>
> In both the Paris and Vancouver DVR presentations "We add distributed FIP
> support at the expense of an _extra_ external address per device, but the
> FIP namespace is then shared across all tenants". Given that there is no
> "external" interface for the DVR interface for floating IPs until at least
> one tenant allocates one, a new namespace needs to be created to act as the
> termination for the tenant's floating IP.  A normal tenant router would
> have an address allocated already, because it has a port allocated onto the
> external network (this is the address that SNAT overloads for those
> non-floating associated machines that lets them communicate with the
> Internet at large), but in this case, no such interface exists until the
> namespace is created and attached to the external network, so when the
> floating IP port is created, an address is simply allocated from the
> External (e.g. floating) pool for the interface.  And _then_ the floating
> IP is allocated to the namespace as well. The fact that this extra address
> is used is a part of the normal port allocation process (and default
> port-security anti-spoofing processes) that exist already, and simplifies
> the process of moving tenant allocated floating addresses around (the port
> state for the floating namespace doesn't change, it keeps it's special mac
> and address regardless of what ever else goes on). So don't think of it as
> a Floating IP allocated to the DVR, it's just the DVR's local
> representative for it's port on the external network.  Tenant addresses are
> then "on top" of this setup.
>
> So, in-efficient, yes.  Part of DVR history, yes.  Confusing to us mere
> network mortals, yes.  But that's how I see it. And sorry for the SNAT
> reference, just adding my own additional layer of "this is how it should
> be"  on top.
>
> Robert
>
> On Wed, Jan 27, 2016 at 3:33 PM, Fox, Kevin M  wrote:
>
>> But there already is a second external address, the fip address that's
>> nating. Is there a double nat? I'm a little confused.
>>
>> Thanks,
>> Kevin
>> --
>> *From:* Robert Starmer [rob...@kumul.us]
>> *Sent:* Wednesday, January 27, 2016 3:20 PM
>> *To:* Carl Baldwin
>> *Cc:* OpenStack Operators; Tomas Vondra
>> *Subject:* Re: [Openstack-operators] DVR and public IP consumption
>>
>> You can't get rid of the "External" address as it's used to direct return
>> traffic to the right router node.  DVR as implemented is really just a
>> local NAT gateway per physical compute node.  The outside of your NAT needs
>> to be publicly unique, so it needs it's own address.  Some SDN solutions
>> can provide a truly distributed router model, because they globally know
>> the inside state of the NAT environment, and can forward packets back to
>> the internal source properly,

Re: [Openstack-operators] best practice to manage multiple Data center using openstack

[Saverio Proto]

Hello Jeff,

your question is very general.

as a general answer I can suggest to use a configuration management
system such as Puppet or Ansible to take care of the servers. It is
easier to keep stuff in different datacenter running the same version
of packages in this way.

I hope this helps.

Saverio


2016-01-29 8:49 GMT+01:00 XueSong Ma :
> Hi:
> does anyone can tell me what are the best way or manage multiple DC using
> one openstack system?
> or the good reasons for it?
> We have sevel openstack env(multiple region), but its really difficult to
> manage them, python code, software update. etc.
> Thanks a lot!
>
> Jeff
>
>
>
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] DVR and public IP consumption

[Fox, Kevin M]

I wish I had time for it. :/ Maybe in a few months when I get this new 
production cloud deployed. Can't promise anything though


I'm very much in favor of floating ip's. I'd even argue for them for ipv6. Not 
because of SNAT, or saving IP's. Its because they are an important abstraction 
that lets you turn pets into cattle.

Let me explain... ip addresses tend to be state that gets placed into various 
places. dns, config files for other services, etc. As such it is expected to be 
somewhat long lived. A VM on the other hand, shouldn't be. You should be able 
to stand up a new one, get it ready, and once checked out, move load from the 
old to the new. A floating ip is a perfect way to do that. You leave it on the 
old vm until everything checks out, then move the floating ip. You can even use 
the trick to further scale things Its originally on a VM, but you make a 
load balancer, add the old vm to the load balancer, then move the floating ip 
to the loadbalancer. then you can add more vm's to the LB. Seamless. Without a 
floating ip, none of that is possible. You have to take painful downtimes.

So, please neutron team, floating ip's for v6 are a thing that should be 
possible. The implementation can be quite different. I think ipv6 has a 
mobility extension that maybe can be used instead of snatting. But the goal of 
having an abstraction for a network service endpoint that can be moved around 
(floating ip) really needs to stay.

I'd also really like to see them for tenant networks for similar reasons. Them 
only working on external networks is limiting.

Thanks,
Kevin




From: Robert Starmer [rob...@kumul.us]
Sent: Friday, January 29, 2016 1:21 AM
To: Fox, Kevin M
Cc: Carl Baldwin; OpenStack Operators; Tomas Vondra
Subject: Re: [Openstack-operators] DVR and public IP consumption

I don't think there's anything wrong with your suggestion, as I can't find a 
path where the extra address is actually used (it doesn't get used in any NAT 
mapping, so it is really vestigial). The question now is, will anyone in the 
community be interested in extending the DVR code in this fashion (interested 
in writing a spec?).

I personally am a bigger proponent of dropping the whole Floating IP charade, 
and moving wholesale to v6 and routing right to the VM/container endpoint.  But 
maybe that's just my own odd view.


On Thu, Jan 28, 2016 at 10:10 AM, Fox, Kevin M 
mailto:kevin@pnnl.gov>> wrote:
Ah. so it was done just to make it simple to reuse lots of existing code to get 
DVR working quickly and thus a current requirement, but there is nothing 
stopping further enhancements to be made to eliminate it in the future?

What about a step in between what's there now, and eliminating it completely. 
If the router code expects there to be an ip allocated for it on every compute 
node, could you share one external ip between all the compute node routers? 
Since the network will never actually use it, it probably doesn't matter if its 
conflicting but it would still allow the existing code to function the way it 
always has, greatly simplifying implementation?

Thanks,
Kevin


From: Robert Starmer [rob...@kumul.us]
Sent: Wednesday, January 27, 2016 8:34 PM
To: Fox, Kevin M
Cc: Carl Baldwin; OpenStack Operators; Tomas Vondra

Subject: Re: [Openstack-operators] DVR and public IP consumption

I think I've created a bit of confusion, because I forgot that DVR still does 
SNAT (generic non Floating IP tied NAT) on a central network node just like in 
the non-DVR model.  The extra address that is consumed is allocated to a FIP 
specific namespace when a DVR is made responsible for supporting a tenant's 
floating IP, and the question then is: Why do I need this _extra_ external 
address from the floating IP pool for the FIP namespace, since it's the 
allocation of a tenant requested floating IP to a tenant VM that triggers the 
DVR to implement the FIP namespace function in the first place.

In both the Paris and Vancouver DVR presentations "We add distributed FIP 
support at the expense of an _extra_ external address per device, but the FIP 
namespace is then shared across all tenants". Given that there is no "external" 
interface for the DVR interface for floating IPs until at least one tenant 
allocates one, a new namespace needs to be created to act as the termination 
for the tenant's floating IP.  A normal tenant router would have an address 
allocated already, because it has a port allocated onto the external network 
(this is the address that SNAT overloads for those non-floating associated 
machines that lets them communicate with the Internet at large), but in this 
case, no such interface exists until the namespace is created and attached to 
the external network, so when the floating IP port is created, an address is 
simply allocated from the External (e.g. floating) pool for the interface.  And 
_then_ the floating