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 (Peter Yardley)
3. Re: Problem with Cisco phones (Marki)
----------------------------------------------------------------------
Message: 1
Date: Fri, 24 Mar 2023 06:50:44 -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:
<CAKabWHhU9R3Q+a-J_dF+HTW2THND8Mi-R3vNBnnqLw+qk3a8=a...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
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
------------------------------
Message: 2
Date: Fri, 24 Mar 2023 22:02:00 +1100
From: Peter Yardley <peter.martin.yard...@gmail.com>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Problem with Cisco phones
Message-ID: <e30dfaf4-e018-47e4-8061-e08385f79...@gmail.com>
Content-Type: text/plain; charset=utf-8
Hi,
An ISC DHCP server always participates. The split you have used just means that
one server has 1/256 of the leases.
The standard is an active active system if you try to go away from that you can
have issues. My boss decided that he would
do a split like this with a central backup server and a number of active
servers. Worked fine till there were problems then
the ?central? server had discio issues and everything went tits up.
> On 24 Mar 2023, at 7:51 pm, 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
Peter Yardley
peter.martin.yard...@gmail.com
------------------------------
Message: 3
Date: Fri, 24 Mar 2023 12:26:05 +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: <4420af4d595208d142f70a654500c...@lists.roth.lu>
Content-Type: text/plain; charset=UTF-8; format=flowed
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
------------------------------
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 7
******************************************
