dhcp规范和现网案例分析.ppt

1、1,DHCP规范和现网案例分析,陈曦 2012年6月,2,本次课题,DHCP简介 中国电信DHCP扩展规范 现网DHCP案例分析,3,DHCP简介,协议概述 报文格式 报文类型 常用option DHCP报文交互过程 DHCP客户端更新租约 DHCP client状态机 DHCP中继工作过程 处理DHCP中继报文,4,协议概述,DHCP动态主机配置协议(Dynamic Host Configuration Protocol) 为网络客户机分配动态的IP地址 提供安全、可靠的TCP/IP网络配置 保证IP地址不发生冲突，减少了在TCP/IP网络上增添、移动和配置计算机的管理负担，使IP地址管理自

2、动化。 动态分配IP地址在某些情况下还可以解决IP不够用的问题。,5,报文格式,6,报文字段含义,7,报文字段含义(续),8,报文类型,9,常用option,10,DHCP报文交互过程,11,DHCP客户端更新租约,DHCP服务器分配给客户端的IP地址有一定的租借期限，当租借期满后服务器会收回该IP地址。 为了延长DHCP客户端使用该地址的期限，需要更新IP地址租约。,12,DHCP客户端更新租约包交互,13,DHCP client状态机,14,DHCP中继工作过程,由于DHCP请求报文采用广播方式发送报文，因此当DHCP客户端和DHCP服务器处于不同子网时，必须要通过DHCP中继进行通信，最

3、终获取到IP地址。这样，多个网络上的DHCP客户端可以使用同一个DHCP服务器，既节省了成本，又便于进行集中管理。,15,处理DHCP中继报文,DHCP中继代理收到DHCP报文后首先识别该报文，再进行相应处理。 如果DHCP报文的UDP目的端口号为67，且BOOTP报文头中的“op”字段是BOOTREQUEST（1），即表示该报文是DHCP客户机发给服务器的请求报文。DHCP中继代理会检查报文的“giaddr”字段，如果其值为0.0.0.0，则DHCP中继代理设备用接受该报文的接口的IP地址填充此字段后，发送报文到指定的DHCP服务器组内的所有DHCP服务器。 如果DHCP报文的UDP目的端口

4、号为67，且BOOTP报文头中的“op”字段是BOOTREPLY（2），即表示该报文是DHCP服务器希望通过中继代理转发给DHCP客户端的回应报文。DHCP中继代理会将该报文从“giaddr”字段所属的接口发送到指定的DHCP客户端。,16,中国电信DHCP扩展规范,发送discover报文的时间间隔 续租机制 终端ARP探测流程(福建电信地方规范) Option 60扩展 Option 125扩展,17,发送discover报文的时间间隔,如第一次 DHCP 的请求，未收到来自DHCP 服务器的响应后，需按照协议栈的要求在第 4 秒、第 8 秒、第 16 秒、第 32 秒、第 64 秒、第1

5、24秒、第184秒第304秒分别发起地址请求，且每次只发送一个请求报文。如第秒仍未收到服务器响应，则重启会话，重复上述过程。 其中福建电信要求： seconds elapse字段需记录本次流程中所发送的累计时间，以秒为单位。 设备上电后，第一个DHCP Discover包要在060秒之间随机时延一段后发出。,18,discover报文的时间间隔实例,19,续租机制,上图中T1.5(68.75%, 5.5/8, 11/16)和T2.5(93.75%,7.5/8, 15/16)是中国电信的对标准规范的扩展。,20,续租未响应的抓包,21,在T1期间总是得到响应的抓包,22,在T2期间才得到响应的抓

