Question
Leslie Rhorer
lesrhorer at siliconventures.net
Fri Jun 3 08:43:43 UTC 2022
Here are the captures of the DHCP packets on both servers.
On 6/3/2022 1:03 AM, Glenn Satchell wrote:
> Hi Leslie,
>
> I know about capturing packets on a 10G interface :) many gigabytes in
> a few seconds...
>
> So you need to use filters when capturing, eg with tcpdump
>
> tcpdump -i eth0 host <other dhcp server IP or name> and tcp port 647
>
> will only capture the failover traffic on eth0 directed to or from the
> other server, and ignore the rest.
>
> tcpdump udp and port 68 or port 67
>
> will capture dhcp packets.
>
> You can add options like "-c 100" to stop after 100 packets are
> captured. "-w filename" will capture to a file and you can copy this
> file to your desktop and use wireshark to read it.
>
> With failover, it's better to restart one dhcp server, wait for it to
> sync, then restart the other one. If you shut down both and then start
> them, then they come up in recover mode.
>
> Also looking at failover connections:
>
> netstat -ant | grep 647
>
> should show an established connection between the two servers.
>
> regards,
> Glenn
>
> On 2022-06-03 15:39, Leslie Rhorer wrote:
>
>> On 6/2/2022 11:30 PM, Gregory Sloop wrote:
>>
>>> Are you seeing balance messages every hour as the two re-balance the
>>> available lease pool?
>> No, I don't think so. It has only been a couple of hours since I
>> have had both online, however.
>>
>>> You say they are both handling leases properly, but how do you know
>>> this? (That a machine gets a lease from somewhere is not good
>>> evidence.)
>>
>> Do you mean because some other machine / device could be issuing
>> leases? No. In that case,
>>
>> 1. Killing both servers would not take down any DHCP clients. If both
>> servers are shut down, DHCP clients start failing in about an hour,
>> until they are all dead.
>>
>> 2. DHCP responses on the LAN stop completely the moment both servers
>> are taken down.
>>
>> 3. No other machine would know anything about the list of dynamically
>> assigned fixed IP addresses in dhcpd.static. None of the addresses
>> of any of the clients ever change.
>>
>> 4. Whenever one server is shut down, the other responds with tons of
>> responses in the log.
>>
>>> A packet capture in front of the secondary might be helpful to see
>>> what traffic is passing - both to the peer and to clients.
>> While not impossible, that is a bit easier said than done. The links
>> between the servers are 10G. I can look into it.
>>
>>> (I hate making captures, at least as much as the next person, but
>>> dang if they don't, nearly always, show something that was different
>>> than I assumed. So, I've just gotten a lot less averse to getting
>>> captures. Yeah, they'll probably take me extra time to setup and get
>>> and paw through, [all when I could be fixin' stuff!] but they can
>>> save hours or days of fruitless searching for a fix, when I don't
>>> even really *know* what's wrong yet. Don't know about anyone else,
>>> but fixing problems gets a whole lot easier when I actually know
>>> what's wrong, or at least have a good idea what's going on. :)
>>
>> Agreed, although when an interface is chunking away at over 10,000
>> packets per second...
>>
>> If something doesn't break loose, I will see about loading Wireshark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: secondary.pcap.gz
Type: application/gzip
Size: 2157 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20220603/1703ab9b/attachment-0002.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: primary.pcap.gz
Type: application/gzip
Size: 2681 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20220603/1703ab9b/attachment-0003.gz>
More information about the dhcp-users
mailing list