Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: DHCP server assigned its own address (Larry Apolonio)
2. Re: Esoteric question (Simon Hobson)
3. Re: Esoteric question (Gregory Sloop)
----------------------------------------------------------------------
Message: 1
Date: Wed, 18 Sep 2019 06:54:58 -0700
From: Larry Apolonio <isc-d...@rh73.com>
To: dhcp-users@lists.isc.org
Subject: Re: DHCP server assigned its own address
Message-ID: <cb171646-5735-0a89-0d7a-c2f89a2d1...@rh73.com>
Content-Type: text/plain; charset=utf-8; format=flowed
I should have used SED to sanitize my post.
Anyway thanks all for your help, I fixed the subnet, it no longer has
the IP address of the server,
I am now tasked to audit all of the other entries to make sure they look
fine and do not overlap any statics.
LA
On 9/17/2019 2:20 AM, Bill Shirley wrote:
> The IP address of the DHCP server is 192.168.11.10
> ??????? range 192.168.11.10 *10.254.11.10*;
> You configured it to assign it's own address.
>
> Also your rage ending address is outside your subnet:
> ?? option subnet-mask 255.255.255.0;
>
> Bill
>
> On 9/16/2019 9:31 PM, Larry Apolonio wrote:
>>
>> All,
>>
>> I have a weird problem that I am trying to solve.
>>
>> In short, for those who don't want to read the details, I am trying to
>> figure out why the DHCP server assigned its own IP address to another
>> device.
>>
>>
>> My dhcp server is running on CentOS 6.10 and is the regular RPM that
>> comes with that distribution dhcp-4.1.1-63.P1.el6.centos.x86_64.
>>
>> What is a little unusual is that webmin is used to manage the dhcp
>> server, for the most part it works for our environment.
>>
>> Yesterday, I got a nagios alert that the server was no longer
>> available. ?This nagios server is on the same subnet as the server so
>> there was no weird firewall routing issues involved.? With the help of
>> the networking guys, we found that another machine took the IP address
>> of our DHCP server.? This happened late July this year and it ended up
>> being a human error, the person spinning up a machine on this network
>> assigned a static IP address to their machine that was the same IP as
>> our server, so we thought someone did it again.
>>
>> The difference this time is that it seems like the DHCP server itself
>> assigned its own IP address
>>
>> Here is a sample of that subnet declaration, with IPs changed to
>> protect the innocent
>>
>> # XXXXXX Subnet
>> subnet 192.168.11.0 netmask 255.255.255.0 {
>> ??????? range 192.168.11.10 10.254.11.10;
>> ??????? option subnet-mask 255.255.255.0;
>> ??????? default-lease-time 28800;
>> ??????? option broadcast-address 192.168.11.255;
>> ??????? option routers 192.168.11.254;
>> ??????? option domain-name-servers 208.67.222.222 , 208.67.220.220;
>> ??????? option domain-name "example.local";
>> ??????? }
>>
>> The IP address of the DHCP server is 192.168.11.10, I personally would
>> not do this, I would have not even had the DHCP server IP address in
>> that range.? But please read on
>>
>> This is a rarely used subnet, so a machine appearing on this subnet is
>> rare, in fact I thought this subnet did not have a dhcp declaration
>> prior to me looking in to it.? Doesn't this log entry in
>> /var/log/messages confirm it? (hostname was changed in this paste)
>>
>> Sep 12 10:02:12 linuxdhcpserver dhcpd: No subnet declaration for eth0
>> (no IPv4 addresses).
>> Sep 12 10:02:12 linuxdhcpserver dhcpd: ** Ignoring requests on eth0.
>> If this is not what
>> Sep 12 10:02:12 linuxdhcpserver dhcpd:??? you want, please write a
>> subnet declaration
>> Sep 12 10:02:12 linuxdhcpserver dhcpd:??? in your dhcpd.conf file for
>> the network segment
>> Sep 12 10:02:12 linuxdhcpserver dhcpd:??? to which interface eth0 is
>> attached. **
>>
>> When the service was restarted 3 hours later, that same message about
>> no subnet declaration for eth0 did not appear.
>>
>> One reason we use webmin is so that non-linux folk (AKA people without
>> the root password) can log in to an easy web interface is to manage
>> the service that the Linux server does, in this case dhcp.
>>
>> But it also logs what they did, up to a certain point, I can tell who
>> edited which subnet declarations but not the exact changes they did.
>>
>> From the webmin logs, until yesterday this subnet was not changed.
>>
>> From the command line I also ran last to see who logged in, it was
>> either root, or a proper Linux server admin, and I admit that someone
>> in this group could be holding back, I don't think we did anything via
>> CLI.
>>
>> So I am at a loss, trying to figure out why a DHCP server would assign
>> its own IP address (it is pingable, no iptables rules blocking ICMP),
>> I thought conflict resolution would prevent it. If I am reading
>> RFC1541 section 2.2 correctly.
>>
>> Did someone do a good job at cleaning up their tracks?? I don't think
>> the effort or skill was there.? It would be easier to just admit they
>> made a mistake.
>>
>> Was webmin not logging correctly?? I really dont recall this subnet
>> being on this server, because I do recall seeing that message in the
>> logs regarding no subnet declaration in the past.
>>
>> Couple solutions were proposed so this would not happen again, the
>> biggest one is putting this server and its big brother nagios server
>> on its lonesome VLAN/subnet and restrict anything else from being on
>> this subnet.? Seems overkill but this IP hijack happened twice within
>> 60 days when it has been fine for years.
>>
>> Thank you,
>>
>> Larry Apolonio
>>
>> Although I have been speaking English for a while now, I still have
>> problems articulating my thoughts, thank you for your patience.
>>
>>
>> _______________________________________________
>> dhcp-users mailing list
>> dhcp-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
------------------------------
Message: 2
Date: Wed, 18 Sep 2019 21:47:34 +0100
From: Simon Hobson <si...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Esoteric question
Message-ID: <1c902b0a-c45f-4460-9eab-a273a1e9c...@thehobsons.co.uk>
Content-Type: text/plain; charset=utf-8
Gregory Sloop <gr...@sloop.net> wrote:
>Packet caps from the new router show that the router/DHCP server IS
>seeing all the DHCP protocol handshake. [When it's having the
>"problem."]
>The client does a DISCOVER
>Server responds with OFFER
>The client responds with REQUEST
>Then there's a LONG pause. [like 90s+ worth.]
>The Server responds with ACK. [It actually appears to send several
>ACKS.
Ah, about 90s you say ?
Have a look on the external interface and/or in the logs and see if it's trying
to do any DNS lookups or updates. Over the years I've seen lots of threads
related to 90s delays - a common one being SSH logins - which have come down to
the device attempting a DNS lookup and waiting for it to time out.
Anyway, what I theorise could be happening is :
With WAN connected, "something" (dhcpd) is trying to do "something" with an
outside service and timing out.
When the WAN is link-up but not connected to the modem, such attempts fail very
quickly as the device has no ARP entry for it's default route and so the
network stack quickly reports "no route to host".
BTW, when I first read your post I was thinking WTF ! It was only after reading
the other replies that this idea came to mind.
Simon
--
------------------------------
Message: 3
Date: Wed, 18 Sep 2019 14:50:14 -0700
From: Gregory Sloop <gr...@sloop.net>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Esoteric question
Message-ID: <203771846.20190918145...@sloop.net>
Content-Type: text/plain; charset="us-ascii"
Not to "diss" any of the prior suggestions - but THIS, well this is something I
can get behind!
It *might* not be correct, and it's a bust of an idea - but it, IMNSHO, ties
all the pieces together in a really elegant way.
It's just a concept that makes so much sense and makes all the weird symptoms
all seem so much more plausible.
Wow. Really, massive thanks Simon.
I'll try to update the list when/if I figure out what's wrong. [Unless I've
done something so incredibly stupid I'm too embarrassed to post about it... :( ]
The modem did get replaced today, so it's possible the symptoms simply vanish
because of some change in the modem config, etc. But we'll see.
Thanks so much all!
-Greg
SH> Gregory Sloop <gr...@sloop.net> wrote:
>>Packet caps from the new router show that the router/DHCP server IS
>>seeing all the DHCP protocol handshake. [When it's having the
>>"problem."]
>>The client does a DISCOVER
>>Server responds with OFFER
>>The client responds with REQUEST
>>Then there's a LONG pause. [like 90s+ worth.]
>>The Server responds with ACK. [It actually appears to send several
>>ACKS.
SH> Ah, about 90s you say ?
SH> Have a look on the external interface and/or in the logs and see
SH> if it's trying to do any DNS lookups or updates. Over the years
SH> I've seen lots of threads related to 90s delays - a common one
SH> being SSH logins - which have come down to the device attempting a
SH> DNS lookup and waiting for it to time out.
SH> Anyway, what I theorise could be happening is :
SH> With WAN connected, "something" (dhcpd) is trying to do
SH> "something" with an outside service and timing out.
SH> When the WAN is link-up but not connected to the modem, such
SH> attempts fail very quickly as the device has no ARP entry for it's
SH> default route and so the network stack quickly reports "no route to host".
SH> BTW, when I first read your post I was thinking WTF ! It was only
SH> after reading the other replies that this idea came to mind.
SH> Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20190918/fb56934a/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 131, Issue 15
*******************************************