6、包,23,终端ARP探测 (福建电信规范),24,ARP探测流程,1)家庭网关正常获取后，ARP探测机制开始探测。 探测周期为每四分钟一次，探测包为全广播包，探测三层地址为本接口网关地址。 2)探测包发送后，等待超时时间为五秒。 若五秒内收到ARP回复，本次探测结束。 若五秒超时未收到ARP回复，则： 发送以广播形式发送Request发（包中携带本接口之前正常获取的地址）续租。 3)若未收到 server回应的ACK报文。重复本过程发送Request报文（重复发送间隔为）。任何一次收到ACK报文后，本次探测结束。 若）中三次Request续租报文均无回应，则重启会话。（如同重新开机流程）,25

7、,ARP链路检测总是正常的抓包,26,ARP探测异常发request抓包,27,ARP探测异常且无法恢复抓包,28,Option 60,0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | code (60) | Length | Enterprise Code | +-+-+-+-+ | Field type | Field Length | Field Value |

8、 +-+-+,29,Option 60,Option60字段鉴权规划参照中国电信“我的e家”技术规范e家终端（e8）文中标准设计。 扩充Filed Type 31 - 60 为 IPTV 机顶盒专用，其中Field Type 31定义为IPTV机顶盒DHCP认证的鉴权信息（具体为：接入层用户名、密码等信息加密后的密文，加密算法见本文相关内容）。,30,Option 60加密算法,在家庭网关启动后，如果FLASH中没有储存VOIP用户名和密码信息，则OPTION 60相关信息如下：Type为34；Value为24位家庭网关序列号+默认VOIP账号字符串（固定为”admin/admin”）。如果V

9、OIP账号已保存到家庭网关的FLASH中， Option 60字段相关信息如下：Type值为34，Value值为24位家庭网关序列号+VoIP账号的加密字符串 DHCP平台对网关OPTION 60字段进行验证，对验证通过的返回OFFER报文，没有通过的丢弃该报文不做任何处理。,31,Option 60加密算法,家庭网关从FLASH中读取出VoIP/IPTV账号信息：用户名（UserID）、密码（Password） 家庭网关生成随机数R，R长度为64bit ，8字节。 家庭网关生成时间戳TS，TS定义为距离格林威志时间1970年0点秒数的64bit 整型，强制转换8字节长整型，如位数不够高位补0

10、。 家庭网关生成密文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=其他数字：保留。,32,Option 6

11、0字段举例,CT option 60 全字段(UserIdad66133512iptv Password123456) 3C 35 00 00 1F 31 01 0A DA A1 3C 13 0D 33 6A 0E 00 00 00 00 00 00 00 53 BE 31 31 0F 1F 5F C8 53 8E 67 70 77 32 19 DE A4 ED BA BF 98 50 1E D1 6C BF DE 0D 0E A5 0F F9 Type. . . . . . : 60(0 x3C) Length. . . . . : 53(0 x35) Enterprise Code : 0

12、(0 x00 0 x00) Field type. . . : 31(0 x1F) Field Length. . : 49(0 x31) 加密方式. . . . : 1(0 x01) 加密计算: 随机数: 0A DA A1 3C 13 0D 33 6A 时间戳: 0E 00 00 00 00 00 00 00 密钥Key: 53 BE 31 31 0F 1F 5F C8 53 8E 67 70 77 32 19 DE 密文C: A4 ED BA BF 98 50 1E D1 6C BF DE 0D 0E A5 0F F9,33,Option 125,OPTION 125 功能是对标准DHCP

13、协议一个补充标准，该功能的标准定义在RFC 3925中。 DHCP服务器在完成验证将客户端的IP地址等信息封装成DHCP OFFER包的时候，将OPTION 125信息封装进DHCP OFFER包中再发送给客户端。 DHCP 服务器在收到Request包后，同样也会在回给机顶盒的ACK包中添加OPTION125的信息。 客户端收到OFFER/ACK包以后，首先查看该OFFER/ACK包中OPTION 125中的约定的信息，并与预先存储的信息进行比对。比对结果为相同则使用此OFFER/ACK，如果比对信息不同则将此OFFER/ACK丢弃。,34,Option 125 格式,35,Option 1

