Question

[Leslie Rhorer]

On 6/3/2022 10:39 AM, Gregory Sloop wrote:
>
> Are you *sure* that both machines are on the same broadcast network?
>
> (Or at least have a dhcp helper that will relay dhcp broadcasts?)
>
> Just because the peers can talk to each other (finally) doesn't mean 
> they're on the same broadcast network.
>
     Yes, I am sure.  The servers are plugged into the same switch, and 
they have adjacent IP addresses (192.168.1.50/23 and 192.168.1.51/23).
>
> (And, as far as packet capture. I doubt that you need 10G between the 
> peers - so you could always force the ports to something slower - 
> 100Mbps would probably be way more bandwidth than peer 
> communication/leases really needs - then a packet capture should be 
> easy. (And once you've got it working, turn the speed back up, if you 
> really want/need it.)
>
     Not necessary.  Over time, now, they have both served numerous IP 
addresses.  I was just mildly surprised the hosts were sending unicast 
requests, but I suppose it makes sense.  It cuts down a little - not 
much - on broadcast traffic, making the network more efficient.
>
> Really short leases can help drive up traffic and allow you to see 
> more lease cycles more quickly - good for testing - probably not so 
> great for production.
>
> -Greg
>
>
>
>          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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20220603/e8a9e539/attachment-0001.htm>