Problem with Cisco phones

Fri Mar 24 16:08:27 UTC 2023

Hello all,

Can you tell me which switch is in use behind it and whether a separate VLAN is configured there for VoIP?
What does the configuration of the switch look like here?

It seems to me that there might be a problem with the configuration of the switch. Can you try plugging the phone directly into the VLAN of the DHCP server to see how it behaves there?

Best regards from Berlin

Z. Matthias

> On Freitag, März 24, 2023 at 4:57 PM, Marki <dhcp-users at lists.roth.lu (mailto:dhcp-users at lists.roth.lu)> wrote:
> If a look at the OFFER immediately following the DISCOVER highlighted in
> the previous screenshot, I see a lease time of 6250s.
>
> Four seconds later on the next try at 02:24:20,907 it's 6246s etc.
> So the server is kind of counting down like a lease already existed.
>
> The lease is fresh around 02:08 -->
> https://pasteboard.co/Ys8RKuNafGEs.jpg
>
> This is crazy, I will open a case with Cisco.
> We also have non-Cisco phones, which work just fine. I start doubting a
> problem with dhcpd ...
>
> On 2023-03-24 16:15, Darren Ankney wrote:
> > 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-users at 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-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
> > >
> > > --
> > > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20230324/2045e184/attachment-0001.htm>