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 (Marki)
2. Re: Problem with Cisco phones (Darren Ankney)
----------------------------------------------------------------------
Message: 1
Date: Fri, 24 Mar 2023 14:42:45 +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: <97f0fabc3cd9b218953ec00d2f367...@lists.roth.lu>
Content-Type: text/plain; charset=UTF-8; format=flowed
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 <dhcp-us...@lists.roth.lu> 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 <dhcp-us...@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-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
>> >>
>> >> --
>> >> 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
>>
>> --
>> 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 11:15:32 -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:
<cakabwhgsnkcrenowlowglfhh+bxjp8m3dpvubgthi_bceu7...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
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 <dhcp-us...@lists.roth.lu> 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 <dhcp-us...@lists.roth.lu> 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 <dhcp-us...@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-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
> >> >>
> >> >> --
> >> >> 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
> >>
> >> --
> >> 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
>
> --
> 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 9
******************************************
