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 (Glenn Satchell)
2. Re: DHCP issues 2 (Simon)
3. Re: isc dhcp server and client query (Simon)
----------------------------------------------------------------------
Message: 1
Date: Fri, 03 Jun 2022 20:03:50 +1000
From: Glenn Satchell <glenn.satch...@uniq.com.au>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Question
Message-ID: <d17429d97020f723afe88d6b3618d...@uniq.com.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
ok, now we are getting somewhere...
Note startup error messages should be in syslog, or perhaps "systemctl
status isc-dhcp-server" will show them.
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.
Next in the failover peer section, both config files have "primary". One
of them needs to be "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.
# backup
failover peer "dhcp-failover" {
secondary; # declare this to be the secondary server
address 192.168.1.51;
port 647;
peer address 192.168.1.50;
peer port 647;
max-response-delay 30;
max-unacked-updates 10;
load balance max seconds 3;
split 128;
}
# primary
failover peer "dhcp-failover" {
primary; # declare this to be the primary server
address 192.168.1.50;
port 647;
peer address 192.168.1.51;
peer port 647;
max-response-delay 30;
max-unacked-updates 10;
load balance max seconds 3;
split 128;
mclt 3600; # only on primary
}
With this change I think it should work now... fingers crossed :)
regards,
Glenn
On 2022-06-03 19:33, Leslie Rhorer wrote:
> ??? Oi, veh!? Something else has died, now, and I don't know what or
> how.? The only change I made was the one listed below, and now dhcpd
> won't run from /etc/init.d/isc-dhcp-server.? Rather, it runs, but then
> it quits.? I can run it manually from the CL with exactly the same
> syntax, and it remains up, but then the primary server quits.
>
> On 6/3/2022 4:03 AM, Leslie Rhorer wrote:
>> Well, I found one error left over from when this was a /24 network.?
>> The range definition on the secondary server was from 192.168.1.220 to
>> 192.168.1.240, instead of 192.168.0.200 to 192.168.0.240.? You can see
>> the error in the backup.conf.gz file. I am not sure what issues this
>> would cause, other than of course serving addresses in a range I want
>> to change.
>>
>> On 6/3/2022 2:45 AM, Glenn Satchell wrote:
>>> Hi Leslie,
>>>
>>> Ok I can see a packet flow in that pcap file between the two servers.
>>> It shows a TCP packet from 192.168.1.50 port 46869 with the SYN [S]
>>> flag to 192.168.1.51 port 647 - so that's trying to open the
>>> connection.
>>> 192.168.1.51 responds with RST [R] flag, so 192.168.50 tries again,
>>> and on it goes. So looks like 192.168.51 is not listening on that
>>> port. There's no failover connection being established. So we have
>>> that to sort out first.
>>>
>>> $ tcpdump -r secondary.pcap -v
>>> reading from file secondary.pcap, link-type EN10MB (Ethernet)
>>> 16:23:34.924575 IP (tos 0x0, ttl 64, id 46213, offset 0, flags [DF],
>>> proto TCP (6), length 60)
>>> ??? 192.168.1.50.46869 > 192.168.1.51.647: Flags [S], cksum 0xdfce
>>> (correct), seq 4009562500, win 64240, options [mss 1460,sackOK,TS val
>>> 3809692760 ecr 0,nop,wscale 7], length 0
>>> 16:23:34.924599 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
>>> proto TCP (6), length 40)
>>> ??? 192.168.1.51.647 > 192.168.1.50.46869: Flags [R.], cksum 0x71fb
>>> (correct), seq 0, ack 4009562501, win 0, length 0
>>> 16:23:39.925032 IP (tos 0x0, ttl 64, id 20478, offset 0, flags [DF],
>>> proto TCP (6), length 60)
>>> ??? 192.168.1.50.57529 > 192.168.1.51.647: Flags [S], cksum 0x995f
>>> (correct), seq 2790876011, win 64240, options [mss 1460,sackOK,TS val
>>> 3809697760 ecr 0,nop,wscale 7], length 0
>>> 16:23:39.925054 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
>>> proto TCP (6), length 40)
>>> ??? 192.168.1.51.647 > 192.168.1.50.57529: Flags [R.], cksum 0x3f14
>>> (correct), seq 0, ack 2790876012, win 0, length 0
>>>
>>> When I look at it with wireshark it's the same but perhaps shown a
>>> little more clearly
>>>
>>> 1??? 0.000000??? 192.168.1.50??? 192.168.1.51??? TCP??? 74 46869 ?
>>> 647 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3809692760
>>> TSecr=0 WS=128
>>> 2??? 0.000024??? 192.168.1.51??? 192.168.1.50??? TCP??? 54 647 ?
>>> 46869 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
>>> 3??? 5.000457??? 192.168.1.50??? 192.168.1.51??? TCP??? 74 57529 ?
>>> 647 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3809697760
>>> TSecr=0 WS=128
>>> 4??? 5.000479??? 192.168.1.51??? 192.168.1.50??? TCP??? 54 647 ?
>>> 57529 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
>>> 5??? 10.000924??? 192.168.1.50??? 192.168.1.51??? TCP??? 74 51935 ?
>>> 647 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3809702760
>>> TSecr=0 WS=128
>>> 6??? 10.000945??? 192.168.1.51??? 192.168.1.50??? TCP??? 54 647 ?
>>> 51935 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
>>> 7??? 15.001390??? 192.168.1.50??? 192.168.1.51??? TCP??? 74 57497 ?
>>> 647 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3809707761
>>> TSecr=0 WS=128
>>>
>>> Can you please post the failover peer definitions for both dhcp
>>> servers, I think we need to check that they make sense. Second the
>>> interface configs for that interface on each server, output from "ip
>>> addr show ethX" or whatever the correct interface name is please. We
>>> need to be sure the address, netmask, etc, match up.
>>>
>>> So that packet capture is very useful. It's pin pointed an issue
>>> straight away.
>>>
>>> regards,
>>> Glenn
>>>
>>> On 2022-06-03 16:37, Leslie Rhorer wrote:
>>>> ??? 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.
>>
------------------------------
Message: 2
Date: Fri, 3 Jun 2022 11:27:44 +0100
From: Simon <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DHCP issues 2
Message-ID: <bfa15c7c-ccdc-4bc6-8794-3d33702a0...@thehobsons.co.uk>
Content-Type: text/plain; charset=utf-8
Leslie Rhorer <lesrho...@siliconventures.net> wrote:
>
> On 6/2/2022 5:52 PM, Leslie Rhorer wrote:
>> On 6/2/2022 2:00 PM, Simon wrote:
>>> Leslie Rhorer <lesrho...@siliconventures.net> wrote:
>>>
>>>> 2. Stopping the service does not actually do anything. The .pid file
>>>> remains intact and the service remains in memory. Having to manually
>>>> delete the .pid file and manually kill the daemon is a pain, especially
>>>> right now since I am setting things up and restarting the service a lot.
>>> That is easy to answer - it?s NOT a DHCP server issue, that?s a
>>> distro/packaging issue.
>>> Since I don?t use systemd, I can?t help further in terms of the
>>> startup/shutdown problems.
>>
>> I would be inclined to agree, except for two things:
>>
>> 1. Why is it happening on the secondary and not the primary? They are the
>> same version of the same distro.
>>
>> 2. Why is dhcpd sending an exit code of 1? That is why systemd thinks
>> there is a failure. Dhcpd (or any daemon) is supposed to send an exit code
>> of 0.
>
>
> I found the problem. It was not a distro issue. It was my error.
> Before I wiped the OS, there was some sort of fatal error going on. For
> testing purposes, I disabled IPv6 in the /etc/defaults/isc-dhcp-server file,
> but I accidentally neglected to comment out the INTERFACESv6 line. This was
> causing dhcpd to issue an exit code of 1. This not only caused the start
> option to report an error, but also was preventing the stop option from
> cleaning up the .pid file and terminating the daemon. Before wiping the OS,
> I copied all the config files to a backup and restored them after the
> re-install. This cleared whatever was causing the fatal issue, but retained
> the spurious error report.
You beat me to it - I was going to add that you really needed to sort out what
was failing at start - and that really means seeing the logs because the server
would have given a clue in the logs. One way to try and work around this would
be to try and figure out exactly what command line was used to start the
service and to try starting it manually from the command line (adding the
?don?t background yourself? flag) - that way you could see what diagnostics
were given.
If the service started but the process manager (systemd) thought it hadn?t,
then on ?stopping? the service, it looks like the service manager is doing
nothing on the basis of ?it?s not running so nothing to stop?.
Simon
------------------------------
Message: 3
Date: Fri, 3 Jun 2022 11:39:01 +0100
From: Simon <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: isc dhcp server and client query
Message-ID: <2604bd21-ac50-4391-bd36-e57889c66...@thehobsons.co.uk>
Content-Type: text/plain; charset=utf-8
Asma Kouser <kous...@medha.com> wrote:
> I am using ISC DHCP-4.3.6, and have a scenario in which the server is
> not allocating the IP address. I have updated the dhcpd.conf to give an IP
> address based on 'agent.circuit-id' and 'agent.remote-id' and there is only
> one IP in the pool to assign. When I connect a laptop the switch will add the
> agent info and forward it to the DHCP server and the DHCP server assigned the
> address which is defined in the Pool. now I have removed this laptop and
> connected another laptop on the same port, now the hardware address and the
> hostname will change but the agent information remains the same, in this
> case, the server is not allocating the IP address and says no free lease.
This is a known problem setting up such an arrangement. Even though you are
using agent.<id> to allocate IPs to clients, the server internally still tracks
leases again the Client-ID (or if that?s not present, it falls back to MAC
address) - you?ll be able to see this int eh leases file.
So when you replace the client, as far as the server is concerned, it has no
address it can give to the client - your config with agent.<id> will specify a
specific IP address, but that address is still leased to the old client until
it times out (or you manually release it - e.g. via OMAPI).
> Also, the ISC DHCP client does not send a DHCP Discovery or a request when
> the ethernet link is down and up again. Please let me know what modifications
> should I do to achieve this as well.
That will be down to the network management on your client. The client itself
doesn?t manage interfaces - it relies on the OS?s network manager to start it
and stop it as interfaces come up and down.
Simon
------------------------------
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 10
*******************************************
