Question

Leslie Rhorer lesrhorer at siliconventures.net
Fri Jun 3 14:03:37 UTC 2022


     Hmm.  I am not seeing any responses going out from the backup 
server, but when I check, I don't see any incoming requests, either.  
Shouldn't the requests be broadcast packets?  With the primary shut 
down, requests are coming in to the primary and no responses are going out.

On 6/3/2022 8:48 AM, Leslie Rhorer wrote:
> Phew! 'Much better.  I think.  I haven't seen any responses going out 
> from  the seconday, but then only 4 have gone out so far from the 
> primary.  It says the max mis-bal is 6, which I presume 6 means might 
> go out one interface before the other catches up?  We will let it run 
> an hour or so and see if the secondary catches up, and if the leases 
> files are updated.
>
> On 6/3/2022 8:23 AM, Leslie Rhorer wrote:
>>
>> On 6/3/2022 5:03 AM, Glenn Satchell wrote:
>>> ok, now we are getting somewhere...
>>>
>>> Note startup error messages should be in syslog, or perhaps 
>>> "systemctl status isc-dhcp-server" will show them.
>>     I have it logging to /var/log/dhcp/dhcp.log with logrotate 
>> enabled for the directory, but that doesn't really matter.
>>>
>>> So having the "wrong" network range would cause issues, the requests 
>>> come in from a certain subnet, and the server tries to match the 
>>> requests to a subnet definition, but of course on the secondary 
>>> server it doesn't have 192.168.0.0 so it can't offer an address. 
>>> That explains why there is no requests being served.
>>     I think maybe you lost me.  Both are on the same /23 subnet, just 
>> in one case not where I wanted them.  Both 192.168.0.200 - 240 and 
>> 192.168.1.220 - 240 are on 192.168.0/23.
>>>
>>> Next in the failover peer section, both config files have "primary". 
>>> One of them needs to be "secondary"
>>     How the heck did that happen?  I could swear one was set to 
>> "secondary".
>>> , eg changing backup to be the back up server should have this as 
>>> the failover peer setting. mclt is only specified on  primary. This 
>>> would definitely be causing problems now as you have top primary 
>>> failover peers for the same subnet. Before there were two different 
>>> subnets, so no clashes as failover is done on a subnet by subnet 
>>> basis. You could have different peers for each subnet for example.
>>     Hmm, OK, maybe I follow.
>>> With this change I think it should work now... fingers crossed :)
>>>
>>     Yeah.  What you said.


More information about the dhcp-users mailing list