14、25举例,举例: Option-code=125 Option-len=DHCP 服务器厂商自定义 Enterprise-number1=DHCP 服务器厂商自定义 data-len1=16 vendor-class-data1=SHCTCIPTVDHCPAAA,36,中国电信Option 125扩展功能,Option125特定字段内容定义 enterprise-number1：待定，暂用0。 option-data1：DHCP SERVER特定信息（根据需要添加，总字节数不可超过250）,37,Option125 扩展字段定义,38,Option125 举例说明,0000 7d 1c 00

15、00 00 00 17 02 06 48 47 57 2d 43 54 03 .HGW-CT. 0010 09 44 50 36 30 37 2d 47 56 39 0b 02 00 64 .DP607-GV9.d 7d (option 125) 1c (length 28) 00 00 00 00 (enterprise-number1：待定，暂用0) 17 (data-len1 = 23) 02 (subopt-code 2) 06 (subopt-len) 48 47 57 2d 43 54 (HGW-CT) 03 (subopt-code 3) 09 (subopt-len) 44 5

16、0 36 30 37 2d 47 56 39 (DP607-GV9) 0b (subopt-code 11) 02 (subopt-len) 00 64 (IPTV业务的VLAN ID=100),39,现网DHCP案例分析,福州语音问题 通过option 60实现对A/B业务平面的访问,40,福州语音问题,现网现象描述 接福建大亚现场技术支持工程师(FAE)黄红慈报道，SVN：5571的软件版本，在福州几个本地网多出现语音不能使用，到现场看了一下，发现PING SBC地址无法通，查看路由表有IP存在，局方数据查询说该ONU无发续约包过来，导致半个小时后语音不能正常使用，但在现场发现是有IP地址

17、的。另外只要重新设置一下WAN口连接（就是点击一下VLAN：45 按确认后）设备在上报IP请求，IP就可以通了。,41,现网现象初步分析和定位,初步分析：可能是续租包没有发出来，目前网关在续租到期未续租成功的情况下，IP地址可继续使用（符合前面的“查看路由表有IP存在”），但无法ping通SBC(因为地址已经被回收)。另外重新设置一下WAN口连接，这是会重新开始DISCOVER的过程，就又能拿到server分配的IP了（符合前面的“IP就可以通了”）。 通过大亚FAE在现场的抓包，确实没有发现发续租包，包括单播和广播续租包。,42,在公司内的验证,升级为同样的版本，同样的组网环境，在公司内验证

18、，发现DHCP所有过程一切正常，包括续租过程。DHCP续租包总是在租约期的一半时间向DHCP server准时发出。,43,初步怀疑方向,因为是在VOIP WAN连接上发生了DHCP无法续租成功，而VOIP WAN连接是使用的独立的路由表（与INTERNET路由表不一样）。根据以往的经验，DHCP 单播续租包无法发出的一种可能是路由表不正确，导致单播包无法找到路由而发送失败。 根据负责组网模块的工程师说法，福建那边有一个特殊需求，从offer包提供的网关地址和网段掩码，无论掩码长度为多少，都加一个8位地址的掩码的路由。 根据为福建电信定制功能而写的代码，例如会添加了一条以下的路由: ip ro

19、ute add to 10.8.0.0/8 dev eth4.46_1 table t31 实际上这条路由添加是不会成功的，经过路由表查看，这样的路由没有添加成功的，因为子网和掩码长度不匹配，需要修改成以下这样的路由才能添加成功。 ip route add to 10.0.0.0/8 dev eth4.46_1 table t31 因此怀疑路由没有添加成功导致单播DHCP续租包未能成功发出，经过修改代码，修正了以上的bug，发送版本给前方验证。,44,对初步怀疑的验证,经过前方验证，故障依旧，虽然前面bug得到了修正，但DHCP的问题与此bug无关。,45,再次分析验证(1),因为在公司环境里

