Dhcp学习笔记

Dhcp学习笔记一：udp端口使用问题

B O O T P有两个熟知端口： BOOTP  服务器为6 7，BOOTP  客户为6 8。这意味着BOOTP  客户不会选择未用的临时端口，而只用端口 6 8。选择两个端口而不是仅选择一个端口为 B O O T P服务器用的原因是：服务器的应答可以进行广播（但通常是不用广播的）。

如果服务器的应答是通过广播传送的，同时客户又选择未用的临时端口，那么这些广播

也能被其他的主机中碰巧使用相同临时端口的应用进程接收到。因此，采用随机端口（即临

时端口）对广播来说是一个不好的选择。

如果客户也使用服务器的知名端口（ 6 7）作为它的端口，那么网络内的所有服务器会被唤醒来查看每个广播应答（如果所有的服务器都被唤醒，它们将检查操作码，如果是一个应答而不是请求，就不作处理）。因此可以让所有的客户使用与服务器知名端口不同的同一知名端口。

如果多个客户同时进行系统引导，并且服务器广播所有应答，这样每个客户都会收到其

他客户的应答。客户可以通过 B O O T P首部中的事务标识字段来确认应答是否与请求匹配，或者可以通过检查返回的客户硬件地址加以区分。

Dhcp学习笔记二：客户端获得地址先还是服务器知道客户地址先？

这里出现了一个有趣的问题： TFTP  服务器如何能将一个响应直接送回 BOOTP  客户？这个响应是一个 U D P数据报，而服务器知道该客户的 I P地址（可能通过读取服务器上的配置文件）。但如果这个客户向那个 I P地址发送一个 U D P数据报（正常情况下会处理 U D P的输出），BOOTP  服务器的主机就可能向那个 I P地址发送一个A R P请求。但这个客户不能响应这个 A R P请求，因为它还不知道它自己的 I P地址！（这就是在R F C 9 5 1中被称作“鸡和蛋”的问题。）

有两种解决办法：第一种，通常被 Unix  服务器采用，是服务器发一个 i o c t l ( 2 )请求给内核，为该客户在 A R P高速缓存中设置一个条目（这就是命令 a r p - s所做的工作，见 4 . 8节）。服务器能一直这么做直到它知道客户的硬件地址和 I P地址。这意味着当服务器发送 U D P数据报（即B O O T P应答）时，服务器的 A R P将在ARP  高速缓存中找到该客户的 I P地址。

另一种可选的解决办法是服务器广播这个 B O O T P应答而不直接将应答发回该客户。既然通常期望网络广播越少越好，因此这种解决方案应该只在服务器无法在它的 ARP  高速缓存设置一个条目的情况下使用。通常只有拥有超级用户权限才能在 A R P高速缓存设置一个条目，如果没有这种权限就只能广播 B O O T P应答。

Dhcp学习笔记三：跳数字段的问题

当收到一个 B O O T P请求时，中继代理将它的 I P地址填入收到B O O T P请求中的“网关 I P地址字段”，然后将该请求发送到真正的 B O O T P服务器（由中继代理填入网关字段的地址是收到的 B O O T P请求接口的 I P地址）。该代理中继还将跳数字段值加 1

（这是为防止请求被无限地在网络内转发。 RFC 951认为如果跳数值到达 3就可以丢弃该请求）。既然发出的请求是一个单播的数据报（与发起的客户的请求是广播的相反），它能按照一定的路由通过其他的路由器到达真正的 B O O T P服务器。真正的B O O T P服务器收到这个请求后，产生B O O T P应答，并将它发回中继代理，而不是请求的客户。既然请求网关字段不为零，真正的B O O T P服务器知道这个请求是经过转发的。中继代理收到应答后将它发给请求的客户。

Dhcp学习笔记四：bootp与dhcp的区别

