Ignoring existing leases over Option 82 details

[Simon Hobson]

Justin Shore wrote:

>We've configured a dhcpd install for our new FTTH deployment.  We 
>have about 1500 classes and single IP pools defined, one for each 
>ONT. Rather than assign a static IP to each ONT by matching the MAC 
>address, we're using option 82 info set by the upstream OLT.  This 
>will allow a tech in the field to replace a bad ONT without making 
>any changes to the DHCP config.  This is the recommended method from 
>the FTTH manufacturer.
>
>We ran into a problem this afternoon during pre-deployment ONT 
>upgrades.  A tech connected 10 ONTs to an OLT and did a code upgrade 
>on them. The first 10 upgrades went well.  Then the tech 
>disconnected those 10 ONTs and replaced them with 10 new ones. 
>These 10 ONTs were connected to the same physical ports on the OLTs 
>so they should have pulled down the same IPs as the first 10 ONTs. 
>However none of the new ONTs pulled IPs.

It's a known problem. According to the RFC, the server MUST use the 
client-id (if supplied) or the MAC address (if no client-id) as the 
primary key for the database. Your situation is similar to this 
current thread http://marc.info/?t=122349412400006&r=1&w=2, and there 
are plenty of threads on option-82 if you search the archives.

The answer is the same - either get hacking yourself, or persuade ISC 
to implement the feature to allow changing the primary key - it's 
already been said that it's far more likely to happen if someone 
sponsors it.