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: Failover Peer Issue with Polycom SoundStation IP 6000
Phone (willieb)
2. RE: GUI for ISC dhcp (willieb)
3. Re: Failover Peer Issue with Polycom SoundStation IP 6000
Phone (Sten Carlsen)
4. Re: GUI for ISC dhcp (Victoria Risk)
5. Re: GUI for ISC dhcp (Victoria Risk)
6. Re: Failover Peer Issue with Polycom SoundStation IP 6000
Phone (glenn.satch...@uniq.com.au)
----------------------------------------------------------------------
Message: 1
Date: Thu, 12 Nov 2020 09:19:04 -0600 (CST)
From: willieb <will.bash...@btctelcom.net>
To: dhcp-users@lists.isc.org
Subject: Re: Failover Peer Issue with Polycom SoundStation IP 6000
Phone
Message-ID: <1605194344765-0.p...@n4.nabble.com>
Content-Type: text/plain; charset=us-ascii
Thanks so much for the reply! I stop the service on the second server, then
the first server stated: "dhcpd: failover peer failover-dhcp: I move from
normal to communications-interrupted". I'm not sure if this is the same as
partner down state?
The lease times are both 7 days. I could easily change this but I don't
think it will make a difference.
I compared the 2 case captures. Case 1 with 2 servers in a failover
configuration when the issue is happening, and case 2 with the second
server's service stopped and the issue is not happening (phone gets IP
immediately). The only difference I can see between the 2 captures is the
"DHCP Server Identifier" in the ACK. In case 1 the "DHCP Server Identifier"
in the ACK is the IP of the second server (which I find odd since split is
set to 255). But this is also the case with captures using the other model
phones (i.e. VVX411) that are working fine. Hmmm. In case 2, of course the
"DHCP Server Identifier" is the IP of the first server, since there is only
1 server. For case 1 and case 2 I see the "DHCP Server Identifier" in the
OFFER messages is that of server 1.
I did notice that in a long capture I took where the phone has the issue but
starts working 30ish minutes later, the last ACK is different from the rest
in that it has the first server IP as the "DHCP Server Identifier". So for
grins I temporarily changed the "DHCP Server Identifier" on the second
server to the IP of the first server, and the SoundStation IP 6000 then
immediately booted normally in a few seconds even with both servers running.
It seems this particular model phone has an issue with the OFFER "DHCP
Server Identifier" being the IP of server 1 and the ACK "DHCP Server
Identifier" being the IP of server 2. At this point though I still don't
know what a resolution could be.
--
Sent from: http://isc-dhcp-users.2343191.n4.nabble.com/
------------------------------
Message: 2
Date: Thu, 12 Nov 2020 09:54:19 -0600 (CST)
From: willieb <will.bash...@btctelcom.net>
To: dhcp-users@lists.isc.org
Subject: RE: GUI for ISC dhcp
Message-ID: <1605196459458-0.p...@n4.nabble.com>
Content-Type: text/plain; charset=us-ascii
I'm not sure if Gestio supports DHCP or not. I used it a long time ago and
can't remember, sorry...
--
Sent from: http://isc-dhcp-users.2343191.n4.nabble.com/
------------------------------
Message: 3
Date: Thu, 12 Nov 2020 16:54:57 +0100
From: Sten Carlsen <st...@s-carlsen.dk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Failover Peer Issue with Polycom SoundStation IP 6000
Phone
Message-ID: <58a3bc92-6db1-485b-a21f-1d053c20e...@s-carlsen.dk>
Content-Type: text/plain; charset=us-ascii
> On 12 Nov 2020, at 16.19, willieb <will.bash...@btctelcom.net> wrote:
>
> Thanks so much for the reply! I stop the service on the second server, then
> the first server stated: "dhcpd: failover peer failover-dhcp: I move from
> normal to communications-interrupted". I'm not sure if this is the same as
> partner down state?
>
> The lease times are both 7 days. I could easily change this but I don't
> think it will make a difference.
>
> I compared the 2 case captures. Case 1 with 2 servers in a failover
> configuration when the issue is happening, and case 2 with the second
> server's service stopped and the issue is not happening (phone gets IP
> immediately). The only difference I can see between the 2 captures is the
> "DHCP Server Identifier" in the ACK. In case 1 the "DHCP Server Identifier"
> in the ACK is the IP of the second server (which I find odd since split is
> set to 255). But this is also the case with captures using the other model
> phones (i.e. VVX411) that are working fine. Hmmm. In case 2, of course the
> "DHCP Server Identifier" is the IP of the first server, since there is only
> 1 server. For case 1 and case 2 I see the "DHCP Server Identifier" in the
> OFFER messages is that of server 1.
I never used failover; but Is it reasonable that the DHCP Server Identifier is
not the actual server that sent out this message? I.e. should it be the same in
both instances?
I think Simon might be able to answer this?
>
> I did notice that in a long capture I took where the phone has the issue but
> starts working 30ish minutes later, the last ACK is different from the rest
> in that it has the first server IP as the "DHCP Server Identifier". So for
> grins I temporarily changed the "DHCP Server Identifier" on the second
> server to the IP of the first server, and the SoundStation IP 6000 then
> immediately booted normally in a few seconds even with both servers running.
>
> It seems this particular model phone has an issue with the OFFER "DHCP
> Server Identifier" being the IP of server 1 and the ACK "DHCP Server
> Identifier" being the IP of server 2. At this point though I still don't
> know what a resolution could be.
>
>
>
> --
> Sent from: http://isc-dhcp-users.2343191.n4.nabble.com/
> _______________________________________________
> 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
------------------------------
Message: 4
Date: Wed, 11 Nov 2020 18:02:20 -0800
From: Victoria Risk <vi...@isc.org>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: GUI for ISC dhcp
Message-ID: <27e2e271-05c4-454e-b5f2-8355c2174...@isc.org>
Content-Type: text/plain; charset=us-ascii
> On Nov 5, 2020, at 12:42 AM, ahiya <ah...@younity.io> wrote:
>
> hi
>
> could anyone recommend a lite weight GUI for managing ISC?
> for monitoring and configuration tasks:
> - add/remove/modify subnets/pools
> -add/remove a reservation
> - monitor HA
> - subnets stats
Did you look at Glass?
It is lightweight. It might not do everything you want, but it is open source,
and created by an operator for his own use. I doubt it is checking for
overlapping subnets.
https://github.com/Akkadius/glass-isc-dhcp
Vicky
------------------------------
Message: 5
Date: Thu, 12 Nov 2020 08:11:47 -0800
From: Victoria Risk <vi...@isc.org>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: GUI for ISC dhcp
Message-ID: <9eecc635-f630-4d84-a7fd-d2b2af03e...@isc.org>
Content-Type: text/plain; charset="utf-8"
We have a page on our web site that lists commercial products that manage BIND
and ISC DHCP. It is probably not complete. We don?t have information on how
they compare, on features, or pricing or anything like that.
https://www.isc.org/commercialproducts/
If you have something to add to this list, pls unicast back to me and I will
update it.
Vicky Risk
vi...@isc.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20201112/604ece62/attachment-0001.htm>
------------------------------
Message: 6
Date: Fri, 13 Nov 2020 09:35:52 +1100
From: glenn.satch...@uniq.com.au
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Failover Peer Issue with Polycom SoundStation IP 6000
Phone
Message-ID: <5b11d34bc47b297d212908820c19a...@uniq.com.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
In the dhcp-options man page it says dhcp-server-identifier is used as
the address for unicast replies to the server, so it is probably
important to point to the individual servers.
option dhcp-server-identifier ip-address;
This option is used in DHCPOFFER and DHCPREQUEST messages, and
may optionally be included in the DHCPACK and DHCPNAK messages. DHCP
servers include this option in the DHCPOFFER in order to allow
the client to distinguish between lease offers. DHCP clients
use the contents of the ?server identifier? field as the destination
address for any DHCP messages unicast to the DHCP server. DHCP
clients also indicate which of several lease offers is being
accepted by including this option in a DHCPREQUEST message.
The only use case for setting this is where you have multiple IP
addresses on the DHCP server and you want replies to come back to a
specific one, eg a private management network and the client facing
interface. This is not a failover specific setting, and in my experience
the defaults will usually have the right behaviour.
Now, down to the problem, it is obviously a bug in the firmware of these
phones. Have you checked with the vendor to see if there is an update
available before hacking around with dhcp configs? There are rather alot
of support articles onthe Polycom support website, and something there
might be of use if you haven't looked there already.
The potential issue I see is that if you set the server-identifier to
the first dhcp server, and then that server goes down, unicast replies
to the other server may not work as intended. This is something to test
out to be sure there is no adverse impact.
Perhaps setting a class that matches these particular phones and setting
the server-identifier only for the phones in question? Something like
this where you match on the vendor part of the mac address:
class "soundstation6000" {
match if substring(hardware, 1, 4 = 1:aa:bb:cc); # the leading 1 is
type ethernet, aa:bb:cc are the first three octets of the mac address
server-identifier aa.aa.14.34; # or whatever the other server's IP
address is
}
regards,
Glenn
On 2020-11-13 02:54, Sten Carlsen wrote:
>> On 12 Nov 2020, at 16.19, willieb <will.bash...@btctelcom.net> wrote:
>>
>> Thanks so much for the reply! I stop the service on the second server,
>> then
>> the first server stated: "dhcpd: failover peer failover-dhcp: I move
>> from
>> normal to communications-interrupted". I'm not sure if this is the
>> same as
>> partner down state?
>>
>> The lease times are both 7 days. I could easily change this but I
>> don't
>> think it will make a difference.
>>
>> I compared the 2 case captures. Case 1 with 2 servers in a failover
>> configuration when the issue is happening, and case 2 with the second
>> server's service stopped and the issue is not happening (phone gets IP
>> immediately). The only difference I can see between the 2 captures is
>> the
>> "DHCP Server Identifier" in the ACK. In case 1 the "DHCP Server
>> Identifier"
>> in the ACK is the IP of the second server (which I find odd since
>> split is
>> set to 255). But this is also the case with captures using the other
>> model
>> phones (i.e. VVX411) that are working fine. Hmmm. In case 2, of course
>> the
>> "DHCP Server Identifier" is the IP of the first server, since there is
>> only
>> 1 server. For case 1 and case 2 I see the "DHCP Server Identifier" in
>> the option dhcp-server-identifier ip-address;
This option is used in DHCPOFFER and DHCPREQUEST messages, and
may optionally be included in the DHCPACK and DHCPNAK messages. DHCP
servers include this option in the DHCPOFFER in order to allow
the client to distinguish between lease offers. DHCP clients
use the contents of the ?server identifier? field as the destination
address for any DHCP messages unicast to the DHCP server. DHCP
clients also indicate which of several lease offers is being
accepted by including this option in a DHCPREQUEST message.
>> OFFER messages is that of server 1.
>
> I never used failover; but Is it reasonable that the DHCP Server
> Identifier is not the actual server that sent out this message? I.e.
> should it be the same in both instances?
> I think Simon might be able to answer this?
>
>>
>> I did notice that in a long capture I took where the phone has the
>> issue but
>> starts working 30ish minutes later, the last ACK is different from the
>> rest
>> in that it has the first server IP as the "DHCP Server Identifier". So
>> for
>> grins I temporarily changed the "DHCP Server Identifier" on the second
>> server to the IP of the first server, and the SoundStation IP 6000
>> then
>> immediately booted normally in a few seconds even with both servers
>> running.
>>
>> It seems this particular model phone has an issue with the OFFER "DHCP
>> Server Identifier" being the IP of server 1 and the ACK "DHCP Server
>> Identifier" being the IP of server 2. At this point though I still
>> don't
>> know what a resolution could be.
>>
>>
>>
------------------------------
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 145, Issue 11
*******************************************
