Thanks John and Salvatore. I can probably start a new thread on this or change
the subject line if needed.
To add more:
Think of deployments in enterprise/DC where only a portion of it is Openstack
(still migrating). Sure, the commercial external DHCP servers may have API's.
But, the policy may be such that they don't want their DHCP servers to be
"told" from Openstack, that for this <MAC, options>, this is the IP address you
need to assign. They may have their own centralized management tools for doing
that.
And also, they may not have a way where they provide ways to "reserve" an IP
address for this <MAC, options>. By "reserve" i mean, something like telling
the external DHCP server, you may get a DHCP request for this <MAC, options> in
the future, give me the IP address that you will assign when such a request
comes in the future.
If they have a way to reserve, the proposed IPAM solution still works.
Thanks,
Paddu
From: Salvatore Orlando <[email protected]>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<[email protected]>
Date: Thursday, February 5, 2015 8:46 AM
To: "OpenStack Development Mailing List (not for usage questions)"
<[email protected]>
Subject: Re: [openstack-dev] [Neutron] fixed ip info shown for port even when
dhcp is disabled
I have the feeling that the discussion is diverging a bit.
John is correctly stating that with pluggable IPAM it should be possible, in
theory to write a driver which interfaces to any DHCP server, providing it the
information it needs to distribute addresses assigned by Neutron. This is
possible in theory even if the DHCP server does not expose any sort of API - as
an example you might write a driver which writes into configuration files and
then restarts or reloads the DHCP server as needed, which is not very different
from what we do today with Dnsmasq.
However, it seems to me that the gist of Padmanabhan's question is whether
neutron should allow completely out of band IP address management. Neutron is
evolving in a direction where this would be possible only if one considers it
as a simple service for building virtualised layer-2 segments. Unless some form
of interaction with the entity which manages IPs is envisioned, it would not be
possible to use neutron's security and routing services.Also, another aspect to
factor in is nova. I have not checked this in a while, but I seem to recall it
was not able to boot a VM with network interfaces if it did not obtain also IP
addresses for such interfaces - and those IPs are indeed fetched from neutron's
port info.If I got Padmanabhan's point right then we need to discuss if and how
out of band address mgmt and distribution should be supported in Neutron.
Regards,Salvatore
On 5 February 2015 at 15:20, John Belamaric <[email protected]> wrote:
The pluggable IPAM [1] is intended to support the scenario you described below.
That is, a fixed IP is provided for the port by IPAM, and then the DHCP server
is programmed to return that IP for that MAC or DUID (for IPv6). If I
understand correctly, your concern then is:
1) The DHCP server may not allow such programming;2) The DHCP server may not be
able to provide an IP allocation via any means other than DHCP (ie, no API to
pre-allocate the IP)
I would think then, what you are asking for is the ability to attach an
interface to a layer 2 network without also giving it an IP in any subnet(s)
that are on that network. Seems like a reasonable request, but I am not sure
what would be involved in implementing that.
Additionally, we would need some mechanism to update the port with the IP after
it is allocated via the DHCP server. Otherwise, I don't think all the iptables
rules and such will be properly configured, so you probably won't be able to
pass traffic beyond the local subnet. Not sure on that though.
[1] -
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/neutron-ipam.html
From: Padmanabhan Krishnan <[email protected]>
Reply-To: Padmanabhan Krishnan <[email protected]>
Date: Thursday, February 5, 2015 at 1:47 AM
To: John Belamaric <[email protected]>, "OpenStack Development Mailing
List (not for usage questions)" <[email protected]>
Subject: Re: [openstack-dev] [Neutron] fixed ip info shown for port even when
dhcp is disabled
Hi John,Sure, this may not be in the scope of IPAM as originally proposed in
[1]. Am just trying to see if there can be a solution for this scenario using
IPAM.
What I had in mind is also a centrally managed IPAM and not each VM allocating
its own IP address. Let me clarify. It's not an uncommon requirement to use a
commercial DHCP server in an enterprise/DC. I am referring to it as external
DHCP server from Openstack's perspective.One scenario of deployment is when
IPAM is done through Openstack and in which case, the <MAC, IP, optionally
segment> can be programmed in the external DHCP server, assuming they have
standard API's for that. Then, the VM will get the openstack assigned IP
address from the DHCP server when it boots up. You also suggested this and
sure, it's not a problem here.
Now, another scenario and that's of interest is when IPAM itself is done
directly using the commercial DHCP server for various reasons. I am just trying
to see how this model will work (or can be extended to work) for this case.
What's the role of pluggable IPAM [1] in this scenario? If at all there's a way
to tell the external DHCP server, do your own allocation and return an IP
address for me for this <MAC, segment>, then this IP address can be returned
during the allocate_ip API by the pluggable IPAM? But, I am not sure, an
external DHCP server will have this flexibility.Then, in such scenarios, the
only way is to not allocate an IP address during create_port. When the VM comes
up and sends a DHCP request the commercial DHCP server responds with an
address. The pluggable IPAM then can use its own method, and when it discovers
the IP address of the VM, it can call to update_port with the IP address.Any
other way?
[1] -
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/neutron-ipam.html
Thanks,Paddu
On Tuesday, February 3, 2015 8:57 AM, John Belamaric <[email protected]>
wrote:
Hi Paddu,
I think this is less an issue of the pluggable IPAM than it is the Neutron
management layer, which requires an IP for a port, as far as I know. If the
management layer is updated to allow a port to exist without a known IP, then
an additional IP request type could be added to represent the placeholder you
describing.
However, doing so leaves IPAM out of the hands of Neutron and out of the hands
of the external (presumably authoritative) IPAM system. This could lead to
duplicate IP issues since each VM is deciding its own IP without any
centralized coordination. I wouldn't recommend this approach to managing your
IP space.
John
From: Padmanabhan Krishnan <[email protected]>
Reply-To: Padmanabhan Krishnan <[email protected]>
Date: Wednesday, January 28, 2015 at 4:58 PM
To: John Belamaric <[email protected]>, "OpenStack Development Mailing
List (not for usage questions)" <[email protected]>
Subject: Re: [openstack-dev] [Neutron] fixed ip info shown for port even when
dhcp is disabled
Some follow up questions on this.
In the specs, i see that during a "create_port", there's provisions to query
the external source by "Pluggable IPAM" to return the IP.This works fine for
cases where the external source (say, DHCP server) can be queried for the IP
address when a launch happens.
Is there a provision to have the flexibility of a "late IP assignment"?
I am thinking of cases, like the temporary unavailability of external IP source
or lack of standard interfaces in which case data packet snooping is used to
find the IP address of a VM after launch. Something similar to late binding of
IP addresses.This means the create_port may not get the IP address from the
pluggable IPAM. In that case, launch of a VM (or create_port) shouldn't fail.
The Pluggable IPAM should have some provision to return something equivalent to
"unavailable" during create_port and be able to do an update_port when the IP
address becomes available.
I don't see that option. Please correct me if I am wrong.
Thanks,Paddu
On Thursday, December 18, 2014 7:59 AM, Padmanabhan Krishnan <[email protected]>
wrote:
Hi John,Thanks for the pointers. I shall take a look and get back.
Regards,Paddu
On Thursday, December 18, 2014 6:23 AM, John Belamaric
<[email protected]> wrote:
Hi Paddu,
Take a look at what we are working on in Kilo [1] for external IPAM. While this
does not address DHCP specifically, it does allow you to use an external source
to allocate the IP that OpenStack uses, which may solve your problem.
Another solution to your question is to invert the logic - you need to take the
IP allocated by OpenStack and program the DHCP server to provide a fixed IP for
that MAC.
You may be interested in looking at this Etherpad [2] that Don Kehn put
together gathering all the various DHCP blueprints and related info, and also
at this BP [3] for including a DHCP relay so we can utilize external DHCP more
easily.
[1] https://blueprints.launchpad.net/neutron/+spec/neutron-ipam[2]
https://etherpad.openstack.org/p/neutron-dhcp-org[3]
https://blueprints.launchpad.net/neutron/+spec/dhcp-relay
John
From: Padmanabhan Krishnan <[email protected]>
Reply-To: Padmanabhan Krishnan <[email protected]>, "OpenStack Development
Mailing List (not for usage questions)" <[email protected]>
Date: Wednesday, December 17, 2014 at 6:06 PM
To: "[email protected]" <[email protected]>
Subject: Re: [openstack-dev] [Neutron] fixed ip info shown for port even when
dhcp is disabled
This means whatever tools the operators are using, it need to make sure the IP
address assigned inside the VM matches with Openstack has assigned to the
port.Bringing the question that i had in another thread on the same topic:
If one wants to use the provider DHCP server and not have Openstack's DHCP or
L3 agent/DVR, it may not be possible to do so even with DHCP disabled in
Openstack network. Even if the provider DHCP server is configured with the same
start/end range in the same subnet, there's no guarantee that it will match
with Openstack assigned IP address for bulk VM launches or when there's a
failure case.So, how does one deploy external DHCP with Openstack?
If Openstack hasn't assigned a IP address when DHCP is disabled for a network,
can't port_update be done with the provider DHCP specified IP address to put
the anti-spoofing and security rules?With Openstack assigned IP address,
port_update cannot be done since IP address aren't in sync and can overlap.
Thanks,Paddu
On 12/16/14 4:30 AM, "Pasquale Porreca" <[email protected]>
wrote:
>I understood and I agree that assigning the ip address to the port is
>not a bug, however showing it to the user, at least in Horizon dashboard
>where it pops up in the main instance screen without a specific search,
>can be very confusing.
>
>On 12/16/14 12:25, Salvatore Orlando wrote:
>> In Neutron IP address management and distribution are separated
>>concepts.
>> IP addresses are assigned to ports even when DHCP is disabled. That IP
>> address is indeed used to configure anti-spoofing rules and security
>>groups.
>>
>> It is however understandable that one wonders why an IP address is
>>assigned
>> to a port if there is no DHCP server to communicate that address.
>>Operators
>> might decide to use different tools to ensure the IP address is then
>> assigned to the instance's ports. On XenServer for instance one could
>>use a
>> guest agent reading network configuration from XenStore; as another
>> example, older versions of Openstack used to inject network
>>configuration
>> into the instance file system; I reckon that today's configdrive might
>>also
>> be used to configure instance's networking.
>>
>> Summarising I don't think this is a bug. Nevertheless if you have any
>>idea
>> regarding improvements on the API UX feel free to file a bug report.
>>
>> Salvatore
>>
>> On 16 December 2014 at 10:41, Pasquale Porreca <
>> [email protected]> wrote:
>>>
>>> Is there a specific reason for which a fixed ip is bound to a port on a
>>> subnet where dhcp is disabled? it is confusing to have this info shown
>>> when the instance doesn't have actually an ip on that port.
>>> Should I fill a bug report, or is this a wanted behavior?
>>>
>>> --
>>> Pasquale Porreca
>>>
>>> DEK Technologies
>>> Via dei Castelli Romani, 22
>>> 00040 Pomezia (Roma)
>>>
>>> Mobile +39 3394823805
>>> Skype paskporr
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> [email protected]
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> [email protected]
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>--
>Pasquale Porreca
>
>DEK Technologies
>Via dei Castelli Romani, 22
>00040 Pomezia (Roma)
>
>Mobile +39 3394823805
>Skype paskporr
>
>_______________________________________________
>OpenStack-dev mailing list
>[email protected]
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
