Problem with Cisco phones

[Darren Ankney]

Hi Marki,

I've never tried a split other than 128.  From these logs, it looks
like both servers will still answer perhaps if the SECS field in the
DISCOVER packet is incremented beyond the 'load balance max seconds'
setting.  This could indicate a problem as well.  Both of these seem
to indicate that the clients are either not receiving packets at all
or are intermittently receiving packets from the DHCP server.  Perhaps
there is some firewall or network issue?

Thank you,

-Darren

On Fri, Mar 24, 2023 at 4:52 AM 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