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

[Simon]

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.

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

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


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


Simon