DISCOVERs from "unkown network segment" - suppress log messages?

Christina Siegenthaler tina at ieu.uzh.ch
Sat Nov 26 10:17:04 UTC 2022


Hi

> Am 25.11.2022 um 19:23 schrieb Simon <dhcp1 at thehobsons.co.uk>:
> 
> Darren Ankney <darren.ankney at gmail.com> wrote:
> 
>> Since the log messages say: via 10.xx.xx.1: unknown network segment, I
>> assume that the 10.xx.xx.xx/xx subnet is not one you are concerned
>> with.  If that is, indeed, the case, I suggest adding a firewall rule
>> either on the server itself or further upstream to block traffic from
>> that subnet (or just the 10.xx.xx.1 host) to UDP port 67. The "via
>> 10.xx.xx.1" indicates that the traffic is being relayed, so it should
>> be unicast and not difficult to add to the firewall.
> 
> Yes, that’s probably the easiest way to deal with it. I have a rather vague recollection that a server rule might not work as dhcpd uses raw packet handling by default which means it gets to see packets before the network stack.

OK, I was afraid that this would be the case. I’ll look into firewall configuration then (the DHCP server runs on macOS).


> 
> Also, who is the network administrator responsible for the kit that’s incorrectly relaying requests to your server ? Perhaps the OP should “invite them” to correct their clearly broken config - I hesitate to suggest the use of a piece of clue by four :D

Couldn’t agree more here! Unfortunately, the decision for that brand/ model for the new network hardware came from higher up (and they took the ones with the lowest quote, of course)…
We, and the network admins, already noticed in summer 2021 (!), when the first new switches were up, that they cannot configure them to relay DISCOVERs to the correct DHCP server, they can only relay all request to all servers. They filed a feature request with Huawei to add this - of course, we’re still waiting. They network admins are pretty p*** off, too, because this worked fine with the old config, and in our opinion, this is a crucial feature for network hardware, but…

Thus I’d like to see what I can on my end, for the time being.

> 
> 
> 
> Christina Siegenthaler <tina at ieu.uzh.ch> wrote:
> 
>> Background is, we (unfortunately) got new network hardware (Huawei instead of Cisco), and now I get also DHCP requests from buildings and networks that do not belong to our department and that are not served by our DHCP server.
> 
> I would disagree with “it’s not a problem” since it clearly indicates that there is a network misconfiguration in the new kit - so if someone got this wrong, what else did they get wrong ?

Agree - but see above, we’ll have to live with it somehow. Maybe they’ll add that feature at some time.

> 
>> This is usually not a problem since the server simply ignores those requests (though it logs them), but now there is a client in one of the other subnets which constantly sends DISCOVERS (about 200 per minute); they fill my log file and I’d like to get rid of them ...
> 
> 200 per minute ! That’s a seriously badly configured client and I’d be asking whoever is responsible for that network to be tracking it down and “asking” the user to remove it until it’s been fixed. Mind you, the user might well be wondering why it’s not working properly ?
> 00:07:32 belongs to AAEON Technology Inc. (an OUI lookup tool such as https://www.wireshark.org/tools/oui-lookup.html is helpful here). Their website (https://www.aaeon.com/en/) says "AAEON Technology Inc. is a leading manufacturer of advanced industrial and embedded computing platforms.” so the device could be almost anything.
> But as I know internal politics in universities can be “interesting”, perhaps just stick with firewalling the requests.

Yeah, indeed. I called the IT guy of the department responsible for the device. It seems to be a 3D printer. Obviously, they took it off the network after my call, since I did not get the DISCOVERs for a few days, but now they have started again. Wrote them an email since it was Friday evening, but it would be easier for me to be able to just ignore the requests, rather than call them every few days…

Thank you all,

Tina


> 
> 
> Simon
> 
> -- 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users


---------------------------------------------------------------------------------
Dr. Tina Siegenthaler

IT support

Institute of Evolutionary Biology and Environmental Studies
University of Zurich
Winterthurerstr. 190
8057 Zürich

tel : ++41 44 6354891
email: tina at ieu.uzh.ch
---------------------------------------------------------------------------------



More information about the dhcp-users mailing list