Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: Problem with Cisco phones (Darren Ankney)
2. Re: Problem with Cisco phones (Darren Ankney)
3. Re: Problem with Cisco phones (Marki)
----------------------------------------------------------------------
Message: 1
Date: Fri, 24 Mar 2023 05:20:55 -0400
From: Darren Ankney <darren.ank...@gmail.com>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Problem with Cisco phones
Message-ID:
<CAKabWHhXEDqg9N1oAaQ90HSzO+=kwj+d5txqzzgjn3qc+ra...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
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-us...@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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
Message: 2
Date: Fri, 24 Mar 2023 05:24:26 -0400
From: Darren Ankney <darren.ank...@gmail.com>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Problem with Cisco phones
Message-ID:
<CAKabWHim91wo0MOwQtn=hfCcnyPKm=2+=sezu2sxhs2otbn...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
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-us...@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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
Message: 3
Date: Fri, 24 Mar 2023 11:47:00 +0100
From: Marki <dhcp-us...@lists.roth.lu>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Problem with Cisco phones
Message-ID: <472a17bc51160e35f7a7f0af1dfbe...@lists.roth.lu>
Content-Type: text/plain; charset=UTF-8; format=flowed
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-us...@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@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
Subject: Digest Footer
_______________________________________________
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 172, Issue 6
******************************************
