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

Mon Nov 28 14:36:17 UTC 2022

> Am 26.11.2022 um 18:13 schrieb Simon <dhcp1 at thehobsons.co.uk>:
> 
> Christina Siegenthaler <tina at ieu.uzh.ch> wrote:
> 
>>> 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)…
> 
> Of course ! And I assume accept zero responsibility for any problems they’ve lumbered you all with.

Yep.

> 
>> 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…
> 
> That’s ... well I suspect if I wrote what I first thought when I read that, I’d be on the list admin’s naughty step for a while !
> Hmm, perhaps judicious application of an Etherkiller and then tell the higher ups that the frequent failures are because the cheap stuff they bought is rubbish ;-)
> 
> There is another option though.
> Relay agents do NOT need to be in the routers - they can be anywhere on the client network. So it would be possible (technically) to simply turn off the very broken relay agents in the Huawei kit, and fire up a separate device to run a relay agent. I realise this is probably not practical on financial and political grounds :-(
> 
> Does the Huawei kit have egress filters available ? If so, then that might be another option - filter the outbound relayed packets in each router so that they only go to the server responsible for that subnet. Again, more hassle for the network admins, but it might be a work around.

I don’t know - I have nothing to do with the hardware and zero access to it… I can pass it along, but I have my doubts.

> 
> Lastly, was this rubbish procured as a “supply the kit and our network people will configure it” or “supply and configure kit to do x, y, z” ? If the latter, then there would be an argument that the supplier should sort this out as what they’ve supplied doesn’t meet the requirements (if they shift enough boxes, they might have more clout with Huawei). But I imagine that would also be politically difficult, and the window for doing so has long past (and the supplier has disappeared over the horizon on their horse).
> And yes, I have scars from buying kit where the vendor says it will do <list of things we want from it>, but manage to string out the support calls long enough to be paid before we can conclusively state “doesn’t do <some subset of functions>, you aren’t getting paid till you sort it”.

Again, I have no idea, that decision was made way above my paygrade, and we (the departments) had nothing to say about it and obviously the network admins didn’t have much to say either, they’re absolutely not happy with that stuff either. We got an email recently, asking us to be extra careful about the configuration of our DHCP server, so it will answer requests from our department’s networks only and not from anybody else’s. I’m afraid it’s only a matter of time until something goes seriously wrong here… I really hope they fix this soon.
Especially since at the moment only a few buildings have been „upgraded“ (if you can call it that) to the new hardware. It’s going to be real fun when the rest follows and I get DHCP requests from all over the university…
(Sorry for the rant)

> 
> 
>>> 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…
> 
> Just think given the above, 200 request packets/second relayed to every DHCP server on the network 8-O That’s some serious wastage of resource.
> As you say, simplest to just firewall the packets and ignore it.

Tried that today, unfortunately to no avail. macOS has pf installed, but obviously pf does not / cannot block DHCP packets or the other way round, dhcpd grabs the DISCOVERs before pf rules come into effect. So I’m back to field one…

Any other ideas?

Thanks, 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