PC--bras(DHCP relay)————server(可能是双server场景)
基础知识:dhcp relay 和dhcp server一样会记录一张表,用于查询地址分配状态,relay这种表缺省是刷新的,bras场景一般,关闭这个刷新功能。目的是为了减少本设备和服务器的交互压力,正是由于relay场景关闭刷新,往往产生这种残留影响上线的问题。
举例两个网上问题
1,问题1,设备做bras,ipoe场景,DHCP relay 角色,故障现象是,终端获取不到地址,通过debug发现,bras已经收到了DHCP discover报文,但是设备没有往server转发。
2,问题2,设备做bras,ipoe场景,DHCP relay 角色,故障现象是,终端获取不到地址。dhcp server有两个,两个server的地址池是有包含的。
问题 1:排查了队列,CPU等情况后,未发现异常,说明不是因为性能导致丢弃。
通过debug dhcp erro /event (注意,relay 场景也最好开一下 debug dhcp server ),发现由于接口不匹配导致的报文丢弃。
于是想到可能是既有表象导致的影响。通过display dhcp relay client-information 发现,上不来的终端已经存在dhcp ralay 表象,表象显示接口是从其他接口上来的,而该接口已经没有在使用,是割接之前使用的接口。
问题2:debug dhcp报文交换发现。两个server中,.3的server 先给终端回复offer报文,所以,终端request报文携带server为.3,但是后续relay中继转发报文的时候,只给.2的server发了报文,没有给.3的server发送报文,导致终端获取不到地址,因此需要了解为啥relay会转发错误。后续通过查看表象,确认为。用户先从Server 172.16.228.2上线,中继生成CINFO表项,CINO记录上线Server地址172.16.228.2
、relay没有开启刷新功能,所以server上老化的租约无法通知到relay,导致relay上cino表项持续残留,用户再次上线,discover报文往两个server都发,且先收到172.16.228.3回的offer,因此client发送request报文携带的option 54是172.16.228.3,同时relay转发request时用request报文里面的youripaddress查找到对应的CINFO,因为CINFO下记录有Server地址172.16.228.2,因此只往172.16.228.2转发,不往172.16.228.3发送了172.16.228.2 。Server收到request报文时,检查option 54 ServerID 172.16.228.3与自己不匹配,也不会回复ack,导致上不去线
问题1解决方法:
1.通过reset掉相关client表象,问题解决。后续割接,对于中继场景,更换接口的,最好,释放老的表象,不要被残留的影响。
或者可以配置 dhcp session-mismatch action命令用来配置DHCP设备收到物理位置发生变化、MAC地址不变的上线用户发送的DHCP-DISCOVER的处理方式。
问题2解决方法:
1,中继场景,两个server最好不要配置有重叠的地址池,这样分地址的报文永远用一个交互,不会存在这个问题。
2,中继场景,要使用 ralay改为代理模式
涉及到以上组网的割接场景,建议注意到DHCP ralay的地址残留,对于更换接口的场景,需要清空老的地址分配状态,另外,建议配置DHCP基于终端的探测,及时消除表象。另外,很多场景,终端上不了线是由于分配的ip地址和已经有的表象冲突,此时可以通过如下命令解决。
dhcp conflict-ip-address offline命令用来配置当为新DHCP客户端分配的地址和已在线DHCP客户端的IP地址发生冲突时,释放已在线DHCP客户端的IP地址。
undo dhcp conflict-ip-address offline命令用来恢复缺省情况。
【命令】
dhcp conflict-ip-address offline
undo dhcp conflict-ip-address offline
【缺省情况】
当为新DHCP客户端分配的地址和已在线DHCP客户端的IP地址发生冲突时,已在线DHCP客户端不受影响。
该案例暂时没有网友评论
✖
案例意见反馈
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作