这里有两个重要的区别在DHCP和BOOTP上,第一，DHCP定义了一种可以在固定地租约时间内分配给客户端网络地址地机制，允许连续地重分配网络地址给不同地客户端。第二，DHCP提供一种一个客户端能够取得所有的IP配置需要的变量供其操作的机制。

DHCP定义了一个新的选项“client indentifier”，用于传递一个明确的客户端识别信息给DHCP服务器。这个改变消除了原来在BOOTP消息的chaddr字段的多义性，因为以前该字段既被认为一个硬件地址而且也是用户识别信息。这个client indentifier选项也许包含了与chaddr字段内容完全一样的硬件地址，或者是包含了另外一种识别类型比如DNS名称。其他的客户机识别类型也许被定义为需要使用DHCP。新的客户识别类型将注册到IANA，也会包含在一个新的Assigned Number文档的校订版中，这个在DHCP选项的未来校订版中会详细地描述。

Dhcp学习笔记五：linux上dhcp服务器配置文件的问题

Dhcpd.conf文件中类的匹配：

按mac地址匹配时，匹配mac地址的第1-3字节00-0c-29

Class “vm”{

Match if substring(hardware,1,3)-00:0c:29;

}

若是按照供应商来匹配：

Class “microsoft-client” {

Match if substring (option vendor-class-identifier)=”MSFT”;

}

Dhcp学习笔记六：dhcp服务器对dhcp报文的处理

处理客户端发送来的DHCP报文DHCP服务器可以接收五种DHCP报文：DHCP-DISCOVER、DHCP-REQUEST、DHCP-DECLINE、DHCP-RELEASE和DHCP-INFORM报文。 

    对每一种报文的处理如下。

   (1) DHCP-DISCOVER 

DHCP服务器首先检查地址池是否有可分配的地址，如果没有，则不会响应客户端的申请，并向系统管理员报告;如果有，挑选合适的IP地址，选定IP地址之后，DHCP服务器会根据选定的IP地址来决定用户的绑定租约，

并处理客户端请求的其它网络参数(在服务器上已经进行了其它参数的配置)。

    在确定了以上信息后，服务器将向客户端发送回应的DHCP-OFFER报文。

   (2) DHCP-REQUEST

DHCP-REQUEST报文可能在下面三种情况下产生：.. 客户端响应服务器的 DHCP-OFFER;.. 客户端确认一个先前分配的 IP 地址;.. 客户端请求延长某个网络地址的租约。

  如果DHCP-REQUEST报文中包含Option 54(server identifier option，服务器标识符选项)，则说明此DHCP-REQUEST报文是客户端响应服务器的DHCPOFFER报文的;否则是后两种情况。

   DHCP服务器根据收到的REQUEST报文的类型进行不同的处理，若可以分配合法的IP地址，则回应客户端

一个DHCP-ACK报文。

   (3) DHCP-DECLINE如果客户端通过地址冲突检测发现服务器分配的IP地址冲突或由于其它原因导致不能使用，则发送DHCP-DECLINE报文。

    服务器收到此报文后会将该IP地址标记为不可用(not available)。

   (4) DHCP-RELEASE当用户不再需要使用分配的IP地址时，就会主动向DHCP服务器发送DHCPRELEASE报

文，告知服务器，用户不再需要分配的IP地址。

    服务器收到该报文后会将客户端发送的需要释放的网络地址标记为不可用，同时保持这个客户端的初始化参

数，以便将来的重用(reuse)。

   (5) DHCP-INFORM客户端向服务器发送DHCP-INFORM报文用于请求更多的网络配置信息，包括DNS、缺

