Hi, while trying to integrate dibbler client with neutron to support PD, we countered a few issues with the dibbler client (and server). With a neutron router, we have the qg-xxx interface that is connected to the public network, on which a dhcp server is running on the delegating router. For each subnet with PD enabled, a router port will be created in the neutron router. As a result, a new PD request will be sent that asks for a prefix from the delegating router. Keep in mind that the subnet is added into the router dynamically.
We thought about the following options: 1. use a single dibbler client to support the above requirement. This means, the client should be able to accept new requests on the fly either through configuration reload or other interfaces. Unfortunately, dibbler client doesn’t support it. 2. start a dibbler client per subnet. All of the dibbler clients will be using the same outgoing interface (which is the qg-xxx interface). Unfortunately, dibbler client uses /etc/dibbler and /var/lib/dibbler for its state (in which it saves duid file, pid file, and other internal states). This means it can only support one client per network node. 3. run a single dibbler client that requests a smaller prefix (say /56) and splits it among the subnets with PD enabled (neutron subnet requires /64). Depending on the neutron router setup, this may result in significant waste of prefixes. Given the significant drawback with 3, we are left with 1 and 2. After looking at the dibbler source code, we found that 2 is easier to achieve for now by making some small changes in the dibbler code. In the long run, we think option 1 is better. The changes we made to the linux dibbler client code, and the dibbler server code can be found in here: https://github.com/johndavidge/dibbler/tree/cloud-dibbler. Basically it does a few things: — create a unique working area per dibbler client — since all the clients use the same outgoing interface, we’d like each dibbler client to use a unique LLA as its source address when sending messages. This would avoid clients to receive server messages that are not intended for them. — we found that dibbler server uses transaction ID alone to identify a match between a request and an answer. This would require that unique transaction IDs be used among all the existing clients. We found that clients could use the same transaction IDs in our environment. Therefore, a little change is made in the server code so that it will take the request sender into consideration while looking up a match. Option 1 requires better understanding of the dibbler code, and we think that it may not be possible to make it happen in the kilo timeframe. But we think it has significant advantages over option 2. Regardless, changes made for 2 is also needed since we need to run one dibbler client per neutron router. Now the issue is how to make those changes (possible with further revision) into an official dibbler release ASAP so that we can use them for kilo release. John Davidge has contacted the dibbler authors, and hasn’t received response so far. Comments and thoughts are welcome. Cheers, —Robert
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
