Re: Problem with Cisco phones

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