[openstack-dev] [tricircle] DHCP port problem

Zhipeng Huang zhipengh512 at gmail.com
Thu Feb 4 09:07:06 UTC 2016


CC'ed Li Ma who might have insight on this problem

On Thu, Feb 4, 2016 at 3:51 PM, Vega Cai <luckyvega.g at gmail.com> wrote:

> Hi all,
>
> When implementing L3 north-south networking functionality, I meet the DHCP
> port problem again.
>
> First let me briefly explain the DHCP port problem. In Tricircle, we have
> a Neutron server using Tricircle plugin in top pod to take control all the
> Neutron servers in bottom pods. The strategy of Tricircle to avoid IP
> address conflict is that IP address allocation is done on top and we create
> port with IP address specified in bottom pod. However, the behavior of
> Neutron to create DHCP port has been changed. Neutron no longer waits for
> the creation of the first VM to schedule DHCP agent, but schedule DHCP
> agent when subnet is created, then the bound DHCP agent will automatically
> create DHCP port. So we have no chance to specify the IP address of DHCP
> port. Since the IP address of DHCP port is not reserved in top pod, we have
> risk to encounter IP address conflict.
>
> How we solve this problem for VM creation is that we still create a DHCP
> port first, then use the IP address of the port to create DHCP port in
> bottom pod. If we get an IP address conflict exception, we check if the
> bottom port is a DHCP port, if so, we directly use this bottom port and
> build a id mapping. If we successfully create the bottom DHCP port, we
> check if there are other DHCP ports in bottom pod in the same subnet and
> remove them.
>
> Now let's go back to the L3 north-south networking functionality
> implementation. If user creates a port and then associates it with a
> floating IP before booting a VM, Tricircle plugin needs to create the
> bottom internal port first in order to setup bottom floating IP. So again
> we have risk that the IP address of the internal port conflicts with the IP
> address of a bottom DHCP port.
>
> Below I list some choices to solve this problem:
> (1) Always create internal port in Nova gateway so we can directly use the
> codes handling DHCP problem in Nova gateway. This will also leave floating
> IP stuff to Nova gateway.
>
> (2) Transplant the codes handling DHCP problem from Nova gateway to
> Tricircle plugin. Considering there are already a lot of things to do when
> associating floating IP, this will make floating IP association more
> complex.
>
> (3) Anytime we need to create a bottom subnet, we disable DHCP in this
> subnet first so bottom DHCP port will not be created automatically. When we
> are going to boot a VM, we create DHCP port in top and bottom pod then
> enable DHCP in bottom subnet. When a DHCP agent is scheduled, it will check
> if there exists a port whose device_id is "reserved_dhcp_port" and use it
> as the DHCP port. By creating a bottom DHCP port with device_id set to
> "reserved_dhcp_port", we can guide DHCP agent to use the port we create.
>
> I think this problem can be solved in a separate patch and I will add a
> TODO in the patch for L3 north-south networking functionality.
>
> Any comments or suggestions?
>
> BR
> Zhiyuan
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhipeng at huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipengh at uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160204/feadad3e/attachment.html>


More information about the OpenStack-dev mailing list