Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Duplicate DHCP entries

    Scheduled Pinned Locked Moved DHCP and DNS
    12 Posts 4 Posters 9.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • johnpozJ Offline
      johnpoz LAYER 8 Global Moderator
      last edited by

      "The system is using a dhcp failover peer, I have a feeling that that's got something to do with it."

      Yeah think?? ;) heheeh

      An intelligent man is sometimes forced to be drunk to spend time with his fools
      If you get confused: Listen to the Music Play
      Please don't Chat/PM me for help, unless mod related
      SG-4860 25.07.1 | Lab VMs 2.8.1, 25.07.1

      1 Reply Last reply Reply Quote 0
      • S Offline
        sandern
        last edited by

        I would think the failover peer shouldn't give any adresses out unless the primary should be down. Am I wrong?

        1 Reply Last reply Reply Quote 0
        • W Offline
          wallabybob
          last edited by

          @sandern:

          I would think the failover peer shouldn't give any adresses out unless the primary should be down. Am I wrong?

          I have no idea how DHCP failover peer is supposed to work, but clearly (perhaps without realising it) you think a failover peer will update the primary with the allocations it performed (so the primary doesn't duplicate the allocations of the failover peer).

          Perhaps the primary and the failover peer are supposed to allocate IP addresses from distinct sets.

          1 Reply Last reply Reply Quote 0
          • johnpozJ Offline
            johnpoz LAYER 8 Global Moderator
            last edited by

            Here is the thing - has CARP been setup correctly and working?  You can not use dhcp failover if you don't have CARP setup and working correctly.

            But seems when he talks about a machine vs his cluster of pfsense?  So I have no idea what his using for his dhcp failover peer?  Maybe he has another pfsense box setup but never setup CARP?

            An intelligent man is sometimes forced to be drunk to spend time with his fools
            If you get confused: Listen to the Music Play
            Please don't Chat/PM me for help, unless mod related
            SG-4860 25.07.1 | Lab VMs 2.8.1, 25.07.1

            1 Reply Last reply Reply Quote 0
            • S Offline
              sandern
              last edited by

              On the dhcp server tab you can set another dhcp failover peer.

              As in the docs:

              It also may be a good idea to enable failover DHCP. Enter 192.168.1.2 in the failover peep box on the primary and 192.168.1.1 on the backup server. Click save.

              Thats what I have, both dhcp servers have a state of "normal".

              There is a VIP ip active and there are indeed two pfsense machines.

              Carp is also active with the exemption of synchronization of the config file settings. (Existing bug #1928)

              1 Reply Last reply Reply Quote 0
              • johnpozJ Offline
                johnpoz LAYER 8 Global Moderator
                last edited by

                Have you looked here?
                http://doc.pfsense.org/index.php/DHCP_Failover_Troubleshooting

                An intelligent man is sometimes forced to be drunk to spend time with his fools
                If you get confused: Listen to the Music Play
                Please don't Chat/PM me for help, unless mod related
                SG-4860 25.07.1 | Lab VMs 2.8.1, 25.07.1

                1 Reply Last reply Reply Quote 0
                • S Offline
                  sandern
                  last edited by

                  Yes ofcourse I did, but that didn't help me, both the primary as the peer are in a normal status, so they can communicate fine with each other.

                  1 Reply Last reply Reply Quote 0
                  • johnpozJ Offline
                    johnpoz LAYER 8 Global Moderator
                    last edited by

                    Here is where I am confused

                    "They never had a static entry and there is just one LAN card where dhcp requests are going to."

                    But then you say you have CARP setup..  So this is not true - dhcp requests would be going to both servers would they not?  its not like dhcp listens on the VIP??

                    So if depending on which dhcp server the client accepted the lease from, this should be then sync'd to the other pfsense in your cluster so that it does not hand that out.

                    This how I understand the failover dhcp working.. Maybe I am mistaken, might be interesting to fire up a carp setup and play with this.

                    You should be able to look on the clients to see where they got their lease from.

                    Maybe these entries are common on the systems?  So for example client 1 gets a lease from pf1, pf2 should get that lease snyc'd over to it so that it does not hand it out right.

                    But what happens when client 1 goes to do his renewal?  So pf1 should answer it for the renewal?  or could pf2 answer?  What gets logged in the other pfsense when it sees this request?

                    Guess I will have to fire up CARP and play with this stuff - is there a good write up on dhcp failover?  I have not been able to find one?  Would be good addition to the wiki!!

                    Are you having issues with clients actually getting duplicate IPs?  Or is it just a issue with the log?  I would suggest turn off one of the dhcp servers until you spend some time understanding how it works.  maybe the log entries are normal for a dhcp failover setup??

                    An intelligent man is sometimes forced to be drunk to spend time with his fools
                    If you get confused: Listen to the Music Play
                    Please don't Chat/PM me for help, unless mod related
                    SG-4860 25.07.1 | Lab VMs 2.8.1, 25.07.1

                    1 Reply Last reply Reply Quote 0
                    • jimpJ Offline
                      jimp Rebel Alliance Developer Netgate
                      last edited by

                      In failover mode, the units share lease info and won't hand out multiples. However, if you had some leases before you setup failover they could still be hanging around and it would have shared them between the hosts then.

                      You could stop the DHCP service, rm /var/dhcpd/var/db/dhcpd.leases*, then start DHCP again and see if it ever comes back.

                      Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                      Need help fast? Netgate Global Support!

                      Do not Chat/PM for help!

                      1 Reply Last reply Reply Quote 0
                      • S Offline
                        sandern
                        last edited by

                        I've removed the leases file on both servers, we'll see if that fixes it.

                        1 Reply Last reply Reply Quote 0
                        • S Offline
                          sandern
                          last edited by

                          Sadly it didn't:

                          Primary DHCP system log:

                          Nov 29 11:32:36 	dhcpd: uid lease 172.19.8.56 for client f0:b4:79:ab:d9:0a is duplicate on 172.19.0.0/20
Nov 29 11:57:26 	dhcpd: uid lease 172.19.8.59 for client 74:2f:68:a4:cf:b0 is duplicate on 172.19.0.0/20

                          Primary DHCP log:

                          Nov 29 12:43:32 	dhcpd: DHCPACK to 172.19.8.60 (00:21:00:b1:97:70) via fxp0
Nov 29 12:43:41 	dhcpd: DHCPREQUEST for 172.19.8.127 from 14:da:e9:33:36:5b (android-314fd0df35f688c9) via fxp0
Nov 29 12:43:41 	dhcpd: DHCPACK on 172.19.8.127 to 14:da:e9:33:36:5b (android-314fd0df35f688c9) via fxp0
Nov 29 12:43:44 	dhcpd: DHCPREQUEST for 172.19.8.127 from 14:da:e9:33:36:5b (android-314fd0df35f688c9) via fxp0
Nov 29 12:43:44 	dhcpd: DHCPACK on 172.19.8.127 to 14:da:e9:33:36:5b (android-314fd0df35f688c9) via fxp0
Nov 29 12:43:51 	dhcpd: DHCPDISCOVER from 14:da:e9:33:36:5b (android-314fd0df35f688c9) via fxp0
Nov 29 12:43:51 	dhcpd: DHCPOFFER on 172.19.8.127 to 14:da:e9:33:36:5b (android-314fd0df35f688c9) via fxp0
Nov 29 12:43:51 	dhcpd: DHCPREQUEST for 172.19.8.127 (172.19.0.3) from 14:da:e9:33:36:5b (android-314fd0df35f688c9) via fxp0
Nov 29 12:43:51 	dhcpd: DHCPACK on 172.19.8.127 to 14:da:e9:33:36:5b (android-314fd0df35f688c9) via fxp0
Nov 29 12:44:39 	dhcpd: DHCPDISCOVER from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0: load balance to peer dhcp0
Nov 29 12:44:40 	dhcpd: DHCPREQUEST for 172.19.8.43 (172.19.0.3) from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0
Nov 29 12:44:40 	dhcpd: DHCPACK on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0
Nov 29 12:44:41 	dhcpd: DHCPINFORM from 172.19.8.60 via fxp0
Nov 29 12:44:41 	dhcpd: DHCPACK to 172.19.8.60 (00:21:00:b1:97:70) via fxp0
Nov 29 12:45:45 	dhcpd: DHCPINFORM from 172.19.8.60 via fxp0
Nov 29 12:45:45 	dhcpd: DHCPACK to 172.19.8.60 (00:21:00:b1:97:70) via fxp0
Nov 29 12:50:51 	dhcpd: DHCPDISCOVER from 6c:e9:07:13:d1:a0 via fxp0
Nov 29 12:50:52 	dhcpd: unexpected ICMP Echo Reply from 10.10.1.254
Nov 29 12:50:52 	dhcpd: DHCPOFFER on 172.19.8.50 to 6c:e9:07:13:d1:a0 via fxp0
Nov 29 12:50:52 	dhcpd: DHCPDISCOVER from 6c:e9:07:13:d1:a0 via fxp0
Nov 29 12:50:52 	dhcpd: DHCPOFFER on 172.19.8.50 to 6c:e9:07:13:d1:a0 via fxp0
Nov 29 12:50:52 	dhcpd: DHCPREQUEST for 172.19.8.50 (172.19.0.2) from 6c:e9:07:13:d1:a0 via fxp0
Nov 29 12:50:52 	dhcpd: DHCPACK on 172.19.8.50 to 6c:e9:07:13:d1:a0 via fxp0
Nov 29 12:51:03 	dhcpd: DHCPREQUEST for 172.19.8.56 from f0:b4:79:ab:d9:0a (iPod-van-Jente) via fxp0
Nov 29 12:51:03 	dhcpd: DHCPACK on 172.19.8.56 to f0:b4:79:ab:d9:0a (iPod-van-Jente) via fxp0
Nov 29 12:52:18 	dhcpd: DHCPDISCOVER from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0: load balance to peer dhcp0
Nov 29 12:52:19 	dhcpd: DHCPREQUEST for 172.19.8.43 (172.19.0.3) from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0
Nov 29 12:52:19 	dhcpd: DHCPACK on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0
Nov 29 12:52:48 	dhcpd: DHCPDISCOVER from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0: load balance to peer dhcp0
Nov 29 12:52:48 	dhcpd: DHCPREQUEST for 172.19.8.43 (172.19.0.3) from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0
Nov 29 12:52:48 	dhcpd: DHCPACK on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0
Nov 29 12:53:05 	dhcpd: DHCPREQUEST for 172.19.0.104 from d4:87:d8:cc:74:f3 via fxp0
Nov 29 12:53:05 	dhcpd: DHCPACK on 172.19.0.104 to d4:87:d8:cc:74:f3 via fxp0
Nov 29 12:53:48 	dhcpd: DHCPDISCOVER from 00:25:bc:95:09:72 via fxp0: load balance to peer dhcp0
Nov 29 12:53:50 	dhcpd: DHCPREQUEST for 172.19.0.119 (172.19.0.3) from 00:25:bc:95:09:72 via fxp0: lease owned by peer
Nov 29 12:58:08 	dhcpd: DHCPREQUEST for 172.19.9.34 from 58:b0:35:11:58:7f (evert) via fxp0
Nov 29 12:58:08 	dhcpd: DHCPACK on 172.19.9.34 to 58:b0:35:11:58:7f (evert) via fxp0
Nov 29 12:58:46 	dhcpd: DHCPDISCOVER from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0: load balance to peer dhcp0
Nov 29 12:58:47 	dhcpd: DHCPREQUEST for 172.19.8.43 (172.19.0.3) from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0
Nov 29 12:58:47 	dhcpd: DHCPACK on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0
Nov 29 12:59:39 	dhcpd: DHCPDISCOVER from 90:27:e4:77:8f:ad (Pauline) via fxp0
Nov 29 12:59:40 	dhcpd: unexpected ICMP Echo Reply from 10.10.1.254
Nov 29 12:59:40 	dhcpd: DHCPOFFER on 172.19.8.53 to 90:27:e4:77:8f:ad (Pauline) via fxp0
Nov 29 12:59:41 	dhcpd: DHCPREQUEST for 172.19.8.53 (172.19.0.2) from 90:27:e4:77:8f:ad (Pauline) via fxp0
Nov 29 12:59:41 	dhcpd: DHCPACK on 172.19.8.53 to 90:27:e4:77:8f:ad (Pauline) via fxp0
Nov 29 13:00:05 	dhcpd: DHCPDISCOVER from 34:4b:50:b6:4b:19 (android_bdb252201df34e7d) via fxp0
Nov 29 13:00:06 	dhcpd: unexpected ICMP Echo Reply from 10.10.1.254
Nov 29 13:00:06 	dhcpd: DHCPOFFER on 172.19.8.51 to 34:4b:50:b6:4b:19 (android_bdb252201df34e7d) via fxp0
Nov 29 13:00:06 	dhcpd: DHCPREQUEST for 172.19.8.51 (172.19.0.2) from 34:4b:50:b6:4b:19 (android_bdb252201df34e7d) via fxp0
Nov 29 13:00:06 	dhcpd: DHCPACK on 172.19.8.51 to 34:4b:50:b6:4b:19 (android_bdb252201df34e7d) via fxp0

                          Secondary DHCP system log:

                          Nov 29 12:19:49 	dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:20:01 	dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:20:14 	dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:20:29 	dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:20:36 	dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:20:37 	dhcpd: bind update on 172.19.8.56 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:20:48 	dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:21:02 	dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:21:06 	dhcpd: bind update on 172.19.8.51 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:21:11 	dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:21:20 	dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:21:29 	dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:21:34 	dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:21:42 	dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:21:43 	dhcpd: bind update on 172.19.8.51 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:21:55 	dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:22:09 	dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:22:16 	dhcpd: bind update on 172.19.8.48 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:22:16 	dhcpd: bind update on 172.19.0.122 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:22:17 	dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:22:27 	dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:22:34 	dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:22:46 	dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:23:07 	dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:23:10 	dhcpd: bind update on 172.19.8.48 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:23:14 	dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:23:26 	dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:23:57 	dhcpd: bind update on 172.19.0.110 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:24:16 	dhcpd: bind update on 172.19.8.43 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:24:41 	dhcpd: uid lease 172.19.8.42 for client 00:23:32:1d:19:66 is duplicate on 172.19.0.0/20
Nov 29 12:25:19 	dhcpd: bind update on 172.19.8.43 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:25:33 	dhcpd: bind update on 172.19.0.174 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:25:57 	dhcpd: bind update on 172.19.8.48 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:28:49 	dhcpd: bind update on 172.19.0.174 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:34:23 	dhcpd: bind update on 172.19.0.104 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:34:38 	dhcpd: bind update on 172.19.8.50 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:41:40 	dhcpd: bind update on 172.19.1.75 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:41:57 	dhcpd: bind update on 172.19.8.54 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:42:33 	dhcpd: bind update on 172.19.0.104 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:43:41 	dhcpd: bind update on 172.19.8.127 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:43:44 	dhcpd: bind update on 172.19.8.127 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:43:51 	dhcpd: bind update on 172.19.8.127 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:44:40 	dhcpd: bind update on 172.19.8.43 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:50:52 	dhcpd: bind update on 172.19.8.50 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:51:03 	dhcpd: bind update on 172.19.8.56 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:52:19 	dhcpd: bind update on 172.19.8.43 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:52:48 	dhcpd: bind update on 172.19.8.43 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:53:05 	dhcpd: bind update on 172.19.0.104 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:58:08 	dhcpd: bind update on 172.19.9.34 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:58:47 	dhcpd: bind update on 172.19.8.43 from dhcp0 rejected: incoming update is less critical than outgoing update

                          Secondary dhcp log:

                          Nov 29 12:44:40 	dhcpd: DHCPREQUEST for 172.19.8.43 (172.19.0.3) from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2
Nov 29 12:44:40 	dhcpd: DHCPACK on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2
Nov 29 12:44:40 	dhcpd: bind update on 172.19.8.43 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:44:41 	dhcpd: DHCPINFORM from 172.19.8.60 via fxp0_vlan2
Nov 29 12:44:41 	dhcpd: DHCPACK to 172.19.8.60 (00:21:00:b1:97:70) via fxp0_vlan2
Nov 29 12:45:45 	dhcpd: DHCPINFORM from 172.19.8.60 via fxp0_vlan2
Nov 29 12:45:45 	dhcpd: DHCPACK to 172.19.8.60 (00:21:00:b1:97:70) via fxp0_vlan2
Nov 29 12:50:51 	dhcpd: DHCPDISCOVER from 6c:e9:07:13:d1:a0 via fxp0_vlan2: load balance to peer dhcp0
Nov 29 12:50:52 	dhcpd: DHCPDISCOVER from 6c:e9:07:13:d1:a0 via fxp0_vlan2: load balance to peer dhcp0
Nov 29 12:50:52 	dhcpd: DHCPREQUEST for 172.19.8.50 (172.19.0.2) from 6c:e9:07:13:d1:a0 via fxp0_vlan2
Nov 29 12:50:52 	dhcpd: DHCPACK on 172.19.8.50 to 6c:e9:07:13:d1:a0 via fxp0_vlan2
Nov 29 12:50:52 	dhcpd: bind update on 172.19.8.50 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:51:03 	dhcpd: DHCPREQUEST for 172.19.8.56 from f0:b4:79:ab:d9:0a (iPod-van-Jente) via fxp0_vlan2
Nov 29 12:51:03 	dhcpd: DHCPACK on 172.19.8.56 to f0:b4:79:ab:d9:0a (iPod-van-Jente) via fxp0_vlan2
Nov 29 12:51:03 	dhcpd: bind update on 172.19.8.56 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:52:18 	dhcpd: DHCPDISCOVER from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2
Nov 29 12:52:18 	dhcpd: unexpected ICMP Echo Reply from 10.10.1.254
Nov 29 12:52:19 	dhcpd: DHCPOFFER on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2
Nov 29 12:52:19 	dhcpd: DHCPREQUEST for 172.19.8.43 (172.19.0.3) from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2
Nov 29 12:52:19 	dhcpd: DHCPACK on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2
Nov 29 12:52:19 	dhcpd: bind update on 172.19.8.43 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:52:48 	dhcpd: DHCPDISCOVER from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2
Nov 29 12:52:48 	dhcpd: DHCPOFFER on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2
Nov 29 12:52:48 	dhcpd: DHCPREQUEST for 172.19.8.43 (172.19.0.3) from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2
Nov 29 12:52:48 	dhcpd: DHCPACK on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2
Nov 29 12:52:48 	dhcpd: bind update on 172.19.8.43 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:53:05 	dhcpd: DHCPREQUEST for 172.19.0.104 from d4:87:d8:cc:74:f3 via fxp0_vlan2
Nov 29 12:53:05 	dhcpd: DHCPACK on 172.19.0.104 to d4:87:d8:cc:74:f3 via fxp0_vlan2
Nov 29 12:53:05 	dhcpd: bind update on 172.19.0.104 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:53:48 	dhcpd: DHCPDISCOVER from 00:25:bc:95:09:72 via fxp0_vlan2
Nov 29 12:53:49 	dhcpd: unexpected ICMP Echo Reply from 10.10.1.254
Nov 29 12:53:49 	dhcpd: DHCPOFFER on 172.19.0.119 to 00:25:bc:95:09:72 (Stef-Winkeleer) via fxp0_vlan2
Nov 29 12:53:50 	dhcpd: DHCPREQUEST for 172.19.0.119 (172.19.0.3) from 00:25:bc:95:09:72 (Stef-Winkeleer) via fxp0_vlan2
Nov 29 12:53:50 	dhcpd: DHCPACK on 172.19.0.119 to 00:25:bc:95:09:72 (Stef-Winkeleer) via fxp0_vlan2
Nov 29 12:58:08 	dhcpd: DHCPREQUEST for 172.19.9.34 from 58:b0:35:11:58:7f (evert) via fxp0_vlan2
Nov 29 12:58:08 	dhcpd: DHCPACK on 172.19.9.34 to 58:b0:35:11:58:7f (evert) via fxp0_vlan2
Nov 29 12:58:08 	dhcpd: bind update on 172.19.9.34 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:58:46 	dhcpd: DHCPDISCOVER from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2
Nov 29 12:58:46 	dhcpd: unexpected ICMP Echo Reply from 10.10.1.254
Nov 29 12:58:47 	dhcpd: DHCPOFFER on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2
Nov 29 12:58:47 	dhcpd: DHCPREQUEST for 172.19.8.43 (172.19.0.3) from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2
Nov 29 12:58:47 	dhcpd: DHCPACK on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2
Nov 29 12:58:47 	dhcpd: bind update on 172.19.8.43 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 29 12:59:39 	dhcpd: DHCPDISCOVER from 90:27:e4:77:8f:ad via fxp0_vlan2: load balance to peer dhcp0
Nov 29 12:59:41 	dhcpd: DHCPREQUEST for 172.19.8.53 (172.19.0.2) from 90:27:e4:77:8f:ad via fxp0_vlan2: lease owned by peer
Nov 29 13:00:05 	dhcpd: DHCPDISCOVER from 34:4b:50:b6:4b:19 (android_bdb252201df34e7d) via fxp0_vlan2: load balance to peer dhcp0
Nov 29 13:00:06 	dhcpd: DHCPDISCOVER from 34:4b:50:b6:4b:19 (android_bdb252201df34e7d) via fxp0_vlan2: load balance to peer dhcp0
Nov 29 13:00:06 	dhcpd: DHCPREQUEST for 172.19.8.51 (172.19.0.2) from 34:4b:50:b6:4b:19 (android_bdb252201df34e7d) via fxp0_vlan2
Nov 29 13:00:06 	dhcpd: DHCPACK on 172.19.8.51 to 34:4b:50:b6:4b:19 (android_bdb252201df34e7d) via fxp0_vlan2
Nov 29 13:00:06 	dhcpd: bind update on 172.19.8.51 from dhcp0 rejected: incoming update is less critical than outgoing update
                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.