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? (Christina Siegenthaler)
2. Re: DISCOVERs from "unknown network segment" - suppress log
messages? (Neufeld, Keith)
----------------------------------------------------------------------
Message: 1
Date: Mon, 28 Nov 2022 14:36:17 +0000
From: Christina Siegenthaler <t...@ieu.uzh.ch>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DISCOVERs from "unkown network segment" - suppress log
messages?
Message-ID: <27c93799-94aa-4e2d-8f12-7c4a04e0c...@ieu.uzh.ch>
Content-Type: text/plain; charset="utf-8"
> Am 26.11.2022 um 18:13 schrieb Simon <dh...@thehobsons.co.uk>:
>
> 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.
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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
Message: 2
Date: Mon, 28 Nov 2022 14:49:16 +0000
From: "Neufeld, Keith" <keith.neuf...@wichita.edu>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DISCOVERs from "unknown network segment" - suppress log
messages?
Message-ID: <a0b86891-4ed2-4733-94b1-947f7ba50...@wichita.edu>
Content-Type: text/plain; charset="utf-8"
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?
I'd be inclined to make a dhcpd.conf-not-our-subnets containing subnet
declarations with no pools for all the other subnets that show up in your logs
and "include" it into your dhcpd.conf .
I've had mixed success with "ignore booting" over the years (some versions of
the server it works, some it doesn't and I still get logs), but I'd definitely
put it into each of the subnet declarations for wishful thinking. I know you
already tried it in an individual host declaration, but still worth trying in a
subnet.
Lacking an "ignore unknown subnets" configuration mechanism, it seems like this
might work and be next best.
--
Keith Neufeld
Director of Networking and Telecommunications
Wichita State University
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20221128/c5eec87f/attachment.htm>
------------------------------
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 11
*******************************************