20、测试一切正常，在福建现网环境不正常，因此怀疑与网络环境是有很大关系的。查看DHCP模块代码的历史修订记录，在今年2月份时未福建电信增加了DHCP ARP 探测的功能，是否与此有关？ 因为ARP探测功能可以单独关闭，不启用ARP探测功能，经前方验证，问题依旧。 把DHCP模块的代码倒退到2月份之前的版本，重新编译，发给前方验证，问题消失。 看来是ARP探测功能加入后引入的bug。,46,再次分析验证(2),为了证明推论，关掉NTP服务，重启设备，续租包能够正常发出，证明确实与NTP服务有关。并进一步分析出以下过程：1） 开机DHCP首先拿到地址，根据当前的系统时间+租期/2得到开始发续租包的时间

21、（在2000年）2） NTP在WAN口得到地址后开始启动，更新系统时间到2012年3） DHCP进程检查发续租包的时间永远无法满足,由于时间坐标系不一致，续租时间是按2000年为基准，当前时间按NTP更新后的时间2012年为基准，导致发续租包的时间条件不满足，永远发不出续租包。,47,再次分析验证(3),需要在代码中加入debug信息，看为何到了租期的一半时间DHCP续租为何不能发出。根据实现的原理，需要有两个定时器，一个定时器检查租期是否过半，一个检查ARP探测定时器是否到时间，这两个定时器每秒钟分别检查一次。 定时器的检查是基于系统时间秒数，以1970年1月1日0时0秒为基准点，取当前时间

22、距基准点的秒数,与预计租期到一半的时间点进行比较，如果等于这个时间点，续租包就发出。 经过分析debug信息，发现续租时间和当前时间差别巨大，差值在12年左右。因为续租时间是在当前时间+租期/2上得出的，不会差别这么大，推测与NTP服务开启有关，系统默认时间是2000年，NTP更新后在2012年，正好差别12年。,48,再次分析验证(4),通过以上分析，需要在NTP更新时间后，调整以前续租时间的坐标系才能校准时间，满足发续租包的时间条件。 修改代码，在检查到续租时间和当前时间差值大于一个租期时（这种情况只有NTP修改时间才可能发生），立刻调整续租时间为当前时间。通过验证，能够解决此问题。 根据

23、代码修改记录，同样可以解释SVN 5399的版本无问题， SVN 5711版本存在此问题。在此两个版本之间，增加了DHCP模块每4分钟ARP检查的功能，修 改了有关定时器的机制，以同时满足定时器对续租和ARP检查两个功能的同时支持，定时器在正常情况下本身无问题，但没有考虑到NTP服务刷新系统时间带来的影响，导致 了这个差别。,49,再次分析验证(5),根据代码修改记录，同样可以解释SVN 5399的版本无问题， SVN 5711版本存在此问题。 在此两个版本之间，增加了DHCP模块每4分钟ARP检查的功能，修 改了有关定时器的机制，以同时满足定时器对续租和ARP检查两个功能的同时支持 定时器在

24、正常情况下本身无问题，但没有考虑到NTP服务刷新系统时间带来的影响，导致 了这个差别。,50,多定时器实现机制,51,现网问题的解决方法,针对前面出现的问题，解决现网存在问题的方法有如下几种: 1) 升级到最新版本2) 退回到版本5399,但此版本无ARP检查的功能3) 关闭NTP的功能，重启设备。或者让电信关掉NTP服务器,52,更优化的解决方案,经过前面的分析，此问题的实质是因为系统时间发生漂移，导致定时器无法按预期时间点触发原定任务的处理，虽然前面的解决办法可以在侦测到故障发生时能够自行恢复，但毕竟属于事后补救的方法，能否做到彻底解决呢？ 考虑到系统启动后先设置系统默认时间（例如2010

