Question

[Leslie Rhorer]

     I am seeing a listening connection on the primary server on 647, 
but nothing on the secondary.  I have included the tcdump from the 
secondary on port 647 as a gz file.  'Still waiting on the dumps on 
ports 67 and 68 (it's taking a while for 100 packets to pass)

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: 2513 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20220603/51faca06/attachment-0001.gz>