Problem with Cisco phones
Marki
dhcp-users at lists.roth.lu
Fri Mar 24 13:42:45 UTC 2023
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-users at 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-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
>>
>> --
>> 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