Nicolas Williams writes: > > Note that in the solution described in the original project (the one > > just approved by PSARC), we do not release the lease or clear out the > > interface before exiting. I think that's actually the safest thing to > > do, and the most in tune with the standards. > > That wasn't clear to me because the case materials simply spoke of not > "canonizing" a DHCP interface when a new ioctl indicates that iSCSI > depends on it, and it defined "canonizing" as resetting the interface to > 0.0.0.0.
Nuking the address on the interface is what causes the biggest problem for iSCSI, which is why the document talked about that specifically. > If the actual proposal is to not release the lease, then I think that's > a fine proposal. Yes; it's the same as with NFS. We just bail out without the normal shutdown process. Obviously, we could use a *lot* more finesse here. There's no need to do this unless the specific interface used to communicate with the iSCSI target is under DHCP control. Except of course for routing- level fail-over, it should be "safe enough" to wipe out interfaces that are irrelevant to the problem. I guess I'm unconvinced, though, that this is the end of the problem. Anything that could potentially "lock up" (e.g., an NFSv4 mount) during shutdown due to the loss of an interface at the wrong time is something that needs to be addressed with a dependency. > I agree. An option to set negatively extend the lease time to now+5m > or some such suitable value could be handy. I don't know if it's > possible to use DHCP option 58 (or some other option) in this way in a > DHCPREQUEST. That sounds like a good idea. If only we knew that we would be shutting down in that amount of time. I'd be weakly supportive of having a kernel feature that allows dhcpagent to set a time bomb: first have it tell the DHCP server that we want only another 5 minutes, then tell the kernel to tear down the interface if 5 minutes elapses and the OS hasn't yet halted. It might be tricky, though. > In any case, if we're really worried about continuing to use an address > after the lease expires, then one'd think it'd be good for the kernel to > enforce lease expiration just in case dhcpagent died hard and isn't > getting restarted. Yes, that'd be another instance of the time-bomb concept above. When initially configuring, set the bomb to go off when the lease expires, so that no matter what happens to dhcpagent, we're being "good" on the network. The argument against that (at least historically) is that dhcpagent is part of the OS. We shouldn't have to code against its failure any more than we should have to code against kernel panics. :-/ -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
