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: DISCOVERs from "unkown network segment" - suppress log
messages? (Simon)
----------------------------------------------------------------------
Message: 1
Date: Sat, 26 Nov 2022 17:13:52 +0000
From: Simon <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DISCOVERs from "unkown network segment" - suppress log
messages?
Message-ID: <fdaa5f27-98ff-4c35-b3ba-d5d5e3913...@thehobsons.co.uk>
Content-Type: text/plain; charset=utf-8
Christina Siegenthaler <t...@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
------------------------------
Subject: Digest Footer
_______________________________________________
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 169, Issue 10
*******************************************
