Problem with Cisco phones

[Marki]

Apparently they are working, except for the periods when they are in 
DISCOVERing stage which does not progress into REQUEST/ACK.

The packets seem to be going back and forth alright. Didn't see any 
losses.

Concerning the SECS (seconds elapsed) field: it's starting from 0 all 
the time.
The transaction ID however remains the same.

On 2023-03-24 10:20, Darren Ankney wrote:
> Marki,
> 
> Are these phones actually functional?  Usually increased traffic like
> that indicates the client is experiencing some kind of problem.
> 
> Thanks,
> 
> -Darren
> 
> On Fri, Mar 24, 2023 at 4:24 AM Marki <dhcp-users at lists.roth.lu> 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