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 (Mirsad Goran Todorovac)
2. Re: ISC DHCPv6-BIND9 DDNS update problem (Mirsad Goran Todorovac)
----------------------------------------------------------------------
Message: 1
Date: Tue, 21 Jun 2022 08:53:41 +0200
From: Mirsad Goran Todorovac <mirsad.todoro...@alu.unizg.hr>
To: dhcp-users@lists.isc.org
Subject: Re: ISC DHCPv6-BIND9 DDNS update problem
Message-ID: <76258929-1b1f-aa0b-ce72-bad1c8b8b...@alu.unizg.hr>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi all,
Still no solution.
However, we made it to work over a MikroTik DHCPv6 relay, partially.
But what I get at the Windows 10 PC when I do an "IPCONFIG /RENEW6" is:
An error occurred while renewing interface Ethernet : The parameter is
incorrect.
The Wireshark shows that the MAC of the client is relayed to the DHCPv6
server at the central hub,
lease is picked from the pool for the appropriate location
[2001:b68:2:2a00::/64], and the DHCPv6
relay makes an advertisement of the address to the Windows 10 client:
However, the parameters are somehow not good and rejected. Server tries
up to 10 times with Advertise packet, but receives no Confirm.
I've seen an article on the list about Kea parms causing this. Can it be
that I have set an impossible set of DHCPv6 parameters?
default-lease-time 86400;
preferred-lifetime 604800;
option dhcp-renewal-time 3600;
option dhcp-rebinding-time 7200;
allow leasequery;
option dhcp6.name-servers 2001:b68:2:2800::3,2001:b68:c:2::70:0;
option dhcp6.domain-search "alu.hr";
option dhcp6.preference 255;
##option dhcp6.rapid-commit;
option dhcp6.info-refresh-time 21600;
The symptom is the same over the local subnet and over the DHCPv6 relay:
the address is allocated from the pool, Advertised 10x and then the ISC
DHCPv6 server gives up.
There is no Confirm packet from either local link or relay clients,
equally Windows and Linux hosts, default setups.
Thank you for any idea.
I seem to be stuck with this, though there are small steps in the right
direction.
Kind regards,
Mirsad
On 14.6.2022. 9:27, Mirsad Todorovac wrote:
> On 6/10/22 19:14, Simon wrote:
>
>>
>>> Unfortunately, I am not even the admin of all those net segments and
>>> rogue devices. I might be simply out of luck with this one.
>> Presumably you know the network admins who are responsible for those
>> segments ? And presumably there must be a person or group which
>> oversees the network as a whole (subnets/prefixes etc) ? Just letting
>> everyone ?do their own thing? without central planning is a recipe
>> for disaster.
>>
>> So you need to go to them and point out what the problem is, and what
>> needs to be done to fix it. Of course, if they don?t want to then
>> you?re down to internal politics and potentially you end up reporting
>> back to management that you can?t implement what?s asked for because
>> others are actively sabotaging the network (that?s how I?d describe
>> it if supposed network admins are doing nothing to deal with rogue
>> services like this.)
>
> Hi, Simon,
>
> There is a quote that says that it is wrong to attributed to active
> sabotaging what can be explained with neglect and stupidity.
>
> I believe in the most cases these are simply the default settings for
> the devices. Probably someone in those companies thinks that it is a
> good idea to have a dozen of DHCPv6 servers who do not talk to each
> other and have no ideas of other server's IPv6 range - all on the same
> subnet.
>
> Regards,
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20220621/4b48de01/attachment-0001.htm>
------------------------------
Message: 2
Date: Tue, 21 Jun 2022 09:34:24 +0200
From: Mirsad Goran Todorovac <mirsad.todoro...@alu.unizg.hr>
To: dhcp-users@lists.isc.org
Subject: Re: ISC DHCPv6-BIND9 DDNS update problem
Message-ID: <2f4b6b7f-d545-56b9-fbb7-2e61cf7d3...@alu.unizg.hr>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi all,
It seems that I have been lucky this morning.
According to this article:
https://www.mail-archive.com/kea-users@lists.isc.org/msg00467.html
From this I got the notion that "The parameter is incorrect" message
could come from incorrect
settings of DHCPv6 daemon.
The problem was that default-lease-time was set to a value shorter than
the rest of the timeouts, which was obviously not accepted by DHCPv6
clients even when accepted by DHCPv6 server and relay.
Here is the proof that the setup works now:
Jun 21 09:08:43 domac dhcpd: Relay-forward message from
2001:b68:ff:ff:a2b:0:a8:2 port 547, link address 2001:b68:2:2a00::1,
peer address fe80::51e5:1df6:c605:a036
Jun 21 09:08:43 domac dhcpd: Reply NA: address 2001:b68:2:2a00::10c4 to
client with duid 00:01:00:01:25:c4:85:9c:1c:a0:b8:7d:11:aa iaid =
102539448 valid for 2592000 seconds
Jun 21 09:08:43 domac dhcpd: ddns.c(150): Allocating ddns_cb=0x55a466995360
Jun 21 09:08:43 domac dhcpd: DDNS: ddns_fwd_srv_connector: ddns_cb:
0x55a466995360 flags: 103 state: DDNS_STATE_CLEANUP cur_func: <null>
eresult: 0
Jun 21 09:08:43 domac dhcpd: DDNS: ddns_modify_fwd
Jun 21 09:08:43 domac dhcpd: DDNS: build_fwd_add1:
pname:[PC-PAVAO.slava.alu.hr] uname:[PC-PAVAO.slava.alu.hr]
Jun 21 09:08:43 domac dhcpd: DDNS request: id ptr 0x7f799160c338
DDNS_STATE_ADD_FW_NXDOMAIN 2001:b68:2:2a00::10c4 for
PC-PAVAO.slava.alu.hr zone: slava.alu.hr.dhcid: [00:02:01
:de:c5:41:4f:69:a0:e4:65:2a:e6:39:c5:77:2b:c6:a3:7e:2f:28:82:74:51:66:b2:f9:46:38:9e:af:bf:cc:c6
Jun 21 09:08:43 domac dhcpd: ddns.c(1722): Updating lease_ptr for
ddns_cp=0x55a466995360 (addr=2001:b68:2:2a00::10c4)
Jun 21 09:08:43 domac dhcpd: Sending Relay-reply to
2001:b68:ff:ff:a2b:0:a8:2 port 547
Jun 21 09:08:43 domac named[357]: zone slava.alu.hr/IN/internal: sending
notifies (serial 2022061542)
Jun 21 09:08:43 domac dhcpd: DDNS reply: id ptr 0x7f799160c338, result:
success
Jun 21 09:08:43 domac dhcpd: DDNS: ddns_fwd_srv_add1: ddns_cb:
0x55a466995360 flags: 103 state: DDNS_STATE_ADD_FW_NXDOMAIN cur_func:
ddns_fwd_srv_add1 eresult: 0
Jun 21 09:08:43 domac dhcpd: Added new forward map from
PC-PAVAO.slava.alu.hr to 2001:b68:2:2a00::10c4
Jun 21 09:08:43 domac dhcpd: DDNS: ddns_modify_ptr
Jun 21 09:08:43 domac dhcpd: DDNS request: id ptr 0x7f799160c338
DDNS_STATE_ADD_PTR PC-PAVAO.slava.alu.hr for
4.c.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.2.2.0.0.0.8.6.b.0.1.0.0.2.i
p6.arpa. zone: 0.0.a.2.2.0.0.0.8.6.b.0.1.0.0.2.ip6.arpa.dhcid:
[00:02:01:de:c5:41:4f:69:a0:e4:65:2a:e6:39:c5:77:2b:c6:a3:7e:2f:28:82:74:51:66:b2:f9:46:38:9e:af:bf:cc:c6
Jun 21 09:08:43 domac named[357]: zone
0.0.a.2.2.0.0.0.8.6.b.0.1.0.0.2.ip6.arpa/IN/internal: sending notifies
(serial 2022060202)
Jun 21 09:08:43 domac dhcpd: DDNS reply: id ptr 0x7f799160c338, result:
success
Jun 21 09:08:43 domac dhcpd: Added reverse map from
4.c.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.2.2.0.0.0.8.6.b.0.1.0.0.2.ip6.arpa.
to PC-PAVAO.slava.alu.hr
I have solved the rogue DHCPv6 servers problem by assigning our main
DHCPv6 server the highest preference (255).
Thank you for all the help and the suggestions.
It is really an excellent piece of software but it could have saved me
weeks if it had parameter sanity checks. :-/
However, this excellent support community gave me the notion not to quit
but to persevere despite the odds.
Kind regards,
Mirsad
On 21.6.2022. 8:53, Mirsad Goran Todorovac wrote:
> Hi all,
>
> Still no solution.
>
> However, we made it to work over a MikroTik DHCPv6 relay, partially.
> But what I get at the Windows 10 PC when I do an "IPCONFIG /RENEW6" is:
>
> An error occurred while renewing interface Ethernet : The parameter is
> incorrect.
>
> The Wireshark shows that the MAC of the client is relayed to the
> DHCPv6 server at the central hub,
> lease is picked from the pool for the appropriate location
> [2001:b68:2:2a00::/64], and the DHCPv6
> relay makes an advertisement of the address to the Windows 10 client:
>
>
> However, the parameters are somehow not good and rejected. Server
> tries up to 10 times with Advertise packet, but receives no Confirm.
>
> I've seen an article on the list about Kea parms causing this. Can it
> be that I have set an impossible set of DHCPv6 parameters?
>
> default-lease-time 86400;
> preferred-lifetime 604800;
> option dhcp-renewal-time 3600;
> option dhcp-rebinding-time 7200;
> allow leasequery;
> option dhcp6.name-servers 2001:b68:2:2800::3,2001:b68:c:2::70:0;
> option dhcp6.domain-search "alu.hr";
> option dhcp6.preference 255;
> ##option dhcp6.rapid-commit;
> option dhcp6.info-refresh-time 21600;
>
> The symptom is the same over the local subnet and over the DHCPv6
> relay: the address is allocated from the pool, Advertised 10x and then
> the ISC DHCPv6 server gives up.
>
> There is no Confirm packet from either local link or relay clients,
> equally Windows and Linux hosts, default setups.
>
> Thank you for any idea.
> I seem to be stuck with this, though there are small steps in the
> right direction.
>
> Kind regards,
> Mirsad
>
> On 14.6.2022. 9:27, Mirsad Todorovac wrote:
>> On 6/10/22 19:14, Simon wrote:
>>
>>>
>>>> Unfortunately, I am not even the admin of all those net segments
>>>> and rogue devices. I might be simply out of luck with this one.
>>> Presumably you know the network admins who are responsible for those
>>> segments ? And presumably there must be a person or group which
>>> oversees the network as a whole (subnets/prefixes etc) ? Just
>>> letting everyone ?do their own thing? without central planning is a
>>> recipe for disaster.
>>>
>>> So you need to go to them and point out what the problem is, and
>>> what needs to be done to fix it. Of course, if they don?t want to
>>> then you?re down to internal politics and potentially you end up
>>> reporting back to management that you can?t implement what?s asked
>>> for because others are actively sabotaging the network (that?s how
>>> I?d describe it if supposed network admins are doing nothing to deal
>>> with rogue services like this.)
>>
>> Hi, Simon,
>>
>> There is a quote that says that it is wrong to attributed to active
>> sabotaging what can be explained with neglect and stupidity.
>>
>> I believe in the most cases these are simply the default settings for
>> the devices. Probably someone in those companies thinks that it is a
>> good idea to have a dozen of DHCPv6 servers who do not talk to each
>> other and have no ideas of other server's IPv6 range - all on the
>> same subnet.
>>
>> Regards,
>> 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
>
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20220621/64393889/attachment.htm>
------------------------------
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 28
*******************************************
