Problem with Cisco phones
Darren Ankney
darren.ankney at gmail.com
Fri Mar 24 11:48:49 UTC 2023
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