Re: Problem with Cisco phones
Marki <[email protected]> Fri, 24 Mar 2023 11:47:00 +0100
| Newsgroups | gmane.network.dhcp.isc.dhcp-server |
|---|---|
| Message-ID | <472a17bc51160e35f7a7f0af1dfbe0fd__32379.5851714507$1679654861$gmane$org@lists.roth.lu> |
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 <[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