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: Question (Leslie Rhorer)
2. Re: Question (Glenn Satchell)
3. Re: Question (Leslie Rhorer)
----------------------------------------------------------------------
Message: 1
Date: Fri, 3 Jun 2022 00:39:59 -0500
From: Leslie Rhorer <lesrho...@siliconventures.net>
To: dhcp-users@lists.isc.org
Subject: Re: Question
Message-ID: <70c10315-5a93-8d3b-cd28-66633c2e2...@siliconventures.net>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
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 --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20220603/ae0cf414/attachment-0001.htm>
------------------------------
Message: 2
Date: Fri, 03 Jun 2022 16:03:07 +1000
From: Glenn Satchell <glenn.satch...@uniq.com.au>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Question
Message-ID: <10619762c8883fbd02a53ac02b080...@uniq.com.au>
Content-Type: text/plain; charset=US-ASCII; format=flowed
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.
------------------------------
Message: 3
Date: Fri, 3 Jun 2022 01:37:20 -0500
From: Leslie Rhorer <lesrho...@siliconventures.net>
To: dhcp-users@lists.isc.org
Subject: Re: Question
Message-ID: <5b583cf7-24b0-51ae-272e-7d9bfdd76...@siliconventures.net>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
??? 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.gz>
------------------------------
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 164, Issue 7
******************************************
