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

    Duplicate DHCP entries

    Scheduled Pinned Locked Moved
    DHCP and DNS
    4
    12
    8.8k
    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
      sandern
      last edited by

      In the system log I get these messages:

      Nov 20 13:34:54 	dhcpd: uid lease 172.19.0.104 for client d4:87:d8:cc:74:f3 is duplicate on 172.19.0.0/20
Nov 20 14:08:39 	dhcpd: bind update on 172.19.0.174 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 20 14:44:05 	dhcpd: uid lease 172.19.9.39 for client d4:87:d8:cc:74:f3 is duplicate on 172.19.0.0/20
Nov 20 15:53:30 	dhcpd: uid lease 172.19.8.138 for client 74:2f:68:a4:cf:b0 is duplicate on 172.19.0.0/20
Nov 21 08:19:32 	dhcpd: uid lease 172.19.9.114 for client f0:7b:cb:20:b2:5c is duplicate on 172.19.0.0/20
Nov 21 08:26:57 	dhcpd: uid lease 172.19.9.34 for client 58:b0:35:11:58:7f is duplicate on 172.19.0.0/20
Nov 21 08:30:41 	dhcpd: uid lease 172.19.8.136 for client 00:16:d4:73:5c:e3 is duplicate on 172.19.0.0/20
Nov 21 09:38:19 	dhcpd: uid lease 172.19.8.135 for client f0:7b:cb:20:b2:5c is duplicate on 172.19.0.0/20
Nov 21 12:22:56 	dhcpd: uid lease 172.19.9.118 for client 00:16:d4:73:5c:e3 is duplicate on 172.19.0.0/20
Nov 22 12:04:04 	dhcpd: uid lease 172.19.8.133 for client 00:22:fa:67:13:c8 is duplicate on 172.19.0.0/20
Nov 22 12:28:00 	dhcpd: bind update on 172.19.0.104 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 22 14:51:01 	dhcpd: bind update on 172.19.9.57 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 22 15:08:25 	dhcpd: uid lease 172.19.9.120 for client f0:7b:cb:20:b2:5c is duplicate on 172.19.0.0/20
Nov 23 08:53:51 	dhcpd: uid lease 172.19.1.13 for client 18:87:96:59:21:0d is duplicate on 172.19.0.0/20
Nov 23 09:40:10 	dhcpd: parse_option_buffer: malformed option dhcp.nds-context (code 87): option length exceeds option buffer length.
Nov 23 15:23:00 	dhcpd: uid lease 172.19.9.129 for client 9c:b7:0d:b5:c3:6a is duplicate on 172.19.0.0/20
Nov 26 07:42:46 	dhcpd: uid lease 172.19.0.106 for client c8:33:4b:4b:fe:0c is duplicate on 172.19.0.0/20
Nov 26 08:22:14 	dhcpd: bind update on 172.19.0.162 from dhcp0 rejected: incoming update is less critical than outgoing update
Nov 26 10:14:29 	dhcpd: uid lease 172.19.9.134 for client 9c:b7:0d:b5:c3:6a is duplicate on 172.19.0.0/20

      And in the dhcp leases table I see for about half of the devices a duplicate entry:

      Example for one device:

      172.19.9.118  	00:16:d4:73:5c:e3  	android_7287c108d8a90392  	2012/11/21 12:23:11  	2012/11/21 12:24:30  	offline  	reserved  	[add a static mapping for this MAC address] 	[add a Wake on LAN mapping for this MAC address] 	[delete this DHCP lease]
172.19.8.136  	00:16:d4:73:5c:e3  	android_7287c108d8a90392  	2012/11/21 09:23:05  	2012/11/21 08:34:33  	offline  	reserved  	[add a static mapping for this MAC address] 	[add a Wake on LAN mapping for this MAC address] 	[delete this DHCP lease]
172.19.8.146  	00:16:d4:73:5c:e3  	android_7287c108d8a90392  	2012/11/19 09:16:40  	2012/11/19 08:33:25  	offline  	reserved  	[add a static mapping for this MAC address] 	[add a Wake on LAN mapping for this MAC address] 	[delete this DHCP lease]
172.19.8.160  	00:16:d4:73:5c:e3  	android_7287c108d8a90392  	2012/11/15 09:13:24  	2012/11/15 08:41:02  	offline  	reserved  	[add a static mapping for this MAC address] 	[add a Wake on LAN mapping for this MAC address] 	[delete this DHCP lease]
172.19.9.73  	00:16:d4:73:5c:e3  	android_7287c108d8a90392  	2012/11/12 15:11:39  	2012/11/12 15:10:50  	offline  	reserved  	[add a static mapping for this MAC address] 	[add a Wake on LAN mapping for this MAC address] 	[delete this DHCP lease]

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

      This machine is being used as a captive portal so it are all mobile devices.

      Does anyone have an idea what's causing this? (Pfsense 2.0.1) The system is using a dhcp failover peer, I have a feeling that that's got something to do with it.

      1 Reply Last reply Reply Quote 0
      • johnpozJ
        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 24.11 | Lab VMs 2.7.2, 24.11

        1 Reply Last reply Reply Quote 0
        • S
          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
            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
              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 24.11 | Lab VMs 2.7.2, 24.11

              1 Reply Last reply Reply Quote 0
              • S
                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
                  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 24.11 | Lab VMs 2.7.2, 24.11

                  1 Reply Last reply Reply Quote 0
                  • S
                    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
                      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 24.11 | Lab VMs 2.7.2, 24.11

                      1 Reply Last reply Reply Quote 0
                      • jimpJ
                        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
                          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
                            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.