Send dhcp-users mailing list submissions to dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.isc.org/mailman/listinfo/dhcp-users or, via email, send a message with subject or body 'help' to dhcp-users-requ...@lists.isc.org You can reach the person managing the list at dhcp-users-ow...@lists.isc.org When replying, please edit your Subject line so it is more specific than "Re: Contents of dhcp-users digest..." Today's Topics: 1. Re: OMAPI Reservations and peer/failover (Gregory Sloop) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Jun 2021 07:29:32 -0700 From: Gregory Sloop <gr...@sloop.net> To: Users of ISC DHCP <dhcp-users@lists.isc.org> Subject: Re: OMAPI Reservations and peer/failover Message-ID: <1443392775.20210601072...@sloop.net> Content-Type: text/plain; charset="us-ascii" Top posting: gsuca> the information from the other server. You would probably need to look gsuca> at the source to see what fields get copied over during this process, eg gsuca> the reserved field Source code?! You would probably suggest that I run with scissors too, eh!? (Me reading source code could be at least as dangerous!) :) So, I just just took the easy route; Stopped the peer (non-master/primary peer - though I think it should be fine either way), deleted the leases file, started it back up, and waited (MCLT/2) time, till they came back to normal. All the reserved flags ARE set in the peers' leases file, where I deleted the leases file. So, I think that's a definitive answer. So, at least for reserved flags (I can't answer for anything else) once set on both peers, if one peer is lost and rebuilt from scratch, the reserved flags will get populated from the still surviving peer in the leases file.. Again, thanks all for the input. -Greg gsuca> On 2021-05-29 05:00, Simon Hobson wrote: >> Gregory Sloop <gr...@sloop.net> wrote: >>> Given what I've been able to dig up on the subject of omapi and peers, >>> I'm pretty sure you have to run against both, explicitly. >>> But, additional complication arise! >>> As noted, a fair bit of reading and searching seems to indicate you >>> have to run the omshell commands against each server. >>> However, this is particularly interesting (or perhaps troubling.) >>> See: >>> https://lists.isc.org/mailman/htdig/dhcp-users/2006-July/001102.html >>> To save you the click, I'll quote... >>> --- >>> "You will have to rerun the statement on both peers. >>> Take careful note of servers that lose their dhcpd.leases files, >>> you'll have to be able to 0-to-60 them by replaying everything. " >>> --- >>> There was no expansion on this - and my understanding of it is >>> somewhat ambiguous. >>> Does this mean that if I have a peer that gets rebuild and the leases >>> file is deleted, it won't get a copy of the "original" leases file >>> from it's peer and that all the "reservation" flags will be lost and I >>> will have to re-run all the omapi commands against the peer which lost >>> the leases file? >>> Assuming that's the correct interpretation... >>> I suppose that it's best then, to copy the leases file from the >>> "still-up' peer to the rebuilt peer. (I can't see a reason not to do >>> this, but perhaps I'm missing something.) >> That is indeed an odd statement. >> I can completely understand it for a standalone peer - if it loses >> it's leases file then all your OMAPI made changes will be gone. >> But since the a major point of failover is for a server to be able to >> rebuild itself after a disaster, I would have expected failover to >> take care of that. I suggest you do a trial with a test server - my >> expectation is that if you bring up the peer with no leases file, then >> it'll get everything from it's partner. >> However, the warning still holds. Should your shared leases get >> corrupted or lost, then you'd lose all your changes and need to >> re-play them. I'm not sure under what circumstances both servers could >> lose/corrupt their leases, but I'm sure there will be some. >> I know that on a single server, if you remove some addresses from the >> defined ranges, then any leases defined for them will be removed on >> server startup. So, especially if you build a config and run it out to >> both servers at once, it's possible to lose a bunch of leases that >> way. >> Simon gsuca> Instead of using a reserved lease, how about just setting it to a really gsuca> long time instead, say 3, 6 or 12 months? Use a class or group for these gsuca> special leases. Since that goes in dhcpd.conf it will survive loss of gsuca> the leases file. gsuca> Also note that while the leases recorded in the leases file are the same gsuca> for a failover peer, the actual files are not identical. Various gsuca> settings such as "failover peer state", tstp, tsfp, atsfp, cltt can be gsuca> different. "binding state backup" is a special state for failover. So gsuca> you can't just copy one dhcpd.leases file to the other server. gsuca> With a failover setup, the two servers should synchronise their leases gsuca> by themselves, thus a server with an empty leases file should build up gsuca> the information from the other server. You would probably need to look gsuca> at the source to see what fields get copied over during this process, eg gsuca> the reserved field. gsuca> So in server/db.c write_lease() has a statement to write out the gsuca> reserved statement to dhcpd.leases: gsuca> if (lease->flags & RESERVED_LEASE) gsuca> if (fprintf(db_file, "\n reserved;") < 0) gsuca> ++errors; gsuca> but I still don't know if this gets replicated in a failover gsuca> configuration. Probably need to look in server/failover.c at gsuca> dhcp_failover_startup() gsuca> regards, gsuca> Glenn gsuca> _______________________________________________ gsuca> ISC funds the development of this software with paid support gsuca> subscriptions. Contact us at https://www.isc.org/contact/ for more information. gsuca> dhcp-users mailing list gsuca> dhcp-users@lists.isc.org gsuca> https://lists.isc.org/mailman/listinfo/dhcp-users -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20210601/bd24c832/attachment-0001.htm> ------------------------------ Subject: Digest Footer _______________________________________________ ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. dhcp-users mailing list dhcp-users@lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users ------------------------------ End of dhcp-users Digest, Vol 152, Issue 1 ******************************************