Re: [openstack-dev] [tricircle] DHCP port problem

[Zhipeng Huang]

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

On Thu, Feb 4, 2016 at 3:51 PM, Vega Cai  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-requ...@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: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

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

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tricircle] DHCP port problem

[Vega Cai]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev