Failover Peer Issue with Polycom SoundStation IP 6000 Phone

[glenn.satchell at uniq.com.au]

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.bashlor at 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.
>> 
>> 
>>