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.
    • 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.