Re: Problem with Cisco phones

Hmm.. Here's another view on the capture at a very interesting moment: 
https://pasteboard.co/wizbap9g42pt.jpg

I have added columns for DHCP request type, "seconds elapsed" and 
"transaction id" to it.

You're correct, the secondary doesn't answer to the first DISCOVER 
packet with SECS=0.

But there's too much noise there IMHO.
Then we see a gap between 02:30 and 03:19.
At which time it goes on with requests until 03:44, then there is a 
pause until 04:31, and the same thing happens....

On 2023-03-24 12:48, Darren Ankney wrote:
> That picture of the packet capture seems to show the SECS field in the
> ACK packet.  have a look in the REQUEST packet at the SECS field.
> That is the one that it is relevant in (and DISCOVER as well since
> they are both offering addresses too at times).
> 
> On Fri, Mar 24, 2023 at 7:26 AM Marki <[email protected]> wrote:
>> 
>> 
>> The config is pretty large.
>> 
>> What it boils down to concerning the phones is the following:
>> 
>> === PRIMARY ===
>> 
>> option domain-name "example.com";
>> option domain-name-servers 172.31.2.24, 172.31.2.25;
>> option ntp-servers 172.31.2.24, 172.31.2.25;
>> 
>> option cucm-tftp-server code 150 = array of ip-address;
>> 
>> default-lease-time 7200;
>> max-lease-time 86400;
>> 
>> ddns-update-style none;
>> ddns-updates off;
>> 
>> authoritative;
>> 
>> log-facility local7;
>> 
>> failover peer "failover-partner" {
>>    primary;
>>    address dhcp-primary.example.com;
>>    peer address dhcp-secondary.example.com;
>>    max-response-delay 60;
>>    max-unacked-updates 10;
>>    mclt 3600;
>>    split 255;
>>    load balance max seconds 3;
>> }
>> omapi-port 7911;
>> omapi-key omapi_key;
>> key omapi_key {
>>    algorithm hmac-md5;
>>    secret ==;
>> }
>> 
>> class "ipt" {
>>    log(info, "### matched CLASS ipt");
>>    match hardware;
>> }
>> 
>> subnet 172.17.8.0 netmask 255.255.248.0 {
>>    option routers 172.17.8.1;
>>          option cucm-tftp-server 1.2.3.4;
>>    pool {
>>      range 172.17.8.11 172.17.8.199;
>>      range 172.17.9.11 172.17.9.199;
>>      range 172.17.10.11 172.17.10.199;
>>      failover peer "failover-partner";
>>      allow members of "ipt";
>>    }
>> }
>> 
>> === SECONDARY ===
>> 
>> option domain-name "example.com";
>> option domain-name-servers 172.31.2.24, 172.31.2.25;
>> option ntp-servers 172.31.2.24, 172.31.2.25;
>> 
>> option cucm-tftp-server code 150 = array of ip-address;
>> 
>> default-lease-time 7200;
>> max-lease-time 86400;
>> 
>> ddns-update-style none;
>> ddns-updates off;
>> 
>> authoritative;
>> 
>> log-facility local7;
>> 
>> failover peer "failover-partner" {
>>    secondary;
>>    address dhcp-secondary.example.com;
>>    peer address dhcp-primary.example.com;
>>    max-response-delay 60;
>>    max-unacked-updates 10;
>>    load balance max seconds 3;
>> }
>> omapi-port 7911;
>> omapi-key omapi_key;
>> key omapi_key {
>>    algorithm hmac-md5;
>>    secret ==;
>> }
>> 
>> class "ipt" {
>>    match hardware;
>> }
>> 
>> subnet 172.17.8.0 netmask 255.255.248.0 {
>>    option routers 172.17.8.1;
>>    option cucm-tftp-server 1.2.3.4;
>>    pool {
>>      range 172.17.8.11 172.17.8.199;
>>      range 172.17.9.11 172.17.9.199;
>>      range 172.17.10.11 172.17.10.199;
>>      failover peer "failover-partner";
>>      allow members of "ipt";
>>    }
>> }
>> 
>> ====
>> 
>>  From a packet capture I can confirm that both ACK the REQUEST with
>> SECS=0: https://pasteboard.co/oGrqwdpkEWj9.jpg
>> 
>> I'm not sure though what the relay does with this. I have no capture 
>> of
>> the phone VLAN at that point.
>> 
>> Failover config was done according to https://kb.isc.org/docs/aa-00502
>> 
>> BTW this is dhcp-server-4.3.6.P1-150000.6.17.1.x86_64 (Suse Linux
>> Enterprise 15.3)
>> 
>> Thanks,
>> marki
>> 
>> On 2023-03-24 11:50, Darren Ankney wrote:
>> > 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 <[email protected]> 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 <[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
>> 
>> --
>> 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