[Swan-dev] overlapping address pools
D. Hugh Redelmeier
hugh at mimosa.com
Mon Apr 21 04:31:07 EEST 2014
| From: Paul Wouters <paul at nohats.ca>
| On Sun, 20 Apr 2014, D. Hugh Redelmeier wrote:
|
| > Each conn can have an address pool. If two conns' address pools are
| > identical, they are shared (a single common pool).
|
| Sounds good.
|
| > If two address-pools overlap, but not exactly, each pool is separate in
| > the addresspool logic: each pool could allocate the same address without
| > being aware of it.
|
| I think that's a bug.
I agree. Loading a conn that tries to do this should fail. That way
we have won't get into an inconsistent situation inside Pluto.
| However, what happens when one client using 1 ID connects to both conns?
| Does it get the same IP or is it "taken"? I don't care much as long as
| we handle this case without causing server errors.
Within a single pool, a single client ID will get a single IP address
across all connections that share that pool.
If connections use different pools, the same ID will be given
different IPs through each pool.
Note 1: Currently, the unique ids setting has no effect on this
behaviour. Perhaps !unique ids should change behaviour.
Note 2: if the ID is ID_NONE, the rules are different. We cannot tell
if two things with ID_NONE are the same or different. So (I think) we
act as if every one is different.
Note 1, meet Note 2: It seems to me that the !unique ids setting
should make all IDs behave like ID_NONE. This might not be useful.
So perhaps !unique ids logic isn't useful in the context of
addresspool.
| The alternative is to have pools completely disjoint from connections as
| their own "entities".
My model is that pools are distinct entities. They are identified by
their IP range: different ranges are different pools. Connections
share a pool if the pool ranges they specified are identical.
| I
| am all in favour or a simple solution, and if it gets too complicated to
| hand the job over to something else (eg Radius / Diameter or dhcpd)
I don't know what they can do, but I agree with the sentiment.
More information about the Swan-dev
mailing list