ddns-update-style ad-hoc;
max-lease-time 3600;
default-lease-time 3600;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.0.255;
option routers 192.168.0.1;
option domain-name-servers 192.168.0.1;
option domain-name "home.net.cn";
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.80 192.168.0.100;
}
上面是我的/etc/dhcpd.conf
现在所有被分配的及其，IP地址都是从100倒着分配，100、99、98，这样，不知道为什么
有没有办法分配80、81、82这样
（注释，80这个地址可能被占用，DHCP分配的时候会不会发现80地址存在而从后向前分配？）
| leaper 回复于：2004-07-22 18:09:05 | ||||||||||||||||||
| 这种现像倒没碰到过 我碰到大都是从中取出一个，并非是从最大的开始。 我想可能跟版本在内核处理上的问题吧。 | ||||||||||||||||||
| llzqq 回复于：2004-07-22 18:34:03 | ||||||||||||||||||
| 应该是从高到低分配的，我的也一样，好象不能改变。 | ||||||||||||||||||
| yunqing 回复于：2004-07-23 05:26:19 | ||||||||||||||||||
| 有什么区别吗，如果必要把MAC地址绑定就是了。 | ||||||||||||||||||
| simtiger 回复于：2004-07-24 12:48:02 | ||||||||||||||||||
| "...80这个地址可能被占用，DHCP分配的时候会不会发现80地址存在..." 会的。按照DHCP 的RFC建议，C/S都会探测 1)DHCP Server在分配每个地址之前都会探测这个地址的存在（一般用PING），如果存在，就会在地址池中按照策略选择另一个IP。不过在某些DHCP服务器上，这个是可选项，默认是打开的。 2)DHCP Client在使用这个IP之前也会探测这个地址的存在(一般用ARP)，如果发现地址已经被使用，就会向服务器报告，服务器会另选一个IP分配，并标记这个问题IP。 | ||||||||||||||||||
| rayz 回复于：2004-07-24 19:15:45 | ||||||||||||||||||
| 说道DHCP我碰到一个问题特让我郁闷 cisco 3550 switch 因为下面有lan switch所以用linux 作DHCP server，计划慢慢收集mac做绑定。 设置完成后正好是周末，测试通过就回家了 周一一上班，n电话过来说不能上网了, 跑去一看，所有的client都无法获得ip. 而我自己的已经在dhcpd.conf上绑定了，就获得了ip 后来发现所有ip必须绑定否则会提示连接dhcp server timed out 导线在也没高明白，dhcp广播的，干吗非要制定ip才能起作用 不过anyway绑定ip可以用... | ||||||||||||||||||
| platinum 回复于：2004-07-24 20:26:06 | ||||||||||||||||||
| windows的DHCP服务是从小地址开始分配 ADSL猫如果开启了DHCP服务，也是从小地址开始分配 原来用的RH73忘记是如何的了，现在用的是AS3，却是从大地址开始分配 这方面的资料网上也没有找到…… | ||||||||||||||||||
| Linux@初学者 回复于：2004-07-24 20:44:46 | ||||||||||||||||||
| 我上RHCE时老师说过：LINUX的DHCP分配顺序就是倒着来的！和WNI的相反！ | ||||||||||||||||||
| platinum 回复于：2004-07-24 20:54:38 | ||||||||||||||||||
| 哈，看来培训过和没参加过培训，就是不一样啊：） | ||||||||||||||||||
| Linux@初学者 回复于：2004-07-24 20:56:15 | ||||||||||||||||||
| 不行不行，我很菜，只是会P毛呀！ | ||||||||||||||||||
| leaper 回复于：2004-07-24 20:58:37 | ||||||||||||||||||
| 看来交钱还是有东西学的 | ||||||||||||||||||
| 網中人 回复于：2004-07-24 23:04:06 | ||||||||||||||||||
| [quote:14166027d1="simtiger"]"...80这个地址可能被占用，DHCP分配的时候会不会发现80地址存在..." 会的。按照DHCP 的RFC建议，C/S都会探测 1)DHCP Server在分配每个地址之前都会探测这个地址的存在（一般用PING），如果存在，就会在地址池中..........[/quote:14166027d1] 能請問是哪份 RFC 嗎? 我倒是第一次聽到過這個說法... | ||||||||||||||||||
| LEOD 回复于：2004-07-25 02:33:51 | ||||||||||||||||||
| linux是倒着分配的！ 但我也不知道为什么这样子！ 有谁知道吗！？ | ||||||||||||||||||
| fushuyong 回复于：2004-07-25 07:22:44 | ||||||||||||||||||
| 呵呵，写程序的时候，策略是倒着分配，它就会倒着分配咯，呵呵。说老实话，我不喜欢DHCP。不是万不得以，偶不爱用它。 | ||||||||||||||||||
| simtiger 回复于：2004-07-25 19:58:42 | ||||||||||||||||||
| [quote:5aa9e7cb70="網中人"] 能請問是哪份 RFC 嗎? 我倒是第一次聽到過這個說法...[/quote:5aa9e7cb70] RFC2131/2132 以前做DHCP SERVER时研究过相关RFC，所以记得比较清楚。 | ||||||||||||||||||
| 網中人 回复于：2004-07-25 20:17:03 | ||||||||||||||||||
| 大哥能貼一下是哪一 section 嗎? 小弟看完兩篇, 找不到你提到的 ping 與 arp ... 在 rfc-2131 之 4.3.1 DHCPDISCOVER message , 只提到如下: [code:1:bf6d2c63d3]The server must also choose an expiration time for the lease, as follows: IF the client has not requested a specific lease in the DHCPDISCOVER message and the client already has an assigned network address, the server returns the lease expiration time previously assigned to that address (note that the client must explicitly request a specific lease to extend the expiration time on a previously assigned address), ELSE IF the client has not requested a specific lease in the DHCPDISCOVER message and the client does not have an assigned network address, the server assigns a locally configured default lease time, ELSE IF the client has requested a specific lease in the DHCPDISCOVER message (regardless of whether the client has an assigned network address), the server may choose either to return the requested lease (if the lease is acceptable to local policy) or select another lease. ...[skiped] Once the network address and lease have been determined, the server constructs a DHCPOFFER message with the offered configuration parameters. It is important for all DHCP servers to return the same parameters (with the possible exception of a newly allocated network address) to ensure predictable client behavior regardless of which server the client selects. The configuration parameters MUST be selected by applying the following rules in the order given below. The network administrator is responsible for configuring multiple DHCP servers to ensure uniform responses from those servers. The server MUST return to the client: The client's network address, as determined by the rules given earlier in this section, The expiration time for the client's lease, as determined by the rules given earlier in this section, Parameters requested by the client, according to the following rules: IF the server has been explicitly configured with a default value for the parameter, the server MUST include that value in an appropriate option in the 'option' field, ELSE IF the server recognizes the parameter as a parameter defined in the Host Requirements Document, the server MUST include the default value for that parameter as given in the Host Requirements Document in an appropriate option in the 'option' field, ELSE The server MUST NOT return a value for that parameter, The server MUST supply as many of the requested parameters as possible and MUST omit any parameters it cannot provide. The server MUST include each requested parameter only once unless explicitly allowed in the DHCP Options and BOOTP Vendor Extensions document. Any parameters from the existing binding that differ from the Host Requirements Document defaults, Any parameters specific to this client (as identified by the contents of 'chaddr' or 'client identifier' in the DHCPDISCOVER or DHCPREQUEST message), e.g., as configured by the network administrator, Any parameters specific to this client's class (as identified by the contents of the 'vendor class identifier' option in the DHCPDISCOVER or DHCPREQUEST message), e.g., as configured by the network administrator; the parameters MUST be identified by an exact match between the client's vendor class identifiers and the client's classes identified in the server, Parameters with non-default values on the client's subnet. [/code:1:bf6d2c63d3] 同樣的, 在 4.4.1 Initialization and allocation of network address 一節也沒提到... | ||||||||||||||||||
| simtiger 回复于：2004-07-25 22:24:05 | ||||||||||||||||||
| 现在手中没有RFC文档 不过分配IP不是在DHCPDISCOVER 阶段，你可以认真通读整个RFC文档，我记得应该是这样的 | ||||||||||||||||||
| platinum 回复于：2004-07-25 22:30:26 | ||||||||||||||||||
| 只是个讨论，网中人何必计较那么多，simtiger也是好意 网兄，呵呵，你的脾气好像和以前比变化很大哦～ | ||||||||||||||||||
| gentoo 回复于：2004-07-26 08:30:04 | ||||||||||||||||||
| 同意“网”的看法，很想知道依据。学问不要含糊，对事不对人。 | ||||||||||||||||||
| simtiger 回复于：2004-07-26 13:42:59 | ||||||||||||||||||
| Well,中午查了查RFC2131，上面写得很清楚嘛 2.2 Dynamic allocation of network addresses ... As a consistency check, the allocating server SHOULD probe the reused address before allocating the address, e.g., with an ICMP echo request, and the client SHOULD probe the newly received address, e.g., with ARP. ... 3.1 Client-server interaction - allocating a network address ... When allocating a new address, servers SHOULD check that the offered network address is not already in use; e.g., the server may probe the offered address with an ICMP Echo Request. ... The client SHOULD perform a final check on the parameters (e.g., ARP for allocated network address), and notes the duration of the lease specified in the DHCPACK message. At this point, the client is configured. If the client detects that the address is already in use (e.g., through the use of ARP), the client MUST send a DHCPDECLINE message to the server and restarts the configuration process. ... 认认真真读文档是必要的... | ||||||||||||||||||
| q1208c 回复于：2004-07-26 14:43:29 | ||||||||||||||||||
| 按照楼上兄弟的意思，dhcp 和静态地址是不会冲突的了。可为什么在实际中会有是冲突呢？ | ||||||||||||||||||
| simtiger 回复于：2004-07-26 15:46:16 | ||||||||||||||||||
| 实际情况很复杂的 呵呵，我所说的只是RFC建议上的... | ||||||||||||||||||
| simtiger 回复于：2004-07-26 15:47:12 | ||||||||||||||||||
| 当然还要考虑DHCP Server/Client是否完全符合RFC建议 | ||||||||||||||||||
| 網中人 回复于：2004-07-27 02:08:54 | ||||||||||||||||||
| [quote:20eef2a3a1="platinum"]只是个讨论，网中人何必计较那么多，simtiger也是好意 网兄，呵呵，你的脾气好像和以前比变化很大哦～[/quote:20eef2a3a1] 多謝版主! 不知小弟的脾氣是變好了還是變壞了呢? ^_^ 做學問, 就是要一絲不苟, 不懂就虛心請問. 小弟毫無挑戰權威之意, 只是覺得不解, 特來請教. 若引起誤會, 那我先賠個不是! 至於實作上與 RFC 的出入, 等我有空用 sniffer 來抓抓 isc dhcpd 與 windows client 的封包, 再回來跟大家報告... ^_^ | ||||||||||||||||||
| 網中人 回复于：2004-07-27 02:34:48 | ||||||||||||||||||
| 此外, 推薦一個不錯的 RFC 閱讀站台: http://www.rfc-archive.org 與 DHCP 相關的 RFC 大概有: RFC-951﹑RFC-1084﹑RFC-1123﹑RFC-1533﹑RFC-1534﹑RFC-1497﹑RFC-1541﹑RFC-2131﹑RFC-2132 前面提到的兩篇如下: http://www.rfc-archive.org/getrfc.php?rfc=2131 http://www.rfc-archive.org/getrfc.php?rfc=2132 | ||||||||||||||||||
| 網中人 回复于：2004-07-27 02:40:18 | ||||||||||||||||||
| 找到了: 在 RFC-2131 之 2.2 section (Page 11) 最後一段: [code:1:fd7d1bc5c2]2.2 Dynamic allocation of network addresses The second service provided by DHCP is the allocation of temporary or permanent network (IP) addresses to clients. The basic mechanism for the dynamic allocation of network addresses is simple: a client requests the use of an address for some period of time. The allocation mechanism (the collection of DHCP servers) guarantees not to reallocate that address within the requested time and attempts to return the same network address each time the client requests an address. In this document, the period over which a network address is allocated to a client is referred to as a "lease" [11]. The client may extend its lease with subsequent requests. The client may issue a message to release the address back to the server when the client no longer needs the address. The client may ask for a permanent assignment by asking for an infinite lease. Even when assigning "permanent" addresses, a server may choose to give out lengthy but non-infinite leases to allow detection of the fact that the client has been retired. In some environments it will be necessary to reassign network addresses due to exhaustion of available addresses. In such environments, the allocation mechanism will reuse addresses whose lease has expired. The server should use whatever information is available in the configuration information repository to choose an address to reuse. For example, the server may choose the least recently assigned address. As a consistency check, the allocating server SHOULD probe the reused address before allocating the address, e.g., with an ICMP echo request, and the client SHOULD probe the newly received address, e.g., with ARP.[/code:1:fd7d1bc5c2] 至於實作上是否如此, 等我有空抓封包看看... ^_^ | ||||||||||||||||||
| simtiger 回复于：2004-07-27 12:23:14 | ||||||||||||||||||
| 至少NT4的DHCP Client/Server是这样做的，我用sniffer抓包验证过的。 | ||||||||||||||||||
| 網中人 回复于：2004-07-27 16:27:32 | ||||||||||||||||||
| 我用 redhat 9 的 dhcpd 3.0pl1-23 版作 server, Windows XP(home) 作 client . 抓到的 packet 看來, server 與 client 都會送 ARP , 見附圖. 測試環境中, 我起動了兩台 dhcp server , 因此當 DISCOVER 送出後, 看到兩個 ARP (綠線框部份) 然後看到有兩個 OFFER (紅線框部份) 接下來只送一個 REQUEST (藍色選擇部份), 且看出 request 的是第二個 OFFER (底下的藍線框部份). 最後, 在 ACK 之後, client 還會送 ARP . 不過, 我故意在另一台 linux 主機器設了一個相同的 IP , 可是, client 似乎還是用到相衝的 IP ... 我猜是 arp table 還有 ttl 的關係, 不過, 這部份還要時間 trace 下去. 今天恐怕沒時間了... 等下次有空, 再來試吧.... ^_^
| ||||||||||||||||||
javascript:window.open(this.src);" style="CURSOR: pointer" onload="return imgzoom(this,550)">