省网关等详细配置信息。

   （6）DHCP-ACK:为客户端处理延长租期的请求DHCP客户端在分配租约使用一半时间后，会主动向DHCP服务器申请继续使用该IP地址，服务器对客户端的续约请求进行处理，若发现请求的IP地址可用，则回应DHCP-ACK报文给客户端，告知可以继续使用该IP地址，并更新相应的租约和定时器信息。

   （7）设定或释放保留地址保留地址是DHCP协议的IP地址池中不分配的地址段。

    一旦设定为保留地址后，这个区间内的IP地址就不再参加整个IP地址池的分配而保留起来，将保留地址的起始地址和结束地址记录到该IP地址池的参数中。

   （8） 探测分配IP地址的活动情况在DHCP服务器向客户端分配IP地址时，服务器首先需要确认所分配的IP没有被网络上的其他设备所使用，这就需要服务器发送ICMP(ping)的数据包来对所分配的IP进行探测。服务器对需要探测的IP地址发送ping数据包，如果在规定的时间内没有应答(默认情况下是500ms)，那么服务器就会再次发送ping数据包。到达规定的次数(默认情况下是2次)后，如果仍没有应答，则所分配的IP地址可用。否则系统将向管理员报告出错信息。探测IP地址不影响服务器对其它客户端的响应。

   （9） 配置相关网络参数以告知客户端DHCP服务器可以配置以下网络参数并通过交互报文告知客户端：.. 配置客户端网关地址;.. 配置客户端使用的 DNS 服务器;.. 配置客户端网络使用的域名后缀;.. 配置客户端的 WINS 服务器IP 地址;.. 配置客户端所对应的 NetBIOS 节点类型。

Dhcp学习笔记七：RFC3046一些重要的话

以下内容均是摘自RFC3046：

1、 所有增加的 DHCP 中继代理选项应当是可配置的，且默认值是 disable 的。中继代理应当可以对每个子选项单独配置，以便于控制在客户-到-服务包中插入的位置。

2、 中继代理从一个不受信任的电路接收到一个 giaddr 设置为 0 的（指定它是路由的第一跳）DHCP 包，但包中却已包含中继代理信息选项，应丢弃该包并增加错误计数。

3、 添加代理信息选项后，中继代理可以对创建的 DHCP 包的最大尺寸进行配置。在添加代理信息选项后，其大小超过该最大尺寸配置的包将直接转发而不添加代理信息选项。这种情况下，应当增加错误计数。这种可配置性缺乏时，代理增加转发的 DHCP 包的大小不应超过转发接口的 MTU 值。

4、 代理不应当在包中增加“选项过载”选项或使用“file”或“sname”字段增加中继代理信息选项。同时，也不应当解析或删除 sname 或 file 字段中的中继代理选项， sname 或 file 字段位于通过代理转发的服务器-到-客户包中。

5、 中继代理配置为接收到非 0 giaddr 的客户 DHCP 包也添加中继代理选项时，则中继代理应当丢弃包，如果该包由本地代理自己使用 giaddr 地址进行欺骗。否则，中继代理应当转发任何接收到的有效的非 0 giaddr 的 DHCP 包，而不添加任何中继代理选项。根据 RFC 2131, 它也不修改 giaddr 值。

6、 DHCP 服务器所不能识别的中继代理信息选项在接收时将被忽略，且也不返回响应。这是服务器对不能识别选项的处理方式。

Dhcp学习笔记八：测试DHCP时遇到的一些问题以及经验

1、linux实现DHCP服务器时作用域必须有一个与其自身网段对应的，可以创建一个空作用域。否则会提示出错“没有为eth0配置子网”！切记！

2、记得上次实验时用的是超级作用域，但是采用独立作用域时试过不可以！

3、DHCP服务器获取包后，提取该包的网关域的ip网段，并与地址作用域的网段做配对，配对上了就是该作用域，回复给客户端一个在相同网段的IP！

4、三层交换技术也称为IP交换技术，是一种利用三层协议中的信息来加强第二层交换功能的机制。三层交换技术具有路由的基本特征。数据报文转发是路由器和三层交换机最基本的功能。路由器具有配置复杂、价格高、吞吐量相对较低和吞吐量变化相对较高等缺点。三层交换技术在很大程度上弥补了路由器的这些缺点。