25、年1月1日0时0分），然后DHCP获得地址后，再通过SNTP服务取得当前的实际时间，实际时间与系统默认时间肯定是不同的。这几个过程的时序都是固定的，无法在此基础上做任何改进。 后来想到了取系统自上电以来的秒数（uptime），这个应该与系统时间无直接关系，并且在修改系统时间后，理论上也不会发生任何突变。经过验证，的确如此。 以系统上电的时间作为参考点，取当前的uptime作为时间比较点，经过验证，可以彻底解决此问题。,53,更优化的解决方案之关键代码,在系统头文件中的定义 struct sysinfo long uptime;/* Seconds since boot */ /*封装了一个函数

26、，能够返回系统自启动以来的秒数*/ long get_uptime() struct sysinfo s_info; int error; error = sysinfo( ,54,一些经验教训,研发写代码时需要仔细考虑各种情况下代码的逻辑是否正确。 本案例中因为忽略了系统时间可能变化，导致基准时间变化，导致定时器不准。概率虽然看似很小，但一旦条件满足，就百分之百地出现故障。 不完整的测试会放过一些bug 在本案例中，因为以前的每次测试（包括自测，测试人员测试，现网测试，发行测试），都未能开启SNTP服务，导致无法测试出此bug。而且即使开启SNTP服务，普通的测试无法测试出此bug。要测试出

27、此bug，还需要满足以下条件： 1)测试时间足够长，要大于租期的一半时间以上 2)局端设备（OLT,DHCP server等）要对未续租成功的设备回收IP地址，取消到此设备的路由 因此，需要包括研发，测试，FAE在内的人都需要提高警觉，每个环节都不能放松。,55,一些技巧总结,为了快速测试，可以把DHCP租期时间尽量设置短一些，以便尽早完成整个测试过程。在现网中，由于无法修改局端的DHCP server的租期,可以在代码中修改，例如在现网中DHCP租期时间是30分钟，在代码中把租期时间直接修改为100秒，不影响此问题的本质。在过50秒没有发出续租包，即可认为存在问题。 可以通过使用更改系统时间

28、的命令来模拟SNTP服务的效果，这样可以简化和加快自测的效果。,56,通过DHCP实现对A/B平面的访问,应用背景 方案设计 方案验证结果 个别现网问题的解决 方案进一步优化LAN侧VLAN绑定,57,应用背景,在2009年底，上海电信欲推出一种新集上网，看IPTV业务于一体的无线终端设备-魔屏，此设备的特点是能够同时访问A/B平面。所谓的A平面是指INTERNET网络，B平面是IPTV平面，B平面与A平面不能互相访问，完全由中国电信经营维护，完全独立的IP地址空间。 以往通过家庭网关接入的设备，由端口绑定决定这个设备要么只能访问A平面，要么只能访问B平面，无法同时访问A/B平面。访问A平面相

29、当于PC的行为，访问B平面相当于IPTV机顶盒的行为。,58,A/B平面组网示意图,59,方案设计(初步),为了使魔屏使用简单，魔屏是使用DHCP方式获得地址。研究了B平面DHCP的电信规范，发现B平面对DHCP有特殊要求，其中一个要求是在option 60中可以识别IPTV机顶盒,即在option 60中有IPTV机顶盒的特征字段。 因为A/B平面IP地址空间是独立的，要同时访问这两个平面一定需要两个独立的IP地址，对于魔屏而言，需要在两个平面分别DHCP获取IP。 由于端口绑定的原因，在正常情况下，哪怕发出两次不同的DHCP请求，只能获得一个平面的地址。 按常规的做法是，网关开启两个SSID， 一个绑定在A平面，另外一个绑定在B平面。魔屏分别连接两个SSID，这样就可以同时访问A/B平面了。 这种做法在理论上可行，但从成本上和管理维护上是不可行的，因为要连接上两个SSID，魔屏或许需要两个WiFi芯片，成本要增加，而且两个SSID的连接即使从用户使用角度看也是非常麻烦的。最好能从一个SSID连接上就能同时访问A/B平面。,60,方案设计(优化),使用一个SSID同时访问A/B平面 默认访问A平面，默认从A平面以DHCP方式获取IP地址 当需要访问B平面时，再发DHCP请求，在其中的option 60字段中带特殊标示，表明是访问B平面的，网关识别出是