Problem with Cisco phones

[Darren Ankney]

Marki,

Can you post your dhcp configuration?  both servers shouldn't be
answering if the SECS field is 0 (no matter what you have your split
set to).

On Fri, Mar 24, 2023 at 6:47 AM Marki <dhcp-users at lists.roth.lu> wrote:
>
> 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
>
> --
> 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