Option 82 & limit lease 1

[Frank Bulk]

We are using the spawn configuration, but allowing two IP addresses each.  I
see a second IP address for 6.2% of our population.  For that volume, it's
worth the savings in helpdesk calls.

That said, I would welcome using "option matching" once I can upgrade to
that version.

Frank

From: dhcp-users-bounces+frnkblk=iname.com at lists.isc.org
[mailto:dhcp-users-bounces+frnkblk=iname.com at lists.isc.org] On Behalf Of
Marc Perea
Sent: Thursday, March 11, 2010 9:48 AM
To: dhcp-users at lists.isc.org
Subject: Re: Option 82 & limit lease 1

 

Hi Terry,

we also map a specific public address to each individual port in an ISP
environment. We've had no calls from subscribers who aren't able to get a
DHCP assignment, but plenty of calls when we swap the customer modem since
the lease is tied to the MAC address instead of the option 82 info. We get
plenty of calls related to BRAS trouble, but that's fuel for a different
list discussion.

 

What's the reason that you're finding no lease is available for a particular
subscriber? I don't understand how that scenario is occurring and would like
to help if I can, but in our environment as long as the same MAC asks for
DHCP from the same location (agent.circuit-id), it always gets the same IP
and we only see no free lease errors when a customer is trying to bridge to
us instead of using our residential gateway. What is the situation that
causes your need to worry about freeing the lease?

 

What I would worry about using option 1 is, let's consider that you did have
a customer bridge and the first device grabs the IP for the circuit and ties
its MAC to DHCP. Then, another device on the customer LAN asks for DHCP, and
your scheme as outlined would turn off service from the server perspective
for the first MAC by freeing the lease and potentially let the second device
get the lease (depending on how you use omshell), at which point you'd have
duplicate IPs on the customer equipment and an inconsistent lease.

 

In our scenario, we just deny any device beyond the first that asks for
DHCP, so we should still get a call - at which point we tell the customer to
install our RG and we run the clear lease process while the customer is on
the phone and hooking it up correctly. Otherwise, at least one of the
customer devices will work and we'll have a valid record of the lease for
it.

 

Of your 3 ideas, I would definitely stick with option 1, but I am still
curious what this process will "fix" for you? I get the impression that 2)
won't work because of the way the server handles DISCOVER errors, and I
agree that 3) is a poor choice.

 

I'm still getting to the 4.2 environment in our lab, but we have high hopes.

 

In your config, you are using spawn with option agent.remote-id. Is there
any particular reason for doing so?

 

Cheers!

 

--Marc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20100420/3bf92e5a/attachment.html>