Relayed subnet migration

[Niall O'Reilly]

On 16 May 2006, at 00:11, Robert Fisher wrote:
> Basically, what I want to know is that is there some method that  
> when a
> lease renewal
> request is received for a range that is no longer valid in which a
> release and renew
> attempt can be handled?

We found it necessary to use complementary 'deny' statements to force
'known' and 'unknown' clients respectively to use the desired subnet.
Before that, we were finding that previously 'unknown' clients, after
making the (administrative) transition to 'known', kept renewing the
lease they had acquired when 'unknown'.

The configuration fragment below illustrates (with some obfuscation)
what we do now.  We actually use a public address block for the first
subnet ('deny unknown') and a private block for the second.

     shared-network mumble-flame {
         subnet 192.168.163.0 netmask 255.255.255.0 {
             option subnet-mask 255.255.255.0;
             option routers 192.168.163.1;
             pool {
                 range 192.168.163.129 192.168.163.254;
                 deny unknown clients;
                 max-lease-time 7200;
             }
         }

         subnet 10.192.163.0 netmask 255.255.255.0 {
             option subnet-mask 255.255.255.0;
             option routers 10.192.163.1;
             pool {
                 range 10.192.163.129 10.192.163.254;
                 deny known clients;
                 max-lease-time 7200;
             }
         }
     }

I hope this helps.



Best regards,

Niall O'Reilly
University College Dublin Computing Services

PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9