[Swan-dev] does the address pool really share leases?
andrew.cagney at gmail.com
Sat Sep 28 01:34:24 UTC 2019
On Fri, 27 Sep 2019 at 15:04, Paul Wouters <paul at nohats.ca> wrote:
> On Thu, 26 Sep 2019, Andrew Cagney wrote:
> > I'm trying to understand shared leases - while the code gives the
> > impression that arbitrary connections can share leases I suspect that
> > isn't true. Instead, I suspect there are two scenarios:
> I think you are mising up "shared lease" with "shared pool" ?
* Leases are shared between appropriate connections.
static bool can_share_lease(const struct connection *c)
so I guess sharing but not as we know it
> Connections can share a single pool of leases. Each lease can only be
> handed out once, and is only potentially available to another connection
> instance of the same user (as identified by the user ID)
> > - where an SA shuts down (cleanly), so that the same lease might be
> > assigned when the SA later re-establishes, the id:lease pair
> > this doesn't involve sharing, but is only useful when leases can be
> > uniquely identified using the ID
> Yes, this is not "sharing" though. It is mostly just trying to give the
> same IP to the same user to try and prevent connections that were still
> open from breaking. Ideally, with things like MOBIKE, that would not
> > - where a new CHILD SA is trying to steal an existing lease
> > . SAs establish with a lease assigned
> > . something goes wrong, an end starts bringing up a new SA and wants
> > to re-use the old lease (but it is still reserved by the old SA)
> > . since the IDs match the lease is shared
> > . when the new SA hits the kernel things get updated
> > . when the old SA gets zapped, the sharing stops
> > - is there anything else?
> I don't think so.
> > More generally, the second problem seems to have a lot in common with
> > connection instances - trying to pair up a new SA with an existing but
> > failing instance using the ID. Can (shared) leases only be assigned
> > to connection instances and vice versa?
> In practise yes. In theory, a static client with left=ip, right=ip
> could use the client mechanism to request an IP(4 and/or 6) and get
> this from the addresspool? eg:
> conn test1
> but it would be a strange use of it. Because you could just rewrite that to:
> conn test2
> A pool does kind of imply right=%any and instantiation. And if it helps
> you, I wouldn't mind failing to load the above conn test1.
I'll keep that in mind, but I don't think I need it.
The current code is maintaining, and constantly scanning, an ordered
linked list of assigned (and released) addresses. With "shared
leases" I suspect the list grows until there's an entry for every
possible assigned address - consider 10.0.0.0/8.
By simply changing the list to an array (and doubled in size as
needed) I suspect most of this goes away (sprinkled with some lists,
and slightly more aggressive address reuse strategy, and a hash table
for ID->lease). At least that's the theory.
More information about the Swan-dev