Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160204/653c6d12/attachment.html>