host-identifier and option 82

[Alex Moen]

On Jan 30, 2012, at 2:10 PM, Christian Kratzer wrote:

> Hi,
>
> On Mon, 30 Jan 2012, Marc Perea wrote:
>
>> Greetings,
>> I'm chiming in here because we (an ISP) had a similar situation and  
>> use case and I hope to head off a possible gotcha' if I can. It  
>> sounds to me like you want the dhcpd service to hand back a  
>> specific IP per option 82 circuit, regardless of which MAC address  
>> is presented. Is that accurate?
>
> yes thats at least what I use it for.
>
>> Even though using the static host entry with option 82 does not  
>> result in a MAC address being written to a file, I don't believe  
>> that means that you can swap a new MAC in and have it "just work".  
>> In my estimation, the primary key of the in RAM leasing structure  
>> is still the MAC address
>
> from reading the source there are separate hashses and lookup  
> functions for hosts by hardware address and for hosts by options.  
> Check find_hosts_by_haddr() and find_hosts_by_option() in server/ 
> mdb.c for example.
>
> As I posted earlier this seems to be new after dhcpd 4.x something  
> with earlier versions having only hashes by hardware address.
>
> In our testing we get the expected behaviour of changing the mac of  
> the client and having it "just work" ;)

Good news!

>
>> - or at least the results I've seen first hand seem to indicate  
>> this. We have a few methods of "clearing the lease" - which  
>> although static is still necessary for a new MAC to obtain service.  
>> Even though you short circuit and bypass the leases file by using  
>> static assignment, the dhcp server is still making a promise to  
>> some end device that the IP x.y.z.a is available for it's  
>> _exclusive_ use for the next lease_time seconds. That still gets  
>> tracked, and I believe it's tracked by MAC. So, if you plug another  
>> device into the same circuit as one that has an existing lease, you  
>> will find yourself with the no available leases error in your logs.  
>> At least we do.
>
> if you have handed out a lease to a client and later try to change  
> that to a fixed address I could imagine running into various issues  
> depending on how exactly your system is setup.
>
> The old hack of having a class and small single ip pool per port  
> breaks horribly when the mac changes and the lease is not yet expired.
>
>> One way to fix would be to look for that error and auto-clear  
>> leases as others have described. We've implemented a button on our  
>> support webpage that does the same, as well as a the ability for a  
>> tech. to text (SMS) a special number and have our systems perform  
>> the clear. By the way, using OMAPI you don't have to actually set  
>> the state of the lease to free - it is enough to just modify the  
>> ends time. We set the ends to 0, update, and the lease is free and  
>> available.

On Jan 29, 2012, at 2:26 AM, Christian Kratzer wrote:

> I don't see that much of a need for concatenations of multiple  
> identiers currently as you could always just put all you need in one  
> string.  I do see a need to support multiple different host-ids in  
> one ldap tree. Like for example circuit-id for some hosts and  
> subscriber-id for others.

I am not sure what you mean by this statement.  For instance, we  
(another ISP) use agent-circuit-id, agent-remote-id, and vendor-class- 
identifier on almost all of our networks, utilizing "The old hack of  
having a class and small single ip pool per port" as you put it.  It  
makes for a very long, slow-loading config.  If you can give me an  
example of how to create a host entry using all three of those  
identifiers, I would be very appreciative.  If that does not work,  
then your statement that there is no need is false...  :)

Thanks!

Alex