5、DHCP服务器向DHCP客户机出租的IP地址一般都有一个租借期限，当租约过了一半时，客户机将和设置它的TCP/IP配置的DHCP更新租约。当租期过了87.5%时，如果客户机仍然无法与当初的DHCP联系上，该客户机必须停止使用该IP地址，并从发送一个dhcpdiscover数据包开始，再一次重复整个过程。

6、三层交换的工作原理 

假设两个使用IP协议的站点A、B通过三层交换机进行通信，发送站点A在开始发送时，把自己的IP地址与B站的IP地址比较，判断B站是否与自己在同一子网内。若目的站B与发送站A在同一子网内，则进行二层的转发。若两个站点不在同一子网内，如发送站A要与目的站B通信，发送站A要向“缺省网关”发出地址解析封包，而“缺省网关”的IP地址其实是三层交换机的三层交换模块。当发送站A对“缺省网关”的IP地址广播出一个ARP请求时，如果三层交换模块在以前的通信过程中已经知道B站的MAC地址，则向发送站A回复B的MAC地址。否则三层交换模块根据路由信息向B站广播一个ARP请求，B站得到此ARP请求后向三层交换模块回复其MAC地址，三层交换模块保存此地址并回复给发送站A,同时将B站的MAC地址发送到二层交换引擎的MAC地址表中。从这以后，从A向B发送的数据包便全部交给二层交换处理，信息得以高速交换。

7、DHCP中继技术分析：

通过启动每个VLAN及三层交换机中相关端口的DHCP中继功能，VLAN的接口地址（默认网关）收到该VLAN中客户机发出的DHCP请求广播信息后，由该默认网关充当DHCP代理的角色将请求信息转发给DHCP服务器。在DHCP中继中，每个VLAN的接口地址都作为该VLAN的DHCP代理。利用DHCP中继功能只需要在网络中设置一台DHCP服务器即可，并且DHCP服务器可以位于任何一个VLAN中，只需要在设置DHCP中继参数的时候，指定DHCP服务器的地址就可以了。

!!!!!

// RFC 1542

// 4.1 General BOOTP Processing for Relay Agents

// 4.1.1 BOOTREQUEST Messages

//   If the relay agent does decide to relay the request, it MUST examine

//   the 'giaddr' ("gateway" IP address) field.  If this field is zero,

//   the relay agent MUST fill this field with the IP address of the

//   interface on which the request was received.  If the interface has

//   more than one IP address logically associated with it, the relay

//   agent SHOULD choose one IP address associated with that interface and

//   use it consistently for all BOOTP messages it relays.  If the

//   'giaddr' field contains some non-zero value, the 'giaddr' field MUST

//   NOT be modified.  The relay agent MUST NOT, under any circumstances,

//   fill the 'giaddr' field with a broadcast address as is suggested in

//   [1] (Section 8, sixth paragraph).

// but why? what if server can't route such IP? Client ifaces may be, say, NATed!

// 4.1.2 BOOTREPLY Messages

//   BOOTP relay agents relay BOOTREPLY messages only to BOOTP clients.

//   It is the responsibility of BOOTP servers to send BOOTREPLY messages

//   directly to the relay agent identified in the 'giaddr' field.

// (yeah right, unless it is impossible... see comment above)

//   Therefore, a relay agent may assume that all BOOTREPLY messages it

//   receives are intended for BOOTP clients on its directly-connected

//   networks.

//

//   When a relay agent receives a BOOTREPLY message, it should examine

//   the BOOTP 'giaddr', 'yiaddr', 'chaddr', 'htype', and 'hlen' fields.

//   These fields should provide adequate information for the relay agent

//   to deliver the BOOTREPLY message to the client.

//

//   The 'giaddr' field can be used to identify the logical interface from

//   which the reply must be sent (i.e., the host or router interface

//   connected to the same network as the BOOTP client).  If the content

//   of the 'giaddr' field does not match one of the relay agent's

//   directly-connected logical interfaces, the BOOTREPLY messsage MUST be

//   silently discarded.