公司pc通过dhcp获取ip失败问题处理总结Word文档下载推荐.docx
《公司pc通过dhcp获取ip失败问题处理总结Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《公司pc通过dhcp获取ip失败问题处理总结Word文档下载推荐.docx（17页珍藏版）》请在冰豆网上搜索。
1.现象：
公司网络出现自动获取ip的pc无法获得ip，显示地址是169.254.xx.xx的地址；
有的区域获取的地址不是规划中的ip地址，无法上网。
2.组网：
19,20楼办公环境采用48口接入交换机，ip为192.168.2xx.xx,第三段如图中所示，206,207，208有级联的下级交换机，上联用10g光模块光联核心光交换机。
测试环境下用路由方式和办公区域连接，同样采用光联。
测试交换机下接多个接入交换机。
各网段划分不同的vlan，在核心交换机上起dhcp服务，测试交换机中没有dhcp功能。
上网采用ros路由器出局，核心光交换机用千兆网线和ros路由器对接，对接口属于vlan212。
3.排除过程：
无法获取ip地址的pc上抓包，cmd下执行ipconfig/release,ipconfig/renew。
一个区域显示discover后dhcp服务器没有响应。
另一个区域情况：
共性是正确的mac地址的dhcp服务器没有应答，区别是205区域有其他的dhcpserver。
查看dhcp的资源，showipserverpoolstat，看有空闲的资源。
查看showintbrief，查看各接口的占用情况，发现1/1/1端口出入占用率都比较高。
正常时候和故障时的比较图：
可以看到明显端口1/1/1的明显显偏高。
查看cpu的占用率，如下图：
一般cpu的占用了率在60%才无法处理包，所以还没有达到阈值。
参考cpu里接收各种协议的数量：
短短的一两秒间隔，发现有收到大量的dhcp消息，肯定不正常。
要么环境中有大量的发dhcp请求的discover的，要么是有大量响应的offer之类的消息。
比较丢弃的个数：
下一次：
丢弃了461包
比较正常情况：
丢弃为0，确定是接收太多导致无法处理丢弃。
Debug一下接收的包：
把debug信息输出到telnet的终端上
查看驱动接收的10包是什么？
进入debug模式，debug-hide0906
debugdriverreceivecount10
看到10包里有6包是212vlan接到消息。
已知212vlan对应的1/1/1端口，镜像一下1/1/1端口的包看看。
已经添加镜像组1，monitor端口是1/1/23,只需把1/1/1端口端口作为source-port。
查找此mac地址
据此判断是ros路由器大量的发送offer消息，导致dhcp资源耗尽，无法处理其他来的dhcp消息，导致discover没有应答，无法获得offer消息。
规划中，ros路由器无dhcp功能，可能是其他同事配置此项功能，登录ros路由器，关闭dhcp的server功能后，查看发送报数正常。
没有丢弃的包，此时检查dhcp的功能正常。
4.后续处理过程
由于镜像后，急于恢复dhcp功能，没有抓端口1/1/1发出的包，所以无法确定是否是哪个网络转发的discover造成ros路由器不停的发offer消息。
所以预防性处理问题。
1
2
3
4
4.1添加acl拦截过滤dhcp消息
端口1/1/1上出口拦截discover，request消息，入口拦截offer消息，ack消息。
Dhcp的端口是67,68，所以用acl来实现。
具体的指令为：
access-list2001
rule2001denyudpany68any67
rule2002denyudpany67any68
intten1/1/1
filteringressaccess-list2001statistics
filteregressaccess-list2001statistics
在2001中，拒绝任意源ip端口68发出的任意ip地址，端口为67的udp消息。
在2002中，拒绝任意拒绝任意源ip端口67发出的任意ip地址，端口为68的udp消息。
使用规则，注意选择入和出的方向，要看统计数据后面要加上stat的选项。
在ingress方向，拦截测试环境发出discover消息，request消息等等。
Egress方向，拦截发往测试环境的offer，ack消息。
根据showipdhcpserverstat回车来查看dhcp消息的多少，发现还有大量的discover和offer增加的问题。
4.2查找dhcp的广播消息的来源并处理
在各个vlan里抓包发现，vlan206中有大量的discover消息上报。
为了方便查看mac地址，把添加一列sourcehw
这是接个无线wifi设备（也就是一个有无线wifi功能的nat路由器），进入检查发现，wan口设置为dhcp，重启后，发现依旧不停发discover消息，而正常的wifi路由器不发，确定这些wifi路由器损坏，关闭电源后，现象消失。
观察发现，206网段里存在dhcp服务器，回offer消息的现象。
如图：
发现205网段同样存在dhcp服务器情况，询问有的iad设备默认lan口开启了dhcp，接入网段后会引起问题。
4.3各网段交换机开启dhcpsnooping功能
为此，各网段交换机开启dhcpsnooping功能，添加上联级联口为信任口，DHCP-snooping所起到的的作用就是只有指定端口才接受主机发送的dhcpdiscover广播包，并且只有指定的端口才可以发送DHCP的offer。
而不向其他端口转发discover消息，避免环境中其他的dhcp服务器乱回offer消息造成dhcp失败。
一般在接入交换机上，把级联口作为信任端口。
其他端口不接受discover消息。
步骤是：
1）开启全局dhcpsnooping消息。
2）进入信任的端口，开启dhcpsnooping。
3）此端口为信任端口
只有级联口1/1/52端口是上级级联口，开启dhcp后discover才会接受和转发offer消息。
执行showipdhcpserverstat，发现discover和offer消息大量减少，但还有增加，排查发现是从测试环境对应交换机上来的。
测试环境的交换机采用路由模式和办公区域互通，不能采用在同一vlan中抓包，镜像上联口后，过滤如下：
规划中测试汇聚交换机没有dhcp功能，所以决定采用acl拦截其端口上的dhcp消息。
4.4核心交换机开启acl拦截测试汇聚交换机接口的dhcp消息
注意：
ingress指从端口进入设备，egress指从端口离开设备。
Acl规则号，不同的数字范围代表不同的拦截方法，同一种协议对应一张表，可以有3000中ruleid可以添加。
添加过程：
1）首先添加一条access-list，注意对应acl的编号范围
2）进入对应aclid中添加规则，规则和1-3000，同一种协议对应一个acl号码，否则会冲突。
3）使用规则，注意选择入和出的方向，要看统计数据后面要加上stat的选项。
图上的语句是拦截dhcp的协议discover消息和冒充dhcp服务器的offer消息。
Acl运行后，showipdhcpserverstat中discover消息，offer消息不再猛增。
4.5关闭个vlan1的dhcp功能
镜像交换机端口的包，还有发discover消息上来。
检查这些mac地址的所属区域，发现mac地址仅存在于级联口上，最后发现这些都是各交换机的mac地址。
取消vlan1的dhcpclient功能
关闭vlan1的dhcp功能后，镜像各端口的包没有抓到vlan1发来的dhcp消息。
这些措施执行后，查看dhcp的消息统计，discover，offer比较稳定，没有飙升的现象。
见下图：
5.故障分析：
因为处理故障时，没有镜像核心交换机和ros路由器之间的包，所以无法确定是各级交换机中那个设备发的dhcp的discover消息发到ros路由器，引起ros路由器不断发offer消息，导致核心交换机无法处理正常的dhcp消息引发的故障。
自动获取ip的pc默认租期是一天，到达租期的一半时间时，客户机发出request消息进行续租，由于服务器没有应答消息，pc继续使用此pc，到达租期八分之七时间后，继续发起request消息，服务器依旧没有应答，当到达租期后，pc不能继续使用此ip，重新发起discover消息，此时服务器没有应答，导致pc无法获得ip地址，pc保护机制分配169.254.xx.xx的保留地址。
Pc此时无法上网。
当环境中有非交换机的dhcp服务器存在时，正常情况，pc的重启和网线插拔以及租期一半时，均采用request广播消息进行续租，正确的服务器胡应答，并给出ack消息进行确认租期。
当交换机的dhcp服务器不能应答消息时，pc在租期到达后，重新发起dicover消息申请ip，这时非交换机的dhcp服务器发出offer消息，此时没有正确dhcp服务器的offer到达，pc没有选择正确ip的机会，就对此错误的ip进行确认。
导致获得ip，但同样无法上网。
交换机配置了dhcp的snooping消息后，添加级联口为信任端口，discover，request消息只转发给信任的级联口到核心交换机，环境中其他端口接的dhcp服务器无法获得discover消息，从而避免了offer消息的发出。
同时交换机也只转发信任口的offer和ack消息到其他端口。
6.过程中累计的知识点：
Dhcp过程失败，pc会自动使用169.254的ip地址。
Dhcp客户端使用的两个定时器，二分之一租期和八分之七租期。
Dhcp服务器用mac地址标识一个pc，对同一个mac的多次discover消息，会分配同一个ip地址。
Dhcp过程中，客户端产生一个transactionid随机数来标识dhcp事件，服务器的应答消息，会使用这个id来标识整个过程。
服务器的offer消息发出后，不是立即分配这个ip给pc，而是有一定的时间等待后续的消息，ack发出后，才确定正式分配出此ip地址。
若没有得到后续的request消息，一般会等待5分钟后，释放此ip地址。
有大量的不通mac地址的discover上来，而没有request消息，会引起dhcp的资源枯竭，没有可用的ip分配。
镜像获得包，是端口acl之前包，依然能看到dhcp的拦截前消息。
Discover和request消息是广播消息，可以在同一vlan里抓到。
Offer消息有时可以是广播消息。
收到多个offer响应，pc会从中挑选一个来回request消息。
17
升级会员 