[Dibbler] Features

Tomasz Mrugalski thomson at klub.com.pl
Wed Mar 16 22:31:15 CET 2011


On 15.03.2011 09:51, Gorja Prasad-B22290 wrote:
> Hi Dr.Tomasz Mrugalski,
> Congratulations for your hard work to get Ph.D.
Thanks. There are other quite large changes in my life. I'm quitting my
job at Intel and joining ISC. Hopefully, I'll be able to find some time
to catch up with Dibbler. There are many features and fixes that are
long overdue...

> 1. Support for reload of configuration file or soft reconfiguration
> feature.
> 
>    For configuration changes, DHCPv6 client/server to be restarted, it
> is troublesome when DHCP is enabled/disabled on multiple interfaces !!!
Maintaining client state after configuration change in problematic. I
would have to implement config file comparison logic. This has
significant drawbacks. I'm trying to make client smaller, not to bloat
it further. Do you have any useful, real-life use cases, when you need
to change client's configuration (e.g. start asking for specific extra
option)?

For the server, that's different. Server's configuration may change and
there is a need to reload configuration. However, the old vs new
configuration comparison logic stands. Why can't you just restart
server? That should be quite quick. Server should reload its database
and continue serving clients after restart. If you changed pools, old
addresses won't be loaded and clients won't be able to renew their old
leases, so they will migrate to new ones. That's how this is supposed to
work. Server restart should take around second, maybe less.

> 2. I understand that the dibbler client is able to receive addresses and
> prefixes. But, only first address and first prefix only processed by
> notify scripts.
> 
>    Is there any plan to enhance the script for multiple prefixes and
> addresses?. Similarly, Event mechanism to be enhanced for other
> information(DNS,SIP,WIN server info).
Yes, but only vague. I'd like to know your suggestions, how should I
implement this notification. In particular, can you propose the most
convenient way go signalling parameters to the notify script?

Here are the requirements:
- must be simple for simple cases (i.e. one address or one prefix)
- must be capable of handling complex cases (many addesses, many
  prefixes, mix of many addresses+many prefixes)
- must be able to handle cases when there is no address or prefix at all
  (stateless)

Bonus points for the ability to handle custom options. Both server and
client can now be configured to exchange user-defined options.
Unfortunately, for the time being, client is not able to do anything
useful with it. There should be a way to pass such custom options to
notify script.

Once we agree on reasonable parameter passing manner, I'm willing to
implement this. Not in the next 2 weeks (Prague preparation), but after
IETF meeting is finished.

>    You have suggested to parse client-AddrMgr.xml and
> Client-IfaceMgr.xml for more than one address and prefixes!!. There is a
> possible case in which only other information is requested but not
> address and prefix.
> 
>    IN such cases, what is the trigger point to parse these XMLs,
> precisely when to parse these files?
When running in stateless mode (sending INF-REQUEST and not requesting
any addresses or prefixes) notify script will be called with "update"
parameter, something like this: sh ./notify  :: :: 0 :: update

> 3. How is the behavior of Multiple instances of client and server in a
> single system?
You MAY run both client and server on the same system. You SHOULD NOT
run more than one client instance on the same system. There's good
reason for that: several clients may interfere, e.g. try to add or
delete something from /etc/resolv.conf at the same time; when commanding
client to stop, it is impossible to know if user wants to stop only one
(which one?) or all instances. If you want to have separate instance for
each interface, you doing it wrong. Single DHCPv6 client instance can
handle more than one interface. The same holds true for server. One
server should handle more than one interface just fine.

There are several safety checks that prevents user from running multiple
instances on the same system. However, if you are determined enough, you
can circumvent them and run 2 or more clients. However, clients can get
confused easily (one client may receive response that was addressed to
another one). I really don't recommend doing that.

Hope that helps,
Tomek


More information about the Dibbler mailing list