[openstack-dev] [neutron] Prefix delegation using dibbler client

John Davidge (jodavidg) jodavidg at cisco.com
Tue Feb 24 17:40:48 UTC 2015


Hello all,

We now have a work-in-progress patch up for review:

https://review.openstack.org/#/c/158697/


Feedback on our approach is much appreciated.

Many thanks,

John Davidge
OpenStack at Cisco




On 20/02/2015 18:28, "Ihar Hrachyshka" <ihrachys at redhat.com> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Those are good news!
>
>I commented on the pull request. Briefly, we can fetch from git, but
>would prefer an official release.
>
>Thanks,
>/Ihar
>
>On 02/19/2015 11:26 PM, Robert Li (baoli) wrote:
>> Hi Kyle, Ihar,
>> 
>> It looks promising to have our patch upstreamed. Please take a look
>> at this pull request
>> 
>>https://github.com/tomaszmrugalski/dibbler/pull/26#issuecomment-75144912.
>> Most importantly, Tomek asked if it’s sufficient to have the code
>> up in his master branch. I guess you guys may be able to help
>> answer that question since I’m not familiar with openstack release
>> process.
>> 
>> Cheers, Robert
>> 
>> On 2/13/15, 12:16 PM, "Kyle Mestery" <mestery at mestery.com
>> <mailto:mestery at mestery.com>> wrote:
>> 
>> On Fri, Feb 13, 2015 at 10:57 AM, John Davidge (jodavidg)
>> <jodavidg at cisco.com <mailto:jodavidg at cisco.com>> wrote:
>> 
>> Hi Ihar,
>> 
>> To answer your questions in order:
>> 
>> 1. Yes, you are understanding the intention correctly. Dibbler
>> doesn¹t currently support client restart, as doing so causes all
>> existing delegated prefixes to be released back to the PD server.
>> All subnets belonging to the router would potentially receive a new
>> cidr every time a subnet is added/removed.
>> 
>> 2. Option 2 cannot be implemented using the current version of
>> dibbler, but it can be done using the version we have modified.
>> Option 3 could possibly be done with the current version of
>> dibbler, but with some major limitations - only one single router
>> namespace would be supported.
>> 
>> Once the dibbler changes linked below are reviewed and finalised we
>> will only need to merge a single patch into the upstream dibbler
>> repo. No further patches are anticipated.
>> 
>> Yes, you are correct that dibbler is not needed unless prefix
>> delegation is enabled by the deployer. It is intended as an
>> optional feature that can be easily disabled (and probably will be
>> by default). A test to check for the correct dibbler version would
>> certainly be necessary.
>> 
>> Testing in the gate will be an issue until the new version of
>> dibbler is merged and packaged in the various distros. I¹m not sure
>> if there is a way to avoid this problem, unless we have devstack
>> install from our updated repo while we wait.
>> 
>> To me, this seems like a pretty huge problem. We can't expect
>> distributions to package side-changes to upstream projects. The
>> correct way to solve this problem is to work to get the changes
>> required in the dependent packages upstream into those projects
>> first (dibbler, in this case), and then propose the changes into
>> Neutron to make use of those changes. I don't see how we can
>> proceed with this work until the issues around dibbler has been
>> resolved.
>> 
>> 
>> John Davidge OpenStack at Cisco
>> 
>> 
>> 
>> 
>> On 13/02/2015 16:01, "Ihar Hrachyshka" <ihrachys at redhat.com
>> <mailto:ihrachys at redhat.com>> wrote:
>> 
>> Thanks for the write-up! See inline.
>> 
>> On 02/13/2015 04:34 PM, Robert Li (baoli) wrote:
>>> 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.
>> 
>> Sorry for my ignorance on PD implementation (I will definitely look
>> at it the next week), but what does this entry above mean? Do you
>> want a single dibbler instance running per router serving all
>> subnets plugged into it? And you want to get configuration updates
>> when a new subnet is plugged in, or removed from the router?
>> 
>> If that's the case, why not just restarting the client?
>> 
>>> 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.
>> 
>> Just to understand all options at the table: can we implement ^^
>> option with stock dibbler?
>> 
>> 
>>> 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.
>> 
>> That's disturbing from packager point of view.
>> 
>> - From Red Hat side, we miss dibbler packaged in Fedora, but that's
>> a minor issue, we can easily put some effort and do it.
>> 
>> As for shipping side patches with it, it's a major problem.
>> Especially considering the fact that those patches were not
>> reviewed or accepted by dibbler upstream.
>> 
>> I think it is critical to reach dibbler authors ASAP and see what
>> they have to say about these patches. Remember, we're in Kilo-3
>> mode already.
>> 
>> Reading thru the spec [1], it seems to me that dibbler won't be
>> involved at all unless users explicitly omit prefix info when
>> creating subnets. Is it correct? If so, can we somehow provide an
>> easy way for distributions and deployers out of using custom
>> patched dibbler by disabling the feature completely if/when they
>> see shipping this version of dibbler unacceptable? I think we could
>> introduce a new config option that would forbid prefix delegated
>> subnets (?).
>> 
>> Speaking of deployers, have you also considered providing a patch
>> for sanity_check tool that would test local dibbler installation
>> on whether it supports the needed features?
>> 
>> Also, on a relevant note, how do you test the feature in gate?
>> Distro packages probably don't ship the patched version of the
>> client. Do you have any functional tests that utilize the client?
>> 
>> [1]: 
>> 
>>https://github.com/openstack/neutron-specs/blob/master/specs/kilo/ipv6-pr
>>e
>>
>> 
>fix-delegation.rst
>> 
>> /Ihar
>>> 
>>> 
>>>________________________________________________________________________
>>>__
>>
>>> 
>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>
>>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> 
>>_________________________________________________________________________
>>_
>>
>> 
>OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>
>> 
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> 
>> 
>> 
>>_________________________________________________________________________
>>_
>>
>> 
>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
>> 
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1
>
>iQEcBAEBAgAGBQJU53y7AAoJEC5aWaUY1u57Nx0IALCHzBPNpcyAy2VIRaeek7Q1
>Ol9RuwDRomqpKKsLRPAhatgwq9WDnDLK8MO3bt5yZfW0xqDfwwXYq0jSNoxJWjXE
>L2JBAXgrTRnffPH4rA4kf7cUjLdJBFwMBpwslQZ4UgVC/B6TMjj0cYDu7BOSN2FD
>A4YcBD1qPu5Kqar05R6jo+SH0qsM2g+gHS38UEGRCxnQAsZhk6QMT7NtCbzgE+dY
>n8ntfBV9sEduM4URrrEbhJAblK5gswQJvEV5VxHznLdj+2vgtVUUgSYDKnUk/F66
>CqvVpyGyocAqPoFkyYsoTdq9d6fJil4Oy/gp9gJL22kKsluBOCd1UKnmT7QHOxk=
>=rBo9
>-----END PGP SIGNATURE-----
>
>__________________________________________________________________________
>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



More information about the OpenStack-dev mailing list