DHCP规范和现网案例分析

DHCP规范和现网案例分析陈曦2012年6月1本次课题DHCP简介中国电信DHCP扩展规范现网DHCP案例分析2DHCP简介协议概述报文格式报文类型常用optionDHCP报文交互过程DHCP客户端更新租约DHCPclient状态机DHCP中继工作过程处理DHCP中继报文3协议概述DHCP动态主机配置协议(DynamicHostConfigurationProtocol)为网络客户机分配动态的IP地址提供安全、可靠的TCP/IP网络配置保证IP地址不发生冲突，减少了在TCP/IP网络上增添、移动和配置计算机的管理负担，使IP地址管理自动化。动态分配IP地址在某些情况下还可以解决IP不够用的问题。4报文格式OP(1)Htype(1)Hlen(1)Hops(1)TransactionID(4)Seconds(2)Flags(2)Ciaddr（4）Yiaddr（4）Siaddr（4）Giaddr（4）Chaddr（16）Sname（64）File（128）Options（variable）5报文字段含义最左边的bit位,0代表广播,1代表单播。其余bit尚未使用flags由DHCPClient填充，从DHCPClient开始获得地址或地址续借后所使用了的秒数。Seconds由DHCPClient选择的一个随机数，被DHCPServer和DHCPClient用来在它们之间交流messages和responses。由客户设置并由DHCPServer返回的32bit整数。客户用它对请求和应答进行匹配。TransactionIDDHCPClient设置为0，也能被一个代理服务器设置hopshardwareaddresslength，6字节。hlenhardwareaddresstype，1表示以太网，这和ARP请求或应答中同名字段表示的含义相同。htypemessageopcode/messagetype“1“代表BOOTREQUEST”2“代表BOOTREPLYop含义字段6报文字段含义(续)包含报文的类型、有效租期、DNS（DomainNameSystem，域名系统）服务器的IP地址等配置信息,RFC2132中介绍了全部的option的定义optionsBootfilename，是一个空值终止串。DISCOVER中是“generic”名字或空字符,OFFER提供有效的目录路径全名。file“服务器主机名”字段是一个空值终止串，由服务器填写。snameClienthardwareaddresschaddrDHCPRelay代理的IP地址。giaddrbootstrap中，下一个Server的IP地址。siaddr‘your’（Client）IPaddressyiaddrClientIPaddress，只有DHCPClient已经获得IP地址，并且能响应ARPrequests时，才能被填充。ciaddr含义字段7报文类型报文类型主要功能DHCP-DISCOVERDHCP客户端广播发送的，用来查找网络中可用的DHCP服务器DHCP-OFFERDHCP服务器用来响应客户端的DHCP-DISCOVER请求，并为客户端指定相应配置参数DHCP-REQUESTDHCP客户端广播发送给DHCP服务器，用来请求配置参数或者续借租期DHCP-ACKDHCP服务器通知客户端可以使用分配的IP地址和配置参数DHCP-NAKDHCP服务器通知客户端地址请求不正确或者租期已过期DHCP-RELEASEDHCP客户端主动向DHCP服务器发送，告知服务器该客户端不再需要分配的IP地址DHCP-DECLINEDHCP客户端发现地址冲突或由于其它原因导致地址不能使用，则发送DHCP-DECLINE报文，通知服务器所分配的IP地址不可用DHCP-INFORMDHCP客户端已经有IP地址，用它来向服务器请求其他的配置参数8常用optionOptionNameDescription1SubnetmaskSpecifiessubnetmaskfortheclient3GatewaysAlistofrouters,inpreferentialorder,fortheclienttouse.6DomainNameserversAlistofDomainNameserversinpreferentialorder.ADomainNameserverenablestheclienttolocateothercomputersonthenetworkbyname.50RequestedIPAddressThisoptionisusedinaclientrequest(DHCP-DISCOVER)toallowtheclienttorequestthataparticularIPaddressbeassigned.53DHCPMessageTypeUsedtoconveythetypeoftheDHCPmessage.55ParameterRequestListUsedbyaDHCPclienttorequestvaluesforspecifiedconfigurationparameters.60VendorclassidentifierUsedbyDHCPclientstooptionallyidentifythetypeandconfigurationofDHCPclient.82DHCPRelayAgentInformationOptionTheoptionisinsertedbytheDHCPrelayagentwhenforwardingclient-originatedDHCPpacketstoaDHCPserver,itincludea"circuitID"anda"remoteID".125Vendor-IdentifyingVendorOptionsDHCPclientsandserversmayusethisoptiontoexchangevendor-specificinformation.Eitherpartymaysendthisoption,asneeded.9DHCP报文交互过程10DHCP客户端更新租约

