Re: Problem with Cisco phones

If a look at the OFFER immediately following the DISCOVER highlighted in 
the previous screenshot, I see a lease time of 6250s.

Four seconds later on the next try at 02:24:20,907 it's 6246s etc.
So the server is kind of counting down like a lease already existed.

The lease is fresh around 02:08 --> 
https://pasteboard.co/Ys8RKuNafGEs.jpg

This is crazy, I will open a case with Cisco.
We also have non-Cisco phones, which work just fine. I start doubting a 
problem with dhcpd ...

On 2023-03-24 16:15, Darren Ankney wrote:
> I notice there are 1 second gaps between the discover and offer on
> both servers.  Try disabling ping-check:
> 
> ping-check false;
> 
> to speed that up and see if your clients get happier with the faster
> response though that will have nothing to do with the request/ack
> cycle.  Have a look at the packet capture or in your logs and see what
> the lease length being assigned is .. perhaps it's really short (6
> minutes)?
> 
> On Fri, Mar 24, 2023 at 9:43 AM Marki <[email protected]> wrote:
>> 
>> 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

-- 
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