Sure, makes sense. The placeholder I was referring to would be communicated to 
the IPAM plugin. Though, if there is no IP, it may be just best not to involve 
the IPAM subsystem.

From: Kevin Benton <<>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
Date: Tuesday, February 3, 2015 at 4:38 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
Cc: Padmanabhan Krishnan <<>>
Subject: Re: [openstack-dev] [Neutron] fixed ip info shown for port even when 
dhcp is disabled

If we have ports without IPs, I don't think we need a placeholder, do we? 
Wouldn't a port without an IP address be the same thing as a port with a 
placeholder indicating that it doesn't have an IP address?

On Tue, Feb 3, 2015 at 8:57 AM, John Belamaric 
<<>> 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 

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.


From: Padmanabhan Krishnan <<>>
Reply-To: Padmanabhan Krishnan <<>>
Date: Wednesday, January 28, 2015 at 4:58 PM
To: John Belamaric <<>>, 
"OpenStack Development Mailing List (not for usage questions)" 
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 

I don't see that option. Please correct me if I am wrong.


On Thursday, December 18, 2014 7:59 AM, Padmanabhan Krishnan 
<<>> wrote:

Hi John,
Thanks for the pointers. I shall take a look and get back.


On Thursday, December 18, 2014 6:23 AM, John Belamaric 
<<>> 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 



From: Padmanabhan Krishnan <<>>
Reply-To: Padmanabhan Krishnan <<>>, 
"OpenStack Development Mailing List (not for usage questions)" 
Date: Wednesday, December 17, 2014 at 6:06 PM
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.


On 12/16/14 4:30 AM, "Pasquale Porreca" 

>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
>> IP addresses are assigned to ports even when DHCP is disabled. That IP
>> address is indeed used to configure anti-spoofing rules and security
>> It is however understandable that one wonders why an IP address is
>> to a port if there is no DHCP server to communicate that address.
>> 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
>> into the instance file system; I reckon that today's configdrive might
>> be used to configure instance's networking.
>> Summarising I don't think this is a bug. Nevertheless if you have any
>> regarding improvements on the API UX feel free to file a bug report.
>> Salvatore
>> On 16 December 2014 at 10:41, Pasquale Porreca <
>> 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<tel:%2B39%203394823805>
>>> Skype paskporr
>>> _______________________________________________
>>> OpenStack-dev mailing list
>> _______________________________________________
>> OpenStack-dev mailing list
>Pasquale Porreca
>DEK Technologies
>Via dei Castelli Romani, 22
>00040 Pomezia (Roma)
>Mobile +39 3394823805<tel:%2B39%203394823805>
>Skype paskporr
>OpenStack-dev mailing list

OpenStack Development Mailing List (not for usage questions)

Kevin Benton
OpenStack Development Mailing List (not for usage questions)

Reply via email to