DHCP服务器分配给客户端的IP地址有一定的租借期限，当租借期满后服务器会收回该IP地址。为了延长DHCP客户端使用该地址的期限，需要更新IP地址租约。11DHCP客户端更新租约包交互12DHCPclient状态机13DHCP中继工作过程

由于DHCP请求报文采用广播方式发送报文，因此当DHCP客户端和DHCP服务器处于不同子网时，必须要通过DHCP中继进行通信，最终获取到IP地址。这样，多个网络上的DHCP客户端可以使用同一个DHCP服务器，既节省了成本，又便于进行集中管理。14处理DHCP中继报文

DHCP中继代理收到DHCP报文后首先识别该报文，再进行相应处理。如果DHCP报文的UDP目的端口号为67，且BOOTP报文头中的“op”字段是BOOTREQUEST（1），即表示该报文是DHCP客户机发给服务器的请求报文。DHCP中继代理会检查报文的“giaddr”字段，如果其值为0.0.0.0，则DHCP中继代理设备用接受该报文的接口的IP地址填充此字段后，发送报文到指定的DHCP服务器组内的所有DHCP服务器。如果DHCP报文的UDP目的端口号为67，且BOOTP报文头中的“op”字段是BOOTREPLY（2），即表示该报文是DHCP服务器希望通过中继代理转发给DHCP客户端的回应报文。DHCP中继代理会将该报文从“giaddr”字段所属的接口发送到指定的DHCP客户端。15中国电信DHCP扩展规范发送discover报文的时间间隔续租机制终端ARP探测流程(福建电信地方规范)Option60扩展Option125扩展16发送discover报文的时间间隔如第一次DHCP的请求，未收到来自DHCP服务器的响应后，需按照协议栈的要求在第4秒、第8秒、第16秒、第32秒、第64秒、第124秒、第184秒…第304秒分别发起地址请求，且每次只发送一个请求报文。如第３０４秒仍未收到ＤＨＣＰ服务器响应，则重启ＤＨＣＰ会话，重复上述过程。其中福建电信要求：secondselapse字段需记录本次ＤＨＣＰ流程中所发送ＤＩＳＣＯＶＥＲ的累计时间，以秒为单位。设备上电后，第一个DHCPDiscover包要在0~60秒之间随机时延一段后发出。17discover报文的时间间隔实例18续租机制

上图中T1.5(68.75%,5.5/8,11/16)和T2.5(93.75%,7.5/8,15/16)是中国电信的对标准规范的扩展。19续租未响应的抓包20在T1期间总是得到响应的抓包21在T2期间才得到响应的抓包22终端ARP探测(福建电信规范)23ARP探测流程

