[Chilli] multiple chilli instances on the same network

David Bird david at coova.com
Fri Sep 17 07:45:52 UTC 2010


Hello,

A couple of things going on in CoovaChilli development worth commenting
on.. 

There will be a compile time option to --enable-cluster code. This will
include code to manage peers on the dhcpif network. You might do this to
provide failover or load balancing of the chilli access controller. Each
peer shall be given a unique peerid in the configuration, as well as a
peerkey used for encryption of chilli control messages. The control
messages are layer 2 and I'm currently using the protocol number 0xbeef
to carry the encrypted (blowfish; requires openssl) messages. These
messages are used by chilli to coordinate and share client state
information.  

To begin with, I'm looking at an active/standby setup and have two
instances running on the same machine, both configured for the same
dhcpif (with all necessary configuration changes like uamlisten,
uamport, etc, to keep the two instances from using the same resources).
On startup, peerid 0 is always active:

./chilli_query /tmp/chilli.sock peers
Peer 0 (*)  00:11:22:33:44:55 / 10.1.0.1         Active   5 sec
Peer 1      00:11:22:33:44:55 / 10.2.0.1         Standby  4 sec

./chilli_query /tmp/chilli.sock2 peers
Peer 0      00:11:22:33:44:55 / 10.1.0.1         Active   8 sec
Peer 1 (*)  00:11:22:33:44:55 / 10.2.0.1         Standby  7 sec

Both instances (peerid 0 and peerid 1) know the status of the other.
Peer 0 is doing all the work currently, while peer 1 is ignoring all
(except for chilli control packets) dhcpif traffic. 

I can then have peer 1 instance advertise itself as the active server:

./chilli_query /tmp/chilli.sock2 peerset

Now, instantly (because I'm using uamanyip/uamnatanyip in peer 1 config)
all traffic is being handled by peer 1 instance, while peer 0 is
ignoring traffic:

./chilli_query /tmp/chilli.sock2 peers
Peer 0      00:11:22:33:44:55 / 10.1.0.1         Standby  4 sec
Peer 1 (*)  00:11:22:33:44:55 / 10.2.0.1         Active   3 sec

So, it looks promising! The peers also need to coordinate DHCP lease
status, for which I think [1] can be of inspiration. Though, I think we
can do it in the encrypted chilli control messages. 

Also, to help with some debugging/monitoring, I'll add a 'procs' option
to chilli_query to gather a bit of info like:

./chilli_query /tmp/chilli.sock2 procs
Children 2 Max 128 Total 2
PID    10005 Main     [chilli]             up 596 [Vm Size: 5060 RSS:
1616 FDs: 14]
PID    10032 Daemon   [chilli_redir]       up 596 [Vm Size: 4284 RSS:
1668 FDs: 14]
PID    10031 Daemon   [chilli_proxy]       up 596 [Vm Size: 4220 RSS:
1548 FDs: 15]

Not shown, but it will also show any Script or Redirect processes that
chilli has launched and that are running. 

[1] http://tools.ietf.org/html/draft-ietf-dhc-failover-12

David




More information about the Chilli mailing list