[涉及到DHCP服务的接口或业务割接需要注意残留表象的影响 ]高端路由器 bras角色， 作为DHCP relay场景 由于DHCP relay表象残留导致的网上问题

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客户端不受影响。