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 <
[hidden email]> 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.
>>
>>
>>
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Locked
