Option 82 & limit lease 1

[Terry Shipclark]

Hello, in a current deployment in an isp style setup using standard layer 2
switches, we are mapping specific addresses to individual ports.   Using the
Classes below, and having each 48 port switch reside in a different subnet,
we are able to map two private ips to each port.  The second ip was actually
an afterthought as after being deployed we found that even with a short
lease time calls would still come into the helpdesk about not being able to
get an ip.  To minimize these calls we added a second ip to each port and
changed all our usage reporting accordingly.  We would like to now
transition each subnet to public ips, and would rather only reserve a single
ip to each port, so we need another function to minimize the calls when
leases are not available.  A couple of hack type ways of mitigating the
calls would be.

1)  Use log surfer+(http://www.crypt.gen.nz/logsurfer/) with this patch
available at
http://www.miquels.cistron.nl/isc-dhcpd/patch-server::02-log-agent-options.
       Basically logsurfer uses regexp to watch logs, and if a particular
log is found execute an external program, in our case this external program
would use omshell to free the lease
       The patch, basically adds option 82 information to the DHCPDISCOVER
log entry, this way we would only have to watch for a single line in the log

2)  Write a patch which creates an "on error" statement similar to on commit
which would fire when no free leases are available.
       This seems like it would be tedious, however would then be a lot
better as we would not have to introduce a second daemon to the box.  The on
error could execute an external program with the agent-id and client-id
directly when no free  leases occurs.

3)  Release ip on snmp trap "Port Down"
       We haven't really investigated this too much, as we believe it would
put undue stress on the server, in circumstances such as client rebooting or
transitioning between port down and port up.

I would love to hear pros and cons of the 1st option, as this is the option
I am currently investigating.  Based upon my analysis, assuming that log
surfer doesnt have too much of a footprint and can process the logs in a
timely manner, it would work, and would only temporarily slow a clients dhcp
process when the lease is unavailable.

I would also love to hear if the second option seems like a viable hack, I
understand that the execute is called inline.


I have read many an article as how people are attempting to accomplish
something very similar, and I am sure larger sites have tweaked there dhcp
to do just that.

I then read this post
https://lists.isc.org/pipermail/dhcp-users/2010-March/010965.html, which
says:

If you don't require to maintain state on the assigned leases, the
> best thing, as was suggested, is the new host record "option matching"
> semantic in 4.2.0.
>
>
Now as I am new to the list I am not sure when this version is proposed to
be stable, however I believe this is exactly the type of functionality I am
looking to implement, as we will be limiting mac learning on the layer 2
switch to 1, and not allowing anything questionable.



I know that I have asked a lot of questions and probably some of it doesnt
make sense, but I would appreciate any feedback, suggestions or criticism on
the subject, and what I propose.






class "Port1"
{
    match if binary-to-ascii (10, 32, "",   suffix    ( option
agent.circuit-id, 4)     ) = "1";
    spawn with option agent.remote-id;

}

class "Port2"
{
    match if binary-to-ascii (10, 32, "",   suffix    ( option
agent.circuit-id, 4)     ) = "2";
    spawn with option agent.remote-id;
}


...LINES OMITTED...

class "Port47"
{
    match if binary-to-ascii (10, 32, "",   suffix    ( option
agent.circuit-id, 4)     ) = "47";
    spawn with option agent.remote-id;

}

class "Port48"
{
    match if binary-to-ascii (10, 32, "",   suffix    ( option
agent.circuit-id, 4)     ) = "48";
    spawn with option agent.remote-id;

}


#Sample Subnet Declaration
subnet 10.104.135.0 netmask 255.255.255.0{
    option routers 10.104.135.1;
    pool{ allow members of "Port1"; range 10.104.135.11; }
    pool{ allow members of "Port1"; range 10.104.135.201; }
    pool{ allow members of "Port2"; range 10.104.135.12; }
    pool{ allow members of "Port2"; range 10.104.135.202; }
   .....LINES OMITTED......
   pool{
        range 10.104.135.128 10.104.135.200;
        allow members of "Port24";
        allow members of "Port25";
        allow members of "Port26";
        allow members of "Port27";
        allow members of "Port28";
        allow members of "Port29";
    }
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20100309/8c349fbc/attachment.html>