Problem with Cisco phones

[Peter Yardley]

Hi,

An ISC DHCP server always participates. The split you have used just means that one server has 1/256 of the leases.
The standard is an active active system if you try to go away from that you can have issues. My boss decided that he would
do a split like this with a central backup server and a number of active servers. Worked fine till there were problems then
the “central” server had discio issues and everything went tits up.

> On 24 Mar 2023, at 7:51 pm, Marki <dhcp-users at lists.roth.lu> wrote:
> 
> Oh and here is another weird transaction, not even a Cisco phone.
> 
> d01 is supposed to be the primary, and d02 the secondary.
> split is 255, i.e. secondary should not do anything.
> 
> DHCP server 1 & 2 messages sorted by time
> 
> 2023-03-24T03:56:46.758683+01:00 d01 dhcpd: DHCPDISCOVER from xx:yy:zz:f4:b6:86 (x) via 172.17.64.1
> 2023-03-24T03:56:46.758753+01:00 d02 dhcpd: DHCPDISCOVER from xx:yy:zz:f4:b6:86 via 172.17.64.1: load balance to peer failover-partner
> 2023-03-24T03:56:47.758851+01:00 d01 dhcpd: DHCPOFFER on 172.17.64.103 to xx:yy:zz:f4:b6:86 (x) via 172.17.64.1
> 2023-03-24T03:56:52.791256+01:00 d01 dhcpd: DHCPDISCOVER from xx:yy:zz:f4:b6:86 (x) via 172.17.64.1
> 2023-03-24T03:56:52.791344+01:00 d02 dhcpd: DHCPDISCOVER from xx:yy:zz:f4:b6:86 via 172.17.64.1
> 2023-03-24T03:56:53.791508+01:00 d02 dhcpd: DHCPOFFER on 172.17.64.103 to xx:yy:zz:f4:b6:86 (x) via 172.17.64.1
> 2023-03-24T03:56:53.791879+01:00 d01 dhcpd: DHCPOFFER on 172.17.64.103 to xx:yy:zz:f4:b6:86 (x) via 172.17.64.1
> 2023-03-24T03:56:53.831406+01:00 d01 dhcpd: DHCPREQUEST for 172.17.64.103 (172.31.2.25) from xx:yy:zz:f4:b6:86 (x) via 172.17.64.1
> 2023-03-24T03:56:53.831423+01:00 d01 dhcpd: DHCPACK on 172.17.64.103 to xx:yy:zz:f4:b6:86 (x) via 172.17.64.1
> 2023-03-24T03:56:53.869917+01:00 d02 dhcpd: DHCPREQUEST for 172.17.64.103 (172.31.2.25) from xx:yy:zz:f4:b6:86 (x) via 172.17.64.1
> 2023-03-24T03:56:53.869938+01:00 d02 dhcpd: DHCPACK on 172.17.64.103 to xx:yy:zz:f4:b6:86 (x) via 172.17.64.1
> 2023-03-24T04:49:42.214570+01:00 d02 dhcpd: DHCPREQUEST for 172.17.64.103 from xx:yy:zz:f4:b6:86 (x) via vlan50
> 2023-03-24T04:49:42.214590+01:00 d02 dhcpd: DHCPACK on 172.17.64.103 to xx:yy:zz:f4:b6:86 (x) via vlan50
> 2023-03-24T05:49:44.534495+01:00 d02 dhcpd: DHCPREQUEST for 172.17.64.103 from xx:yy:zz:f4:b6:86 (x) via vlan50
> 2023-03-24T05:49:44.534516+01:00 d02 dhcpd: DHCPACK on 172.17.64.103 to xx:yy:zz:f4:b6:86 (x) via vlan50
> 2023-03-24T06:49:46.849370+01:00 d02 dhcpd: DHCPREQUEST for 172.17.64.103 from xx:yy:zz:f4:b6:86 (x) via vlan50
> 2023-03-24T06:49:46.849390+01:00 d02 dhcpd: DHCPACK on 172.17.64.103 to xx:yy:zz:f4:b6:86 (x) via vlan50
> 2023-03-24T07:49:49.149788+01:00 d02 dhcpd: DHCPREQUEST for 172.17.64.103 from xx:yy:zz:f4:b6:86 (x) via vlan50
> 2023-03-24T07:49:49.149808+01:00 d02 dhcpd: DHCPACK on 172.17.64.103 to xx:yy:zz:f4:b6:86 (x) via vlan50
> 2023-03-24T08:49:51.466691+01:00 d02 dhcpd: DHCPREQUEST for 172.17.64.103 from xx:yy:zz:f4:b6:86 (x) via vlan50
> 2023-03-24T08:49:51.466711+01:00 d02 dhcpd: DHCPACK on 172.17.64.103 to xx:yy:zz:f4:b6:86 (x) via vlan50
> 
> 
> On 2023-03-24 09:23, Marki wrote:
>> Hello,
>> I know this is probably not an ISC DHCPD issue per se, but anyway,
>> maybe it rings a bell with someone.
>> I have a very frustrating issue here with Cisco IP Phones 8800 series.
>> Some of them are doing REQUEST/ACK multiple times per minute. They are
>> doing it as a broadcast, not unicast, hence the relay IP is shown.
>> 2023-03-24T08:53:35.946166+01:00 d01 dhcpd: DHCPREQUEST for
>> 172.17.8.11 from xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1
>> 2023-03-24T08:53:35.946183+01:00 d01 dhcpd: DHCPACK on 172.17.8.11 to
>> xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1
>> 2023-03-24T08:53:43.938781+01:00 d01 dhcpd: DHCPREQUEST for
>> 172.17.8.11 from xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1
>> 2023-03-24T08:53:43.938798+01:00 d01 dhcpd: DHCPACK on 172.17.8.11 to
>> xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1
>> 2023-03-24T08:54:03.943809+01:00 d01 dhcpd: DHCPREQUEST for
>> 172.17.8.11 from xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1
>> 2023-03-24T08:54:03.943828+01:00 d01 dhcpd: DHCPACK on 172.17.8.11 to
>> xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1
>> Some are even switching between broadcast and unicast:
>> 2023-03-24T08:13:21.774638+01:00 d01 dhcpd: DHCPREQUEST for
>> 172.17.8.31 from xx:yy:zz:d1:9d:11 (SEP) via 172.17.8.1
>> 2023-03-24T08:13:21.774658+01:00 d01 dhcpd: DHCPACK on 172.17.8.31 to
>> xx:yy:zz:d1:9d:11 (SEP) via 172.17.8.1
>> -- nothing in between --
>> 2023-03-24T09:12:03.817128+01:00 d01 dhcpd: DHCPREQUEST for
>> 172.17.8.31 from xx:yy:zz:d1:9d:11 (SEP) via vlan50
>> 2023-03-24T09:12:03.817151+01:00 d01 dhcpd: DHCPACK on 172.17.8.31 to
>> xx:yy:zz:d1:9d:11 (SEP) via vlan50
>> Sometimes they are totally stuck for like half an hour. First they
>> DISCOVER all the time, but don't issue a REQUEST after the OFFER until
>> some time has passed.
>> Power cycling does not help. I have yet to lay hand on a specimen in
>> order to totally reset it.
>> This could have started with failover not having been configured
>> correctly between the two dhcp servers, i.e. both servers handing out
>> addresses for dynamic pools.
>> Anyone got an idea?
>> Thanks
>> Marki
> 
> -- 
> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users

Peter Yardley
peter.martin.yardley at gmail.com