DHCP IPAM Plugin for Docker v1.9

[Sidharta Seethana]

Folks,

I have run across multiple references (in github issues/blogs) to work in progress "DHCP IPAM Plugin" implementations. Does someone have pointers to these? I looked at the IPAM/Remote driver docs here : https://github.com/docker/libnetwork/tree/master/docs but it wasn't clear to me how certain aspects of DHCP could be handled with the network model currently in place. With pipework (https://github.com/jpetazzo/pipework), for example, the sandbox (netns) and the endpoint (e.g veth pair, with a generated mac address?) are created before a dhcp client runs inside this sandbox and an IP address is assigned. Could somebody provide a skeletal overview of how an equivalent mechanism could be implemented in this new world of libnetwork + plugins ? 

thanks!

-Sidharta 

[Vipin Jain]

Hi,

As you mentioned pipework access the namespace after container is created. An equivalent way to do this with remote APIs is to proxy-DHCP on behalf of the container (given its MAC address, etc.) to the IPAM driver. There is no access to the network namespace in IPAM driver if that's what you are looking for, understandably so for security concerns,

Some go dhcp implementations that you can adapt to doing proxy-dhcp:

https://github.com/erikh/dhcpd

https://github.com/krolaw/dhcp4

Cheers,

-Vipin

[Sidharta Seethana]

Hi Vipin,

As you mentioned pipework access the namespace after container is created. An equivalent way to do this with remote APIs is to proxy-DHCP on behalf of the container (given its MAC address, etc.) to the IPAM driver.

I don't quite follow how this is meant to work. From my reading of libnetwork code (and the documentation) the sequence of operations for the 'single endpoint' case is : 

1) Create endpoint

    a) create endpoint  

    b) endpoint.assignAddress() -> calls IPAM driver . It is unclear to me how MAC addresses are handled here. I'll have to dig further into code.

2) Create new sandbox 

3) Join endpoint to sandbox . 

From what I understand, in this model, a DHCP based IP address has to be assigned *before* a network sandbox is created. Does this mean a DHCP client has to be run on a endpoint (e.g veth pair?) before this endpoint joins a sandbox?

There is no access to the network namespace in IPAM driver if that's what you are looking for, understandably so for security concerns,

At the point the IPAM driver is called, the sandbox hasn't been created yet (in the single endpoint case). Is this what you mean by 'no access' ? Also, could you please clarify what the security implications here?

 

Some go dhcp implementations that you can adapt to doing proxy-dhcp:

https://github.com/erikh/dhcpd

https://github.com/krolaw/dhcp4

I'll take a look at these.

thanks for your help,

-Sidharta

 

Cheers,

-Vipin

On Thursday, November 19, 2015 at 6:19:11 PM UTC-8, Sidharta Seethana wrote:

Folks,

I have run across multiple references (in github issues/blogs) to work in progress "DHCP IPAM Plugin" implementations. Does someone have pointers to these? I looked at the IPAM/Remote driver docs here : https://github.com/docker/libnetwork/tree/master/docs but it wasn't clear to me how certain aspects of DHCP could be handled with the network model currently in place. With pipework (https://github.com/jpetazzo/pipework), for example, the sandbox (netns) and the endpoint (e.g veth pair, with a generated mac address?) are created before a dhcp client runs inside this sandbox and an IP address is assigned. Could somebody provide a skeletal overview of how an equivalent mechanism could be implemented in this new world of libnetwork + plugins ? 

thanks!

-Sidharta 

--
You received this message because you are subscribed to the Google Groups "docker-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to docker-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[aboch]

Hi Sidharta,

Currently the DHCP IPAM plugin is not supported. Code changes are needed in libnetwork for that.

Minimal requirement for that to work is to pass the container interface MAC address in the options when requesting the address.

During IPAM driver registration, driver should be able to express it requires the MAC when queried for an address. In that case on endpoint creation libnetwork will generate the MAC address itself (if not already passed by user) and set it in the ipam options when calling ipam driver RequestAddress().

Thanks,
Alessandro

On Thursday, November 19, 2015 at 6:19:11 PM UTC-8, Sidharta Seethana wrote:

[Sidharta Seethana]

Hi Alessandro,

Thanks for the clarification. 

Regards,

-Sidharta

--

[Ilya Dmitrichenko]

For the record, Weave Net has an open ticket (weaveworks/weave#1444) for DHCP layer, which would probably pretty simple and can be implement externally. If you are interested to exercise this, please comment on the ticket.