1)家庭网关正常获取ＩＰ后，ARP探测机制开始探测。探测周期为每四分钟一次，探测包为全ＦＦ广播包，探测三层地址为本接口网关ＩＰ地址。2)探测包发送后，等待超时时间为五秒。若五秒内收到ARP回复，本次探测结束。若五秒超时未收到ARP回复，则：发送以广播形式发送Request发（包中携带本接口之前正常获取的ＩＰ地址）续租。3)若未收到ＤＨＣＰserver回应的ACK报文。重复本过程发送Request报文（重复发送间隔为２ｓ）。任何一次收到ACK报文后，本次探测结束。若２）中三次Request续租报文均无回应，则重启ＤＨＣＰ会话。（如同重新开机ＤＨＣＰ流程）24ARP链路检测总是正常的抓包25ARP探测异常发request抓包26ARP探测异常且无法恢复抓包27Option60字段名长度内容Code8固定值，60Length8整个报文长度EnterpriseCode16企业代码（参照e8规范）Fieldtype8扩展属性，固定值31FieldLength8扩展域的长度FieldValue认证加密信息

012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|code(60)|Length|EnterpriseCode|+---------------+---------------+---------------+---------------+|Fieldtype|FieldLength|FieldValue|+-------------------------------+-------------------------------+28Option60Option60字段鉴权规划参照《中国电信“我的e家”技术规范——e家终端（e8）》文中标准设计。扩充FiledType31-60为IPTV机顶盒专用，其中FieldType31定义为IPTV机顶盒DHCP认证的鉴权信息（具体为：接入层用户名、密码等信息加密后的密文，加密算法见本文相关内容）。29Option60加密算法

在家庭网关启动后，如果FLASH中没有储存VOIP用户名和密码信息，则OPTION60相关信息如下：Type为34；Value为24位家庭网关序列号+默认VOIP账号字符串（固定为”admin/admin”）。如果VOIP账号已保存到家庭网关的FLASH中，Option60字段相关信息如下：Type值为34，Value值为24位家庭网关序列号+VoIP账号的加密字符串DHCP平台对网关OPTION60字段进行验证，对验证通过的返回OFFER报文，没有通过的丢弃该报文不做任何处理。30Option60加密算法家庭网关从FLASH中读取出VoIP/IPTV账号信息：用户名（UserID）、密码（Password）家庭网关生成随机数R，R长度为64bit，8字节。家庭网关生成时间戳TS，TS定义为距离格林威志时间1970年0点秒数的64bit整型，强制转换8字节长整型，如位数不够高位补0。家庭网关生成密文C=EnCry(R+TS+64Bit,UserID)，例如C的长度为128bit，UserID为120bit(15字符)，EnCry为3DES对称加密算法，密钥为R+TS后用64位0补足192bit。家庭网关生成密钥Key=Hash(R+Password+TS)，其中Key为128bit，Hash()为哈希算法，这里定义为MD5；R+Password+TS就是Byte的直接拼接。家庭网关生成发送消息Message=O+R+TS+Key+C，其中O描述使用的对称加密算法8bit，O=1：表示为上述描述的加密算法，O=其他数字：保留。31Option60字段举例CToption60全字段(UserId[ad66133512@iptv]Password[123456])3C3500001F31010ADAA13C130D336A0E0000

00

00

00

00

0053BE31310F1F5FC8538E6770773219DEA4EDBABF98501ED16CBFDE0D0EA50FF9Type......:60(0x3C)

Length.....:53(0x35)EnterpriseCode:0(0x000x00)Fieldtype...:31(0x1F)FieldLength..:49(0x31)

加密方式....:1(0x01)加密计算:随机数:0ADAA13C130D336A时间戳:0E0000

00

00

00

00

00密钥Key:53BE31310F1F5FC8538E6770773219DE密文C:A4EDBABF98501ED16CBFDE0D0EA50FF932Option125OPTION125功能是对标准DHCP协议一个补充标准，该功能的标准定义在RFC3925中。DHCP服务器在完成验证将客户端的IP地址等信息封装成DHCPOFFER包的时候，将OPTION125信息封装进DHCPOFFER包中再发送给客户端。DHCP服务器在收到Request包后，同样也会在回给机顶盒的ACK包中添加OPTION125的信息。客户端收到OFFER/ACK包以后，首先查看该OFFER/ACK包中OPTION125中的约定的信息，并与预先存储的信息进行比对。比对结果为相同则使用此OFFER/ACK，如果比对信息不同则将此OFFER/ACK丢弃。33Option125格式

