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: ISC DHCPv6-BIND9 DDNS update problem (Simon)
2. Re: DHCP Lease (Simon Hobson)
3. Re: DHCP Lease (Glenn Satchell)
4. Re: ISC DHCPv6-BIND9 DDNS update problem (Glenn Satchell)
----------------------------------------------------------------------
Message: 1
Date: Thu, 9 Jun 2022 15:50:34 +0100
From: Simon <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: ISC DHCPv6-BIND9 DDNS update problem
Message-ID: <52b7df64-17ff-4d0c-8045-85072a3e4...@thehobsons.co.uk>
Content-Type: text/plain; charset=utf-8
Mirsad Goran Todorovac <mirsad.todoro...@alu.unizg.hr> wrote:
> It seems that I have identified the culprit. Our subnet has 6 rogue DHCPv6
> servers according to this nmap scan:
Yeah, that would do it. Time to get out the clue bat, or ?clue by four?, and
start some user education :D
But more seriously, on a network of any size, and especially if using RAs to
trigger use of DHCP for address assignment, your network infrastructure should
at the very least alert you to rogue DHCP servers - and preferably block them
(by filtering the packets) at the edge switch ports. Without that, as you?ve
experienced, anyone can start up a rogue service - whether accidentally or
maliciously.
The same applies to RAs - without rogue detection and isolation, anyone can
break your network and/or hijack traffic.
Regards, Simon
------------------------------
Message: 2
Date: Thu, 9 Jun 2022 16:06:33 +0100
From: Simon Hobson <si...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DHCP Lease
Message-ID: <68609bf7-60f1-4cd8-8ed3-8cc2b963f...@thehobsons.co.uk>
Content-Type: text/plain; charset=utf-8
Soporte VT <sopo...@vallecastelecom.com> wrote:
> I want to delete a lease, for example, this one below instead of waiting
> eight hours. What is the correct way to do it? I mean, I do not want to screw
> the DHCP service up. So, could someone give me some advice to approach this
> task? Thanks a lot.
As greg has already indicated, there are a number of ways, and the ?best? (or
perhaps, "least bad?) will vary depending on the reason.
Looking at some of the values in that lease (particularly the presence of
agent.circuit-id), I?m going to hazard a guess that there?s some form of
?assign lease based on circuit ID? logic going on, and this causes a problem
when the client changes and there?s no free lease.
Perhaps the cleanest approach might be to use OMAPI to change the expiry time
of the lease to ?not far into the future? so that the server will expire the
lease itself and clean up (DDNS, execute any scripts, etc) automatically. I?ve
not used OMAPI myself, and don?t use failover these days (only have my home
network to manage), but I believe you have to do this on both servers.
Otherwise, as Greg says, you can stop the server and delete all entries for the
lease - but you?ll have to do your own cleanup. With failover there is the
complication that agin, you have to do this on both servers - with scope for a
service interruption if you don?t manage timings & failover states well.
Kind of thinking around the issue, I also wonder if there?s scope to create a
lease update that would replace the lease with a blank free or soon to expire
version (basically, the bare minimum needed for the server to recognise it as a
lease for that IP) in such a way that doing it on one server would
automatically duplicate it to the other.
Perhaps a simple script that injects a DHCP-Release message to one or other
server ?
Regards, Simon
------------------------------
Message: 3
Date: Fri, 10 Jun 2022 09:57:30 +1000
From: Glenn Satchell <glenn.satch...@uniq.com.au>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DHCP Lease
Message-ID: <54af6b8fe704da31c11972eb2ae52...@uniq.com.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
So this is talking about changing the server. The client has a lease and
an IP address which it will continue to use. Deleting the lease on the
server does not delete the lease on the client. You'll need to track
down this client and release the lease there too (dhclient -r on linux;
ipconfig /release on windows).
regards,
Glenn
On 2022-06-10 01:06, Simon Hobson wrote:
> Soporte VT <sopo...@vallecastelecom.com> wrote:
>
>> I want to delete a lease, for example, this one below instead of
>> waiting eight hours. What is the correct way to do it? I mean, I do
>> not want to screw the DHCP service up. So, could someone give me some
>> advice to approach this task? Thanks a lot.
>
> As greg has already indicated, there are a number of ways, and the
> ?best? (or perhaps, "least bad?) will vary depending on the reason.
>
> Looking at some of the values in that lease (particularly the presence
> of agent.circuit-id), I?m going to hazard a guess that there?s some
> form of ?assign lease based on circuit ID? logic going on, and this
> causes a problem when the client changes and there?s no free lease.
>
> Perhaps the cleanest approach might be to use OMAPI to change the
> expiry time of the lease to ?not far into the future? so that the
> server will expire the lease itself and clean up (DDNS, execute any
> scripts, etc) automatically. I?ve not used OMAPI myself, and don?t use
> failover these days (only have my home network to manage), but I
> believe you have to do this on both servers.
>
> Otherwise, as Greg says, you can stop the server and delete all
> entries for the lease - but you?ll have to do your own cleanup. With
> failover there is the complication that agin, you have to do this on
> both servers - with scope for a service interruption if you don?t
> manage timings & failover states well.
>
> Kind of thinking around the issue, I also wonder if there?s scope to
> create a lease update that would replace the lease with a blank free
> or soon to expire version (basically, the bare minimum needed for the
> server to recognise it as a lease for that IP) in such a way that
> doing it on one server would automatically duplicate it to the other.
> Perhaps a simple script that injects a DHCP-Release message to one or
> other server ?
>
> Regards, Simon
------------------------------
Message: 4
Date: Fri, 10 Jun 2022 11:09:51 +1000
From: Glenn Satchell <glenn.satch...@uniq.com.au>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: ISC DHCPv6-BIND9 DDNS update problem
Message-ID: <5ea983859e9913fb0982669b2b9a2...@uniq.com.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Mirsad,
I think offloading the checksum is not a problem, it's just that tcpdump
sees the packet before it gets into the network interface card where the
checksum is calculated. I think if you turn that back on it will make no
difference.
This explains it quite well:
https://serverfault.com/questions/776253/how-does-tcp-offload-nic-cause-the-tcp-checksum-to-be-invalid
regards,
Glenn
On 2022-06-09 19:58, Mirsad Goran Todorovac wrote:
> P.P.S.
>
> I have turned off NIC checksum offloading by `ethtool -K eth1 rx off tx
> off`. Now the UDP checksum should be calculated in the kernel (slower).
>
> 11:54:40.438248 IP6 (hlim 1, next-header UDP (17) payload length: 103)
> fe80::9418:9a22:54b8:743f.546 > ff02::1:2.547: [udp sum ok] dhcp6
> solicit (xid=a1f102 (elapsed-time 0) (client-ID hwaddr/time type 1 time
> 499890753 f0761c5b0dd5) (IA_NA IAID:338441082 T1:0 T2:0) (Client-FQDN)
> (vendor-class) (option-request DNS-search-list DNS-server
> vendor-specific-info Client-FQDN))
> 11:54:40.438928 IP6 (flowlabel 0x82364, hlim 64, next-header UDP (17)
> payload length: 159) fe80::f21f:afff:fef1:420a.547 >
> fe80::9418:9a22:54b8:743f.546: [udp sum ok] dhcp6 advertise (xid=a1f102
> (IA_NA IAID:338441082 T1:3600 T2:7200 (IA_ADDR 2001:b68:2:2800::10:139d
> pltime:604800 vltime:3600)) (client-ID hwaddr/time type 1 time
> 499890753 f0761c5b0dd5) (server-ID hwaddr/time type 1 time 707489786
> f01faff1420a) (preference 255) (DNS-search-list local.alu.hr. alu.hr.)
> (DNS-server 2001:b68:2:2800::3 2001:b68:c:2::70:0))
> 11:54:41.445113 IP6 (hlim 1, next-header UDP (17) payload length: 103)
> fe80::9418:9a22:54b8:743f.546 > ff02::1:2.547: [udp sum ok] dhcp6
> solicit (xid=a1f102 (elapsed-time 100) (client-ID hwaddr/time type 1
> time 499890753 f0761c5b0dd5) (IA_NA IAID:338441082 T1:0 T2:0)
> (Client-FQDN) (vendor-class) (option-request DNS-search-list DNS-server
> vendor-specific-info Client-FQDN))
>
> Now the checksums are OK, however the server still doesn't receive
> Request or Confirm message from the client.
> I'm pretty much out of ideas.
>
> Mirsad
> --
> Mirsad Todorovac
> CARNet system engineer
> Faculty of Graphic Arts | Academy of Fine Arts
> University of Zagreb
> Republic of Croatia, the European Union
> --
> CARNet sistem in?enjer
> Grafi?ki fakultet | Akademija likovnih umjetnosti
> Sveu?ili?te u Zagrebu
------------------------------
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 20
*******************************************
