
<html xmlns="http://www.w3.org/1999/xhtml"><head> <title></title> <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no"> </head> <body><img id="D0EE41F2AC6B1A5EB94E53FB8C60713D" alt="" width="0px" src="https://receipts.canarymail.io/track/FCA67E6230579D93B761CDD4D8860DD3_D0EE41F2AC6B1A5EB94E53FB8C60713D.png" height="0px"><div id="CanaryBody"> <div> <div>Hello all,</div><div><br></div><div>Can you tell me which switch is in use behind it and whether a separate VLAN is configured there for VoIP?</div><div>What does the configuration of the switch look like here?</div><div><br></div><div>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?</div> </div> <div><br></div> </div> <div id="CanarySig"> <div> <div style="font-family:Helvetica;">Best regards from Berlin<a href="https://canarymail.io"></a></div><div style="font-family:Helvetica;"><br></div><div style="font-family:Helvetica;">Z. Matthias</div> <div><br></div> </div> </div> <div id="CanaryDropbox"> </div> <blockquote id="CanaryBlockquote"> <div> <div>On Freitag, März 24, 2023 at 4:57 PM, Marki <<a href="mailto:dhcp-users@lists.roth.lu">dhcp-users@lists.roth.lu</a>> wrote:<br></div> <div>If a look at the OFFER immediately following the DISCOVER highlighted in <br>the previous screenshot, I see a lease time of 6250s.<br><br>Four seconds later on the next try at 02:24:20,907 it's 6246s etc.<br>So the server is kind of counting down like a lease already existed.<br><br>The lease is fresh around 02:08 --> <br>https://pasteboard.co/Ys8RKuNafGEs.jpg<br><br>This is crazy, I will open a case with Cisco.<br>We also have non-Cisco phones, which work just fine. I start doubting a <br>problem with dhcpd ...<br><br>On 2023-03-24 16:15, Darren Ankney wrote:<br><blockquote type="cite">I notice there are 1 second gaps between the discover and offer on<br>both servers. Try disabling ping-check:<br><br>ping-check false;<br><br>to speed that up and see if your clients get happier with the faster<br>response though that will have nothing to do with the request/ack<br>cycle. Have a look at the packet capture or in your logs and see what<br>the lease length being assigned is .. perhaps it's really short (6<br>minutes)?<br><br>On Fri, Mar 24, 2023 at 9:43 AM Marki <dhcp-users@lists.roth.lu> wrote:<br><blockquote type="cite"><br>Hmm.. Here's another view on the capture at a very interesting moment:<br>https://pasteboard.co/wizbap9g42pt.jpg<br><br>I have added columns for DHCP request type, "seconds elapsed" and<br>"transaction id" to it.<br><br>You're correct, the secondary doesn't answer to the first DISCOVER<br>packet with SECS=0.<br><br>But there's too much noise there IMHO.<br>Then we see a gap between 02:30 and 03:19.<br>At which time it goes on with requests until 03:44, then there is a<br>pause until 04:31, and the same thing happens....<br><br>On 2023-03-24 12:48, Darren Ankney wrote:<br><blockquote type="cite">That picture of the packet capture seems to show the SECS field in the<br>ACK packet. have a look in the REQUEST packet at the SECS field.<br>That is the one that it is relevant in (and DISCOVER as well since<br>they are both offering addresses too at times).<br><br>On Fri, Mar 24, 2023 at 7:26 AM Marki <dhcp-users@lists.roth.lu> wrote:<br><blockquote type="cite"><br><br>The config is pretty large.<br><br>What it boils down to concerning the phones is the following:<br><br>=== PRIMARY ===<br><br>option domain-name "example.com";<br>option domain-name-servers 172.31.2.24, 172.31.2.25;<br>option ntp-servers 172.31.2.24, 172.31.2.25;<br><br>option cucm-tftp-server code 150 = array of ip-address;<br><br>default-lease-time 7200;<br>max-lease-time 86400;<br><br>ddns-update-style none;<br>ddns-updates off;<br><br>authoritative;<br><br>log-facility local7;<br><br>failover peer "failover-partner" {<br>primary;<br>address dhcp-primary.example.com;<br>peer address dhcp-secondary.example.com;<br>max-response-delay 60;<br>max-unacked-updates 10;<br>mclt 3600;<br>split 255;<br>load balance max seconds 3;<br>}<br>omapi-port 7911;<br>omapi-key omapi_key;<br>key omapi_key {<br>algorithm hmac-md5;<br>secret ==;<br>}<br><br>class "ipt" {<br>log(info, "### matched CLASS ipt");<br>match hardware;<br>}<br><br>subnet 172.17.8.0 netmask 255.255.248.0 {<br>option routers 172.17.8.1;<br>option cucm-tftp-server 1.2.3.4;<br>pool {<br>range 172.17.8.11 172.17.8.199;<br>range 172.17.9.11 172.17.9.199;<br>range 172.17.10.11 172.17.10.199;<br>failover peer "failover-partner";<br>allow members of "ipt";<br>}<br>}<br><br>=== SECONDARY ===<br><br>option domain-name "example.com";<br>option domain-name-servers 172.31.2.24, 172.31.2.25;<br>option ntp-servers 172.31.2.24, 172.31.2.25;<br><br>option cucm-tftp-server code 150 = array of ip-address;<br><br>default-lease-time 7200;<br>max-lease-time 86400;<br><br>ddns-update-style none;<br>ddns-updates off;<br><br>authoritative;<br><br>log-facility local7;<br><br>failover peer "failover-partner" {<br>secondary;<br>address dhcp-secondary.example.com;<br>peer address dhcp-primary.example.com;<br>max-response-delay 60;<br>max-unacked-updates 10;<br>load balance max seconds 3;<br>}<br>omapi-port 7911;<br>omapi-key omapi_key;<br>key omapi_key {<br>algorithm hmac-md5;<br>secret ==;<br>}<br><br>class "ipt" {<br>match hardware;<br>}<br><br>subnet 172.17.8.0 netmask 255.255.248.0 {<br>option routers 172.17.8.1;<br>option cucm-tftp-server 1.2.3.4;<br>pool {<br>range 172.17.8.11 172.17.8.199;<br>range 172.17.9.11 172.17.9.199;<br>range 172.17.10.11 172.17.10.199;<br>failover peer "failover-partner";<br>allow members of "ipt";<br>}<br>}<br><br>====<br><br>From a packet capture I can confirm that both ACK the REQUEST with<br>SECS=0: https://pasteboard.co/oGrqwdpkEWj9.jpg<br><br>I'm not sure though what the relay does with this. I have no capture<br>of<br>the phone VLAN at that point.<br><br>Failover config was done according to https://kb.isc.org/docs/aa-00502<br><br>BTW this is dhcp-server-4.3.6.P1-150000.6.17.1.x86_64 (Suse Linux<br>Enterprise 15.3)<br><br>Thanks,<br>marki<br><br>On 2023-03-24 11:50, Darren Ankney wrote:<br><blockquote type="cite">Marki,<br><br>Can you post your dhcp configuration? both servers shouldn't be<br>answering if the SECS field is 0 (no matter what you have your split<br>set to).<br><br>On Fri, Mar 24, 2023 at 6:47 AM Marki <dhcp-users@lists.roth.lu> wrote:<br><blockquote type="cite"><br>Apparently they are working, except for the periods when they are in<br>DISCOVERing stage which does not progress into REQUEST/ACK.<br><br>The packets seem to be going back and forth alright. Didn't see any<br>losses.<br><br>Concerning the SECS (seconds elapsed) field: it's starting from 0 all<br>the time.<br>The transaction ID however remains the same.<br><br>On 2023-03-24 10:20, Darren Ankney wrote:<br><blockquote type="cite">Marki,<br><br>Are these phones actually functional? Usually increased traffic like<br>that indicates the client is experiencing some kind of problem.<br><br>Thanks,<br><br>-Darren<br><br>On Fri, Mar 24, 2023 at 4:24 AM Marki <dhcp-users@lists.roth.lu> wrote:<br><blockquote type="cite"><br>Hello,<br><br>I know this is probably not an ISC DHCPD issue per se, but anyway,<br>maybe<br>it rings a bell with someone.<br><br>I have a very frustrating issue here with Cisco IP Phones 8800 series.<br><br>Some of them are doing REQUEST/ACK multiple times per minute. They are<br>doing it as a broadcast, not unicast, hence the relay IP is shown.<br><br>2023-03-24T08:53:35.946166+01:00 d01 dhcpd: DHCPREQUEST for<br>172.17.8.11<br>from xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1<br>2023-03-24T08:53:35.946183+01:00 d01 dhcpd: DHCPACK on 172.17.8.11 to<br>xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1<br><br>2023-03-24T08:53:43.938781+01:00 d01 dhcpd: DHCPREQUEST for<br>172.17.8.11<br>from xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1<br>2023-03-24T08:53:43.938798+01:00 d01 dhcpd: DHCPACK on 172.17.8.11 to<br>xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1<br><br>2023-03-24T08:54:03.943809+01:00 d01 dhcpd: DHCPREQUEST for<br>172.17.8.11<br>from xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1<br>2023-03-24T08:54:03.943828+01:00 d01 dhcpd: DHCPACK on 172.17.8.11 to<br>xx:yy:zz:d9:11:57 (SEP) via 172.17.8.1<br><br>Some are even switching between broadcast and unicast:<br><br>2023-03-24T08:13:21.774638+01:00 d01 dhcpd: DHCPREQUEST for<br>172.17.8.31<br>from xx:yy:zz:d1:9d:11 (SEP) via 172.17.8.1<br>2023-03-24T08:13:21.774658+01:00 d01 dhcpd: DHCPACK on 172.17.8.31 to<br>xx:yy:zz:d1:9d:11 (SEP) via 172.17.8.1<br>-- nothing in between --<br>2023-03-24T09:12:03.817128+01:00 d01 dhcpd: DHCPREQUEST for<br>172.17.8.31<br>from xx:yy:zz:d1:9d:11 (SEP) via vlan50<br>2023-03-24T09:12:03.817151+01:00 d01 dhcpd: DHCPACK on 172.17.8.31 to<br>xx:yy:zz:d1:9d:11 (SEP) via vlan50<br><br>Sometimes they are totally stuck for like half an hour. First they<br>DISCOVER all the time, but don't issue a REQUEST after the OFFER until<br>some time has passed.<br><br>Power cycling does not help. I have yet to lay hand on a specimen in<br>order to totally reset it.<br><br>This could have started with failover not having been configured<br>correctly between the two dhcp servers, i.e. both servers handing out<br>addresses for dynamic pools.<br><br>Anyone got an idea?<br><br>Thanks<br>Marki<br>--<br>ISC funds the development of this software with paid support<br>subscriptions. Contact us at https://www.isc.org/contact/ for more<br>information.<br><br>dhcp-users mailing list<br>dhcp-users@lists.isc.org<br>https://lists.isc.org/mailman/listinfo/dhcp-users<br></blockquote></blockquote><br>--<br>ISC funds the development of this software with paid support<br>subscriptions. Contact us at https://www.isc.org/contact/ for more<br>information.<br><br>dhcp-users mailing list<br>dhcp-users@lists.isc.org<br>https://lists.isc.org/mailman/listinfo/dhcp-users<br></blockquote></blockquote><br>--<br>ISC funds the development of this software with paid support<br>subscriptions. Contact us at https://www.isc.org/contact/ for more<br>information.<br><br>dhcp-users mailing list<br>dhcp-users@lists.isc.org<br>https://lists.isc.org/mailman/listinfo/dhcp-users<br></blockquote></blockquote><br>--<br>ISC funds the development of this software with paid support <br>subscriptions. Contact us at https://www.isc.org/contact/ for more <br>information.<br><br>dhcp-users mailing list<br>dhcp-users@lists.isc.org<br>https://lists.isc.org/mailman/listinfo/dhcp-users<br></blockquote></blockquote><br>-- <br>ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.<br><br>dhcp-users mailing list<br>dhcp-users@lists.isc.org<br>https://lists.isc.org/mailman/listinfo/dhcp-users<br></div> </div> </blockquote> </body></html>