34Option125举例举例:Option-code=125Option-len=DHCP服务器厂商自定义Enterprise-number1=DHCP服务器厂商自定义data-len1=16vendor-class-data1=SHCTCIPTVDHCPAAA35中国电信Option125扩展功能Option125特定字段内容定义enterprise-number1：待定，暂用0。option-data1：DHCPSERVER特定信息（根据需要添加，总字节数不可超过250）36Option125扩展字段定义

subopt-codesubopt-lensub-option-dataDescriptionofsub-option-data11-32设备的生产厂商名称字符串格式，建议使用英文或拼音21-32DHCPserver的设备种类或分类字符串格式，如：

HGW-CT

STBDHCPSERVER

DHCPSERVERNo.531-32DHCPserver的设备型号字符串格式，如DS-8000102上网类业务的VLANID2个字节十六进制数（高字节在前），值0x2000表示untag112IPTV业务的VLANID2个字节十六进制数（高字节在前），值0x2000表示untag122IMS业务的VLANID2个字节十六进制数（高字节在前），值0x2000表示untag132VOICE业务的VLANID2个字节十六进制数（高字节在前），值0x2000表示untag13～60（预留）83保留原有IPTV通道DHCPserver专用其它（待定）37Option125举例说明0000

7d1c0000

00

001702064847572d435403

}........HGW-CT.0010

0944503630372d4756390b020064

.DP607-GV9...d7d(option125)1c(length28)0000

00

00(enterprise-number1：待定，暂用0)17(data-len1=23)02(subopt-code2)06(subopt-len)4847572d4354(HGW-CT)03(subopt-code3)09(subopt-len)44503630372d475639(DP607-GV9)0b(subopt-code11)02(subopt-len)0064(IPTV业务的VLANID=100)38现网DHCP案例分析福州语音问题通过option60实现对A/B业务平面的访问39福州语音问题现网现象描述接福建大亚现场技术支持工程师(FAE)黄红慈报道，SVN：5571的软件版本，在福州几个本地网多出现语音不能使用，到现场看了一下，发现PINGSBC地址无法通，查看路由表有IP存在，局方数据查询说该ONU无发续约包过来，导致半个小时后语音不能正常使用，但在现场发现是有IP地址的。另外只要重新设置一下WAN口连接（就是点击一下VLAN：45按确认后）设备在上报IP请求，IP就可以通了。40现网现象初步分析和定位初步分析：可能是续租包没有发出来，目前网关在续租到期未续租成功的情况下，IP地址可继续使用（符合前面的“查看路由表有IP存在”），但无法ping通SBC(因为地址已经被回收)。另外重新设置一下WAN口连接，这是会重新开始DISCOVER的过程，就又能拿到server分配的IP了（符合前面的“IP就可以通了”）。通过大亚FAE在现场的抓包，确实没有发现发续租包，包括单播和广播续租包。41在公司内的验证

升级为同样的版本，同样的组网环境，在公司内验证，发现DHCP所有过程一切正常，包括续租过程。DHCP续租包总是在租约期的一半时间向DHCPserver准时发出。42初步怀疑方向

因为是在VOIPWAN连接上发生了DHCP无法续租成功，而VOIPWAN连接是使用的独立的路由表（与INTERNET路由表不一样）。根据以往的经验，DHCP单播续租包无法发出的一种可能是路由表不正确，导致单播包无法找到路由而发送失败。根据负责组网模块的工程师说法，福建那边有一个特殊需求，从offer包提供的网关地址和网段掩码，无论掩码长度为多少，都加一个8位地址的掩码的路由。根据为福建电信定制功能而写的代码，例如会添加了一条以下的路由:iprouteaddto10.8.0.0/8deveth4.46_1tablet31实际上这条路由添加是不会成功的，经过路由表查看，这样的路由没有添加成功的，因为子网和掩码长度不匹配，需要修改成以下这样的路由才能添加成功。iprouteaddto10.0.0.0/8deveth4.46_1tablet31因此怀疑路由没有添加成功导致单播DHCP续租包未能成功发出，经过修改代码，修正了以上的bug，发送版本给前方验证。43对初步怀疑的验证

