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? (Philippe Maechler)
2. Re: DISCOVERs from "unkown network segment" - suppress log
messages? (Simon)
----------------------------------------------------------------------
Message: 1
Date: Mon, 28 Nov 2022 19:16:50 +0100
From: Philippe Maechler <plcmaech...@gmail.com>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DISCOVERs from "unkown network segment" - suppress log
messages?
Message-ID:
<CAPhukgbhS=DPdU9Xm=u7jaas6r+f-iy18vvcoddsktp7vg1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I have my own experience with clients sending hundreds request per second.
at the beginning it was just some background noise later we had 2mbps
background noise only from buggy clients
with ipv6 turned on, it got even worse.
the access platform we used did dhcp- and mld-snokping and was coredumping
because it went oom. we had to firewall all the v6 requests, just to get a
somewhat stable network again.
this is just the operational site. huge logs, long searchtimes and tricky
grep and awk patterns to parse the logs is a other story
if possible, try to silence those false dhcp relays. if not possible, check
if you can insert an acl on your router or switche so that this traffic is
ocmed relativle near to the relay agent.
make some notes somewhere or otherwise it will bite back in a few years
(we had to firewall this ~8years ago and it still takes down whole network
segments if we remove the acl)
good luck
Christina Siegenthaler <t...@ieu.uzh.ch> schrieb am Mo., 28. Nov. 2022,
15:36:
>
>
> > 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
>
>
>
>
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20221128/4e744409/attachment-0001.htm>
------------------------------
Message: 2
Date: Mon, 28 Nov 2022 22:08:13 +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: <bef86f6d-8736-446d-a738-3ecdaaa36...@thehobsons.co.uk>
Content-Type: text/plain; charset=utf-8
Christina Siegenthaler <t...@ieu.uzh.ch> wrote:
> 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?
Ooh, that does sound like fun ... not :-(
> (Sorry for the rant)
We all have to let off steam from time to time
>> 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.
You will have to compile it yourself, but there?s a config option to not use
raw packets. The downside is that if you turn that off, it can?t handle local
clients - only relayed ones.
Sten Carlsen <st...@s-carlsen.dk> wrote:
> Also I would look at the authoritative statement to not send DHCPNAKs to
> everybody else (or maybe do it to underline the situation).
Funnily enough, I was thinking something along the same lines - though I was
thinking more along the lines of offering bad config information. Downside
being that it probably wouldn?t enhance one?s career :-( Perhaps even target
the machines used by those who made the ?upgrade? decision - though in practice
it (probably/possibly) wouldn?t work.
Assuming most management are using Windows, that?s very ?sticky? about DHCP.
The Windows DHCP server is not RFC compliant, but that?s fixed with client
behaviour for Windows machines. You can have a rogue DHCP server on the network
for days/weeks/months and it?ll have no effect - then when the Windows server
handling the network fails for some reason, the network breaks and no-one can
remember using a redundant ADSL router as a switch (and forgetting to turn off
it?s DHCP server). I think you can guess how I know that little nugget of
experience ;-)
Sten Carlsen <st...@s-carlsen.dk> wrote:
> I come to think of an earlier thread where some printers were described that
> would only accept a lease of more than IIRC one year - this could be one of
> those.
I had that, back in the late 90s/early 00s I think. It was a Minolta copier
(early days of digital copiers) which would not take an address by DHCP and I
had to manually configure it. I later found out that it would refuse anything
shorter than 2 years - for what reason one can only speculate, or perhaps the
people imposing that restriction had been smoking something ?special?.
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 14
*******************************************
