dhcp for 2 subinterface (Simon Hobson)
Evans Lin ( 林佳保 )
EvansLin at taiwanmobile.com
Fri Oct 22 16:43:38 UTC 2010
Dear Simon,
Thanks very much for your response
My server need to release two sub bundle in the same group (10.10.20.1 & 10.106.0.1),
but the broadcast will only appear 10.10.20.1
subbundle-a corresponding to its own "a.mac.list", subbundle-b corresponding to their "b.mac.list"
I want to know if you can do: When "b.mac.list " mac up to use 10.10.20.1 gw discover , the server must offer 10.106.0.x , but not 10.10.20.x ...
b.r.
evans
-----Original Message-----
From: dhcp-users-bounces+evanslin=taiwanmobile.com at lists.isc.org [mailto:dhcp-users-bounces+evanslin=taiwanmobile.com at lists.isc.org] On Behalf Of dhcp-users-request at lists.isc.org
Sent: Friday, October 22, 2010 8:00 PM
To: dhcp-users at lists.isc.org
Subject: dhcp-users Digest, Vol 24, Issue 27
Send dhcp-users mailing list submissions to
dhcp-users at 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-request at lists.isc.org
You can reach the person managing the list at
dhcp-users-owner at 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: security impact of accepting dhcp declines (Glenn Satchell)
2. Re: security impact of accepting dhcp declines
(Alexandre Bezroutchko)
3. Re: dhcp for 2 subinterface (Simon Hobson)
4. ISC DHCP 4.1.2rc1 is now available (Shawn Routhier)
5. ISC DHCP 4.0.3rc1 is now available! (David W. Hankins)
----------------------------------------------------------------------
Message: 1
Date: Thu, 21 Oct 2010 23:18:27 +1100
From: Glenn Satchell <glenn.satchell at uniq.com.au>
Subject: Re: security impact of accepting dhcp declines
To: Users of ISC DHCP <dhcp-users at lists.isc.org>
Message-ID: <4CC02F93.9050304 at uniq.com.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 10/21/10 22:51, Alexandre Bezroutchko wrote:
> Hello,
>
> I wonder if somebody could clarify how DHCP server will behave when
> somebody tries to exhaust its pool by abusing DHCPDECLINE messages. The
> manpages for dhcpcd.conf says the following:
>
> ...
> The declines keyword
>
> allow declines;
> deny declines;
> ignore declines;
>
> The DHCPDECLINE message is used by DHCP clients to indicate
> that the
> lease the server has offered is not valid. When the server
> receives a
> DHCPDECLINE for a particular address, it normally abandons
> that
> address, assuming that some unauthorized system is using it.
> _Unfortu-
> _ _nately, a malicious or buggy client can, using DHCPDECLINE messages,
> _ _completely exhaust the DHCP server's allocation pool_. The server will
> reclaim these leases, but while the client is running through the
> pool,
> it may cause serious thrashing in the DNS, and it will _also
> cause the
> _ _DHCP server to forget old DHCP client address allocations_.
>
> The declines flag tells the DHCP server whether or not to honor
> DHCPDE-
> CLINE messages. If it is set to deny or ignore in a particular
> scope,
> the DHCP server will not respond to DHCPDECLINE messages.
> ...
>
> I don't get the part about trashing DNS. Does this refer to the case
> when DNS updates are on?
Yes. Each new request would result in a new DNS entry being added, then
removed when it is declined. This only matters if the dhcp server is
doing dynamic DNS updates.
> And the statement about reclaiming these leases, but forgetting old DHCP
> client allocations... Will DHCP server start throwing away existing
> leases when the pool get exhausted?
The DHCP server will offer all the current expired leases on a
least-recently-used basis. Then it will start trying abandoned leases,
and after that it will say "no more leases".
As it offers each expired lease, it will re-write the lease entry with
the client it was offered to and then as abandoned when it is declined,
and in doing so will lose the information about which device had been
last assigned that address. Part of RFC 2131 specifies that a DHCP
server must remember the client it previously gave a lease to, so that
it can offer them the same IP address if they ever come back again
(provided that it is free of course).
> Any input and/or reference to the official docs relevant to my question
> are greatly appreciated.
The DHCP RFCs contain the theory about how a DHCP server should operate
(see the lists in the doc subdirectory of the source distribution). The
man pages describe the behaviour of the server: dhcpd and dhcpd.conf are
the main ones.
> Best regards,
> Alexandre Bezroutchko
> www.gremwell.com <http://www.gremwell.com>
--
regards,
-glenn
--
Glenn Satchell | Miss 9: What do you
Uniq Advances Pty Ltd, Sydney Australia | do at work Dad?
mailto:glenn.satchell at uniq.com.au | Miss 6: He just
http://www.uniq.com.au tel:0409-458-580 | types random stuff.
------------------------------
Message: 2
Date: Thu, 21 Oct 2010 14:43:32 +0200
From: Alexandre Bezroutchko <abb at scanit.be>
Subject: Re: security impact of accepting dhcp declines
To: Users of ISC DHCP <dhcp-users at lists.isc.org>
Message-ID:
<AANLkTinF1R3tBALj-yqQ_4CODkFi9d32H+Ox-WDxK5Jx at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Thank you for the clarification.
On Thu, Oct 21, 2010 at 2:18 PM, Glenn Satchell
<glenn.satchell at uniq.com.au> wrote:
>
> On 10/21/10 22:51, Alexandre Bezroutchko wrote:
>>
>> Hello,
>>
>> I wonder if somebody could clarify how DHCP server will behave when
>> somebody tries to exhaust its pool by abusing DHCPDECLINE messages. The
>> manpages for dhcpcd.conf says the following:
>>
>> ...
>> ? ? ? The declines keyword
>>
>> ? ? ? ?allow declines;
>> ? ? ? ?deny declines;
>> ? ? ? ?ignore declines;
>>
>> ? ? ? The DHCPDECLINE message is used by DHCP clients to ?indicate
>> ?that ?the
>> ? ? ? lease the server has offered is not valid. ? When the server
>> receives a
>> ? ? ? DHCPDECLINE ?for ?a ?particular ?address, ?it ?normally ?abandons
>> ?that
>> ? ? ? address, ?assuming that some unauthorized system is using it.
>> _Unfortu-
>> _ _nately, a malicious or buggy client can, ?using ?DHCPDECLINE ?messages,
>> _ _completely exhaust the DHCP server's allocation pool_. ? The server will
>> ? ? ? reclaim these leases, but while the client is running through the
>> pool,
>> ? ? ? it ?may ?cause serious thrashing in the DNS, and it will _also
>> cause the
>> _ _DHCP server to forget old DHCP client address allocations_.
>>
>> ? ? ? The declines flag tells the DHCP server whether or not to honor
>> DHCPDE-
>> ? ? ? CLINE messages. ? If it is set to deny or ignore in a particular
>> scope,
>> ? ? ? the DHCP server will not respond to DHCPDECLINE messages.
>> ...
>>
>> I don't get the part about trashing DNS. Does this refer to the case
>> when DNS updates are on?
>
> Yes. Each new request would result in a new DNS entry being added, then removed when it is declined. This only matters if the dhcp server is doing dynamic DNS updates.
>
>> And the statement about reclaiming these leases, but forgetting old DHCP
>> client allocations... Will DHCP server start throwing away existing
>> leases when the pool get exhausted?
>
> The DHCP server will offer all the current expired leases on a least-recently-used basis. Then it will start trying abandoned leases, and after that it will say "no more leases".
>
> As it offers each expired lease, it will re-write the lease entry with the client it was offered to and then as abandoned when it is declined, and in doing so will lose the information about which device had been last assigned that address. Part of RFC 2131 specifies that a DHCP server must remember the client it previously gave a lease to, so that it can offer them the same IP address if they ever come back again (provided that it is free of course).
>
>> Any input and/or reference to the official docs relevant to my question
>> are greatly appreciated.
>
> The DHCP RFCs contain the theory about how a DHCP server should operate (see the lists in the doc subdirectory of the source distribution). The man pages describe the behaviour of the server: dhcpd and dhcpd.conf are the main ones.
>
>> Best regards,
>> Alexandre Bezroutchko
>> www.gremwell.com <http://www.gremwell.com>
>
> --
> regards,
> -glenn
> --
> Glenn Satchell ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ?Miss 9: What do you
> Uniq Advances Pty Ltd, Sydney Australia ? | ?do at work Dad?
> mailto:glenn.satchell at uniq.com.au ? ? ? ? | ?Miss 6: He just
> http://www.uniq.com.au tel:0409-458-580 ? | ?types random stuff.
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
Message: 3
Date: Thu, 21 Oct 2010 13:53:27 +0100
From: Simon Hobson <dhcp1 at thehobsons.co.uk>
Subject: Re: dhcp for 2 subinterface
To: Users of ISC DHCP <dhcp-users at lists.isc.org>
Message-ID: <p06240826c8e5e76b4887 at simon.thehobsons.co.uk>
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Evans Lin ( ?-???? ) wrote:
>We use cisco ubr10k for cable service, and it's
>config 2 sub interface ( bundle1.1
>:10.10.20.1,bundle1.2 :10.106.0.1)
>dhcpd version 4.2.0 & CentOS 5.3
>we always saw the ip gw 10.10.20.1 bundle 1.1
>broadcast and then dhcp server offer 10.10.20.x
>...
>how can I do for some mac to get bundle1.2 ip address in dhcp server
Please learn to trim unrelated text from your messages !
As I understand your query, you have two subnets
on the same physical interface - so a client may
have an address in either of two subnets:
10.10.20.0 or 10.106.0.0
If this is the case, then what you need is a shared-network statement :
shared-network "some-text-identifier" {
<shared-network level options go here>
subnet 10.10.20.0 ...
<subnet level options go here>
...
}
subnet 10.106.0.0 ...
<subnet level options go here>
...
}
}
--
Simon Hobson
Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.
------------------------------
Message: 4
Date: Thu, 21 Oct 2010 16:19:02 -0700
From: Shawn Routhier <sar at isc.org>
Subject: ISC DHCP 4.1.2rc1 is now available
To: df-announce at isc.org, dhcp-announce at isc.org,
dhcp-workers at lists.isc.org, Users of ISC DHCP
<dhcp-users at lists.isc.org>
Message-ID: <4CC0CA66.6070404 at isc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
ISC DHCP 4.1.2rc1 is now available for download
This is the first release candidate of DHCP 4.1.2, a maintenance
release which contains a number of bug fixes.
The changes to accept but not require a semi-colon at the end
of the max-life and preferred-life clauses in a DHCPv6 lease file have
two side effects. The first is the generation of warning messages
when reading a lease file created from an older version of DHCP 4.1.
The second is previous versions of DHCP 4.1 will be unable to cleanly
parse a lease file created by DHCP 4.1.2. These effects are only
for lease files for DHCPv6 and do not affect DHCPv4 lease files.
A list of changes in this release has been appended to this message.
For a full list of changes since any historical version, please consult
the RELNOTES file in the software distribution or on our website:
http://www.isc.org/software/dhcp/412rc1
This release, and its OpenPGP-signatures are available now from:
ftp://ftp.isc.org/isc/dhcp/dhcp-4.1.2rc1.tar.gz
ftp://ftp.isc.org/isc/dhcp/dhcp-4.1.2rc1.tar.gz.sha512.asc
ftp://ftp.isc.org/isc/dhcp/dhcp-4.1.2rc1.tar.gz.sha256.asc
ftp://ftp.isc.org/isc/dhcp/dhcp-4.1.2rc1.tar.gz.sha1.asc
ISC's Release Signing Key can be obtained at:
http://www.isc.org/about/openpgp/
Changes since 4.1.2rc1
- Update the code to parse dhcpv6 lease files to accept a semi-colon at
the end of the max-life and preferred-life clauses. In order to be
backwards compatible with older lease files not finding a semi-colon
is also accepted. [ISC-Bugs #22303].
------------------------------
Message: 5
Date: Thu, 21 Oct 2010 17:19:27 -0700
From: "David W. Hankins" <dhankins at isc.org>
Subject: ISC DHCP 4.0.3rc1 is now available!
To: df-announce at isc.org, dhcp-announce at isc.org,
dhcp-workers at lists.isc.org, dhcp-users at lists.isc.org
Message-ID: <20101022001927.GL5534 at isc.org>
Content-Type: text/plain; charset="us-ascii"
ISC DHCP 4.0.3rc1 is now available for download.
This is the FIRST RELEASE CANDIDATE of ISC DHCP 4.0.3, a maintenance
release which fixes bugs present in versions 4.0.2 and prior.
There have been no changes in this release since the previous release,
4.0.3b1. For a complete list of changes from any previous release,
please consult the RELNOTES file within the source distribution, or
on our website:
http://www.isc.org/software/dhcp/403rc1
This release, and its OpenPGP-signatures are available now from:
ftp://ftp.isc.org/isc/dhcp/dhcp-4.0.3rc1.tar.gz
ftp://ftp.isc.org/isc/dhcp/dhcp-4.0.3rc1.tar.gz.sha512.asc
ftp://ftp.isc.org/isc/dhcp/dhcp-4.0.3rc1.tar.gz.sha256.asc
ftp://ftp.isc.org/isc/dhcp/dhcp-4.0.3rc1.tar.gz.sha1.asc
ISC's Release Signing Key can be obtained at:
http://www.isc.org/about/openpgp/
Changes since 4.0.3b1
- None.
--
David W. Hankins "If you don't do it right the first time,
Software Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20101021/7aa4ae2d/attachment-0001.bin>
------------------------------
_______________________________________________
dhcp-users mailing list
dhcp-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
End of dhcp-users Digest, Vol 24, Issue 27
******************************************
未在傳入訊息中找到病毒。
已透過 AVG 檢查 - www.avg.com
版本: 8.5.448 / 病毒庫: 271.1.1/3209 - 發佈日期: 10/21/10 18:34:00
DISCLAIMER:
Sample Disclaimer added in a VBScript.
More information about the dhcp-users
mailing list