经过前方验证，故障依旧，虽然前面bug得到了修正，但DHCP的问题与此bug无关。44再次分析验证(1)因为在公司环境里测试一切正常，在福建现网环境不正常，因此怀疑与网络环境是有很大关系的。查看DHCP模块代码的历史修订记录，在今年2月份时未福建电信增加了DHCPARP探测的功能，是否与此有关？因为ARP探测功能可以单独关闭，不启用ARP探测功能，经前方验证，问题依旧。把DHCP模块的代码倒退到2月份之前的版本，重新编译，发给前方验证，问题消失。看来是ARP探测功能加入后引入的bug。45再次分析验证(2)为了证明推论，关掉NTP服务，重启设备，续租包能够正常发出，证明确实与NTP服务有关。并进一步分析出以下过程：

1）开机DHCP首先拿到地址，根据当前的系统时间+租期/2得到开始发续租包的时间（在2000年）

2）NTP在WAN口得到地址后开始启动，更新系统时间到2012年

3）DHCP进程检查发续租包的时间永远无法满足,由于时间坐标系不一致，续租时间是按2000年为基准，当前时间按NTP更新后的时间2012年为基准，导致发续租包的时间条件不满足，永远发不出续租包。46再次分析验证(3)需要在代码中加入debug信息，看为何到了租期的一半时间DHCP续租为何不能发出。根据实现的原理，需要有两个定时器，一个定时器检查租期是否过半，一个检查ARP探测定时器是否到时间，这两个定时器每秒钟分别检查一次。定时器的检查是基于系统时间秒数，以1970年1月1日0时0秒为基准点，取当前时间距基准点的秒数,与预计租期到一半的时间点进行比较，如果等于这个时间点，续租包就发出。经过分析debug信息，发现续租时间和当前时间差别巨大，差值在12年左右。

因为续租时间是在当前时间+租期/2上得出的，不会差别这么大，推测与NTP服务开启有关，系统默认时间是2000年，NTP更新后在2012年，正好差别12年。47再次分析验证(4)通过以上分析，需要在NTP更新时间后，调整以前续租时间的坐标系才能校准时间，满足发续租包的时间条件。修改代码，在检查到续租时间和当前时间差值大于一个租期时（这种情况只有NTP修改时间才可能发生），立刻调整续租时间为当前时间。通过验证，能够解决此问题。根据代码修改记录，同样可以解释SVN5399的版本无问题，SVN5711版本存在此问题。在此两个版本之间，增加了DHCP模块每4分钟ARP检查的功能，修改了有关定时器的机制，以同时满足定时器对续租和ARP检查两个功能的同时支持，定时器在正常情况下本身无问题，但没有考虑到NTP服务刷新系统时间带来的影响，导致了这个差别。48再次分析验证(5)根据代码修改记录，同样可以解释SVN5399的版本无问题，SVN5711版本存在此问题。在此两个版本之间，增加了DHCP模块每4分钟ARP检查的功能，修改了有关定时器的机制，以同时满足定时器对续租和ARP检查两个功能的同时支持定时器在正常情况下本身无问题，但没有考虑到NTP服务刷新系统时间带来的影响，导致了这个差别。49多定时器实现机制50现网问题的解决方法针对前面出现的问题，解决现网存在问题的方法有如下几种:1)升级到最新版本

2)退回到版本5399,但此版本无ARP检查的功能

