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

[Simon]

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.

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



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 ?

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


Simon