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: dhcrelay is listening on all of myinterfaces instead of
specified ones (Simon Hobson)
2. Re: dhcpd and relayed responses from multi-interface Linux
server (Neufeld, Keith)
3. Re: dhcrelay is listening on all of myinterfaces instead of
specified ones (Rimvydas)
4. Re: dhcpd and relayed responses from multi-interface Linux
server (Simon Hobson)
5. When are IPv6 leases renewed in relation to preferred-life
and max-life (Magnus Holmgren)
6. Re: dhcpd and relayed responses from multi-interface Linux
server (sth...@nethelp.no)
7. Unsubscribe (Wells (US), Rudy C)
----------------------------------------------------------------------
Message: 1
Date: Thu, 4 Jun 2020 13:16:35 +0100
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: dhcrelay is listening on all of myinterfaces instead of
specified ones
Message-ID: <04a8e4fd-7c00-44d1-8aea-20ddc6b1d...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
rimvydukas <rimvy...@rimvydas.info> wrote:
> Just installed isc-dhcp-relay package on my Buster and noticed one
> interesting thing:
>
> usr/sbin/dhcrelay -d -i eth0lo 172.50.16.253
Is "eth0lo" a typo or a copy/paste error ?
Simon
------------------------------
Message: 2
Date: Thu, 4 Jun 2020 14:00:40 +0000
From: "Neufeld, Keith" <keith.neuf...@wichita.edu>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: dhcpd and relayed responses from multi-interface Linux
server
Message-ID: <a7c624d8-5a0c-42cf-b2f6-a18deae4a...@wichita.edu>
Content-Type: text/plain; charset="us-ascii"
> On Jun 3, 2020, at 09:44 , Simon Hobson <dh...@thehobsons.co.uk> wrote:
>
>> The DHCP servers have two interfaces ..., one for administrative access and
>> one for application service access:
>>
>> eth0 -- 10.1.61.16 -- admin
>> eth1 -- 10.1.69.16 -- service
>>
>> We have subnet declarations for each interface because we need to serve
>> clients on each of those subnets; but dhcpd is being invoked with eth1 on
>> its command line
>
> Is there a specific reason for doing it this way ? While it's easy to reply
> with what is in effect "you're building the network wrong", that does seem to
> be the fundamental issue here.
Our server team operates many servers with multiple interfaces ... as have I
over the last thirty years ... and I haven't regarded it as "building the
network wrong." Could you say more about how that's inappropriate?
>> and appears to be listening only on eth1 as desired:
>>
>> Jun 1 16:26:18 netsvc-516 dhcpd[704228]: Listening on
>> LPF/eth1/00:50:56:be:43:d6/10.1.69.0/24
>> Jun 1 16:26:18 netsvc-516 dhcpd[704228]: Sending on
>> LPF/eth1/00:50:56:be:43:d6/10.1.69.0/24
>> Jun 1 16:26:18 netsvc-516 dhcpd[704228]: Sending on
>> Socket/fallback/fallback-net
>>
>> The problem is with the "fallback" UDP socket used for transmitting unicast
>> messages, when it needs to send responses to relayed DISCOVERs. In
>> common/socket.c, in the function maybe_setup_fallback(), a UDP INET socket
>> is created but not bound to any specific interface. Then when packets are
>> transmitted out the fallback socket, it appears that the behavior is to use
>> the server host's route table to decide which interface to send the packet
>> out of, *and to use that interface's IP as the source IP*.
> ...
>> Has this come up on the list before?
>
> I don't recall seeing this before on the list. But then it would be normal to
> serve the locally connected devices directly rather than via a relay agent -
> hence few would hit the problem.
Oh, you've mistaken my meaning. We expect local devices to be served locally.
At least on this platform, dhcpd does not respond correctly to *any* relayed
message to a multi-interface DHCP server unless the messages are relayed to the
interface that is the server host's default route out.
This means, for example, that you cannot relay to multiple interfaces on the
same DHCP server ... which I would like to be able to do temporarily while
migrating the server from an old IP in an old subnet to a new IP in a new
subnet, serving both at the same time while phasing the updates of the routers'
IP helper / DHCP relay statements.
I'd expected others might have other use cases; but from the lack of prior
conversation about this, apparently not.
--
Keith Neufeld
Director of Networking and Telecommunications
Wichita State University
------------------------------
Message: 3
Date: Thu, 4 Jun 2020 17:07:56 +0300
From: Rimvydas <rimvy...@rimvydas.info>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: dhcrelay is listening on all of myinterfaces instead of
specified ones
Message-ID: <16aa4c2a-b81c-4904-9241-b5f2ba911...@rimvydas.info>
Content-Type: text/plain; charset=utf-8
Hi,
No, its not the typo:) Its my custom named interface. I removed ?lo? part in
the further output and just forgot to do the same in the place you mentioned...
> On 4 Jun 2020, at 15:16, Simon Hobson <dh...@thehobsons.co.uk> wrote:
>
> rimvydukas <rimvy...@rimvydas.info> wrote:
>
>> Just installed isc-dhcp-relay package on my Buster and noticed one
>> interesting thing:
>>
>> usr/sbin/dhcrelay -d -i eth0lo 172.50.16.253
>
> Is "eth0lo" a typo or a copy/paste error ?
>
> 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: 4
Date: Thu, 4 Jun 2020 16:23:56 +0100
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: dhcpd and relayed responses from multi-interface Linux
server
Message-ID: <7eaa11a8-50c5-403d-9e54-36501bd38...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
Neufeld, Keith <keith.neuf...@wichita.edu> wrote:
>>> The DHCP servers have two interfaces ..., one for administrative access and
>>> one for application service access:
>>>
>>> eth0 -- 10.1.61.16 -- admin
>>> eth1 -- 10.1.69.16 -- service
>>>
>>> We have subnet declarations for each interface because we need to serve
>>> clients on each of those subnets; but dhcpd is being invoked with eth1 on
>>> its command line
>>
>> Is there a specific reason for doing it this way ? While it's easy to reply
>> with what is in effect "you're building the network wrong", that does seem
>> to be the fundamental issue here.
>
> Our server team operates many servers with multiple interfaces ... as have I
> over the last thirty years ... and I haven't regarded it as "building the
> network wrong." Could you say more about how that's inappropriate?
In this case I think there is an argument that you are building the network
wrong. I read that you have devices that are connected to the network on eth0
but are being services via relay agents forwarding requests via the network on
eth1. In your original message you wrote :
> We have subnet declarations for each interface because we need to serve
> clients on each of those subnets; but dhcpd is being invoked with eth1 on its
> command line
and so I assumed we were talking about clients in the eth0 network.
For these, relaying requests that could be handled directly could be considered
"building the network wrong".
> Oh, you've mistaken my meaning. We expect local devices to be served locally.
>
> At least on this platform, dhcpd does not respond correctly to *any* relayed
> message to a multi-interface DHCP server unless the messages are relayed to
> the interface that is the server host's default route out.
>
> This means, for example, that you cannot relay to multiple interfaces on the
> same DHCP server ... which I would like to be able to do temporarily while
> migrating the server from an old IP in an old subnet to a new IP in a new
> subnet, serving both at the same time while phasing the updates of the
> routers' IP helper / DHCP relay statements.
Ah, now I understand !
I think the simple answer is that it should not matter what source address is
used - only the destination address which routes the packet back to the relay
agent. In terms of protocol spec, that is the case - there's an implicit
assumption that regardless of the source address, the routing will get it to
where it needs to be.
Your problem is that your relay agents impose restrictions which are outside of
the spec - and yes, I understand your problem now. It's neither the
multi-homing nor the relay security that's causing the problem - but the
combination of both of them. I suspect there will be many setups with one or
the other in place - but few with both, and hence the problem you see.
The only solution I can think of is as I described in my earlier post - use the
output mangle table to alter the source address. In a "stable" setup I think it
should be as simple as "protocol=UDP and source port=67" -> "set source address
to 10.1.69.16". As long as the server only has one address it uses for DHCP
service then that ought to work.
Now, for your potential migration setup I think it gets a bit more complicated.
You might need to expand that logic along the lines of :
"protocol=UDP and source port=67 and dest IP in 10.0.0.0/8" -> "set source
address to 10.1.69.16"
"protocol=UDP and source port=67 and dest IP in 172.16.0.0/12" -> "set source
address to 172.17.69.16"
Is that any help ?
There is one thing that also comes to mind. AIUI the ISC DHCP server is more or
less out of active development, with Kia having taken over as the actively
developed ISC DCHP server going forwards. TBH I think it's done marvellous duty
seeing as it was originally intended as a reference implementation of the RFC.
I've not kept up with how Kia is doing - last I read it was ahead on some
features and behind on others. It might be worth looking into whether Kia
operates the same or differently in this respect, and if it has the same issue,
whether ISC might take on the problem as a feature request (though their policy
is AIUI, "you want it, you sponsor it"). If you have some bright CS people in
the Uni, could it become part of a project for a small group of them ?
Just tossing ideas out there in case any of them are suitable for your
situation.
------------------------------
Message: 5
Date: Thu, 04 Jun 2020 19:47:44 +0200
From: Magnus Holmgren <holmg...@lysator.liu.se>
To: dhcp-users@lists.isc.org
Subject: When are IPv6 leases renewed in relation to preferred-life
and max-life
Message-ID: <4192466.NG4n1uHZ5j@johansson>
Content-Type: text/plain; charset="us-ascii"
Hello, quick question:
My ISP hands out IPv6 leases with a max-life of 86400 (24h) but a preferred-
life of only 7200 (2h), and dhclient -6 (4.4.1-2; Debian 10) only renews the
lease after half the max-life. This results in the address being deprecated
most of the time, which causes problems when the kernel chooses an address
from a VPN as the source for packages to the VPN endpoint, for example.
Is my ISP misbehaving by setting a valid-life less than half the max-life (and
not specifying renew and rebind times), or is this a bug in dhclient, or
(least probably) does dhclient try to renew the lease, but the server ignores
it and dhclient doesn't say anything about this? (Surely having to deprecate
the only global-scope address on an interface is undesirable?)
Can I supersede override these values in dhclient.conf? Seems you can only
supersede options, and these are not options?
Thanks,
--
Magnus Holmgren holmg...@lysator.liu.se
(No Cc of list mail needed, thanks)
------------------------------
Message: 6
Date: Thu, 04 Jun 2020 22:06:28 +0200 (CEST)
From: sth...@nethelp.no
To: dhcp-users@lists.isc.org, keith.neuf...@wichita.edu
Subject: Re: dhcpd and relayed responses from multi-interface Linux
server
Message-ID: <20200604.220628.504687978.sth...@nethelp.no>
Content-Type: Text/Plain; charset=us-ascii
> At least on this platform, dhcpd does not respond correctly to *any* relayed
> message to a multi-interface DHCP server unless the messages are relayed to
> the interface that is the server host's default route out.
This is certainly not the case for *all* platforms that ISC DHCP runs
on. I don't have these problems with FreeBSD, for instance.
Steinar Haug, Nethelp consulting, sth...@nethelp.no
------------------------------
Message: 7
Date: Thu, 4 Jun 2020 22:15:04 +0000
From: "Wells (US), Rudy C" <rudy.c.we...@boeing.com>
To: "dhcp-users@lists.isc.org" <dhcp-users@lists.isc.org>
Subject: Unsubscribe
Message-ID: <e046f74d8c8f418480fbff6e07665...@boeing.com>
Content-Type: text/plain; charset="us-ascii"
I will be retiring soon and need to be removed from this email list.
Thank you,
Rudy Wells
Rudy C. Wells
DHCP Service Owner.
DNS Service Support.
NTP Service Support
Boeing IT Network Management Tools
Location 33-01.1 1B6-3.5
Mail Stop 7R-102
Office Phone : 425-965-6418
Cell : 425-761-8996
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20200604/48cc9ef1/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 140, Issue 2
******************************************
