Problem with Cisco phones
Marki
dhcp-users at lists.roth.lu
Fri Mar 24 11:26:05 UTC 2023
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-users at 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-users at 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 at 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 at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
More information about the dhcp-users
mailing list