3)关闭NTP的功能，重启设备。或者让电信关掉NTP服务器51更优化的解决方案经过前面的分析，此问题的实质是因为系统时间发生漂移，导致定时器无法按预期时间点触发原定任务的处理，虽然前面的解决办法可以在侦测到故障发生时能够自行恢复，但毕竟属于事后补救的方法，能否做到彻底解决呢？考虑到系统启动后先设置系统默认时间（例如2010年1月1日0时0分），然后DHCP获得地址后，再通过SNTP服务取得当前的实际时间，实际时间与系统默认时间肯定是不同的。这几个过程的时序都是固定的，无法在此基础上做任何改进。后来想到了取系统自上电以来的秒数（uptime），这个应该与系统时间无直接关系，并且在修改系统时间后，理论上也不会发生任何突变。经过验证，的确如此。以系统上电的时间作为参考点，取当前的uptime作为时间比较点，经过验证，可以彻底解决此问题。52更优化的解决方案之关键代码在系统头文件中的定义struct

sysinfo{ longuptime; /*Secondssinceboot*/ …}/*封装了一个函数，能够返回系统自启动以来的秒数*/longget_uptime(){

struct

sysinfo

s_info;

interror; error=sysinfo(&s_info);

if(error!=0) {

printf("get_uptimecodeerror=%d\n",error); return0; } returns_info.uptime;}53一些经验教训

研发写代码时需要仔细考虑各种情况下代码的逻辑是否正确。本案例中因为忽略了系统时间可能变化，导致基准时间变化，导致定时器不准。概率虽然看似很小，但一旦条件满足，就百分之百地出现故障。不完整的测试会放过一些bug在本案例中，因为以前的每次测试（包括自测，测试人员测试，现网测试，发行测试），都未能开启SNTP服务，导致无法测试出此bug。而且即使开启SNTP服务，普通的测试无法测试出此bug。要测试出此bug，还需要满足以下条件：

1)测试时间足够长，要大于租期的一半时间以上

2)局端设备（OLT,DHCPserver等）要对未续租成功的设备回收IP地址，取消到此设备的路由因此，需要包括研发，测试，FAE在内的人都需要提高警觉，每个环节都不能放松。54一些技巧总结

为了快速测试，可以把DHCP租期时间尽量设置短一些，以便尽早完成整个测试过程。在现网中，由于无法修改局端的DHCPserver的租期,可以在代码中修改，例如在现网中DHCP租期时间是30分钟，在代码中把租期时间直接修改为100秒，不影响此问题的本质。在过50秒没有发出续租包，即可认为存在问题。可以通过使用更改系统时间的命令来模拟SNTP服务的效果，这样可以简化和加快自测的效果。55通过DHCP实现对A/B平面的访问应用背景方案设计方案验证结果个别现网问题的解决方案进一步优化—LAN侧VLAN绑定56应用背景在2009年底，上海电信欲推出一种新集上网，看IPTV业务于一体的无线终端设备-魔屏，此设备的特点是能够同时访问A/B平面。所谓的A平面是指INTERNET网络，B平面是IPTV平面，B平面与A平面不能互相访问，完全由中国电信经营维护，完全独立的IP地址空间。以往通过家庭网关接入的设备，由端口绑定决定这个设备要么只能访问A平面，要么只能访问B平面，无法同时访问A/B平面。访问A平面相当于PC的行为，访问B平面相当于IPTV机顶盒的行为。57A/B平面组网示意图58方案设计(初步)为了使魔屏使用简单，魔屏是使用DHCP方式获得地址。研究了B平面DHCP的电信规范，发现B平面对DHCP有特殊要求，其中一个要求是在option60中可以识别IPTV机顶盒,即在option60中有IPTV机顶盒的特征字段。因为A/B平面IP地址空间是独立的，要同时访问这两个平面一定需要两个独立的IP地址，对于魔屏而言，需要在两个平面分别DHCP获取IP。由于端口绑定的原因，在正常情况下，哪怕发出两次不同的DHCP请求，只能