DHCP wierd issue!!

Sundeep Dsouza · ‎02-23-2012

Ok we have a branch office connected to HO using GRE tunnel. All users in branch are configured to get IP from the DHCP server in HO. Everything works fine, users get their IP from HO DHCP and no one complains. The issue arises when a user either from the HO moves his laptop to the branch or vice versa. When this move happens, users are not able to get an IP from the DHCP server. Instead it would eventually retain its old IP, which means no connectivity. I have the DHCP debug output posted below, has anyone faced this issue before? Please suggest.

--------------------------------------------------------------

*Mar 17 23:35:40.948: IP: s=0.0.0.0 (Vlan155), d=255.255.255.255, len 358, input feature, MCI Check(73), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

*Mar 17 23:35:40.948: IP: s=0.0.0.0 (Vlan155), d=255.255.255.255, len 358, rcvd 2

*Mar 17 23:35:40.948: IP: s=0.0.0.0 (Vlan155), d=255.255.255.255, len 358, stop process pak for forus packet

*Mar 17 23:35:40.948: DHCPD: Reload workspace interface Vlan155 tableid 0.

*Mar 17 23:35:40.948: DHCPD: tableid for 172.13.1.2 on Vlan155 is 0

*Mar 17 23:35:40.948: DHCPD: client's VPN is .

*Mar 17 23:35:40.948: DHCPD: DHCPREQUEST received from client 0110.78d2.c162.73.

*Mar 17 23:35:40.948: DHCPD: client has moved to a new subnet.

*Mar 17 23:35:40.948: DHCPD: Sending notification of ASSIGNMENT FAILURE:

*Mar 17 23:35:40.948: DHCPD: htype 1 chaddr 1078.d2c1.6273

*Mar 17 23:35:40.948: DHCPD: remote id 020a0000ac1002030c000000

*Mar 17 23:35:40.948: DHCPD: interface = Vlan155

*Mar 17 23:35:40.948: DHCPD: class id 4d53465420352e30

*Mar 17 23:35:40.948: DHCPD: out_vlan_id 0

*Mar 17 23:35:40.948: DHCPD: Sending notification of ASSIGNMENT_FAILURE:

*Mar 17 23:35:40.948: DHCPD: due to: CLIENT CHANGED SUBNET

*Mar 17 23:35:40.948: DHCPD: htype 1 chaddr 1078.d2c1.6273

*Mar 17 23:35:40.948: DHCPD: remote id 020a0000ac1002030c000000

*Mar 17 23:35:40.948: DHCPD: interface = Vlan155

*Mar 17 23:35:40.948: DHCPD: class id 4d53465420352e30

*Mar 17 23:35:40.948: DHCPD: out_vlan_id 0

*Mar 17 23:35:40.948: DHCPD: Sending DHCPNAK to client 0110.78d2.c162.73.

*Mar 17 23:35:40.948: DHCPD: no option 125

*Mar 17 23:35:40.948: DHCPD: broadcasting BOOTREPLY to client 1078.d2c1.6273.

*Mar 17 23:35:40.948: IP: s=0.0.0.0 (local), d=255.255.255.255 (Vlan155), len 328, local feature, RCLI(7), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

*Mar 17 23:35:40.948: IP: s=0.0.0.0 (local), d=255.255.255.255 (Vlan155), len 328, local feature, Local Clustering(8), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

*Mar 17 23:35:40.948: IP: s=0.0.0.0 (local), d=255.255.255.255 (Vlan155), len 328, local feature, Wireless Controller(10), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

*Mar 17 23:35:40.948: IP: s=172.13.1.2(local), d=255.255.255.255 (Vlan155), len 328, sending broad/multicast

*Mar 17 23:35:40.948: IP: s=172.13.1.2(local), d=255.255.255.255 (Vlan155), len 328, sending full packetpak 5931DFC consumed in input feature , packet consumed, MCI Check(73), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE pak 57AA9C8 consumed in input feature , packet consumed, MCI Check(73), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

*Mar 17 23:35:40.965: IP: s=0.0.0.0 (Vlan155), d=255.255.255.255, len 328, input feature, MCI Check(73), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

*Mar 17 23:35:40.965: IP: s=0.0.0.0 (Vlan155), d=255.255.255.255, len 328, rcvd 2

*Mar 17 23:35:40.965: IP: s=0.0.0.0 (Vlan155), d=255.255.255.255, len 328, stop process pak for forus packet

*Mar 17 23:35:40.965: DHCPD: Reload workspace interface Vlan155 tableid 0.

*Mar 17 23:35:40.965: DHCPD: tableid for 172.13.1.2 on Vlan155 is 0

*Mar 17 23:35:40.965: DHCPD: client's VPN is .

*Mar 17 23:35:40.965: DHCPD: using received relay info.

*Mar 17 23:35:40.965: DHCPD: Sending notification of DISCOVER:

*Mar 17 23:35:40.965: DHCPD: htype 1 chaddr 1078.d2c1.6273

*Mar 17 23:35:40.965: DHCPD: interface = Vlan155

*Mar 17 23:35:40.965: DHCPD: class id 4d53465420352e30

*Mar 17 23:35:40.965: DHCPD: out_vlan_id 0

*Mar 17 23:35:40.965: DHCPD: DHCPDISCOVER received from client 0110.78d2.c162.73 on interface Vlan155

*Mar 17 23:35:40.965: DHCPD: using received relay info.

*Mar 17 23:35:40.965: DHCPD: Sending notification of DISCOVER:

*Mar 17 23:35:40.965: DHCPD: htype 1 chaddr 1078.d2c1.6273

*Mar 17 23:35:40.965: DHCPD: interface = Vlan155

*Mar 17 23:35:40.965: DHCPD: class id 4d53465420352e30

*Mar 17 23:35:40.965: DHCPD: out_vlan_id 0

*Mar 17 23:35:40.965: DHCPD: there is no address pool for 172.13.1.2.

*Mar 17 23:35:40.965: DHCPD: Looking up binding using address 172.13.1.2

*Mar 17 23:35:40.965: DHCPD: setting giaddr to 172.13.1.2.

*Mar 17 23:35:40.965: DHCPD: BOOTREQUEST from 0110.78d2.c162.73 forwarded to 192.168.11.10.

*Mar 17 23:35:40.965: DHCPD: BOOTREQUEST from 0110.78d2.c162.73 forwarded to 192.168.11.11.

*Mar 17 23:35:40.982: DHCPD: Reload workspace interface Vlan155 tableid 0.

*Mar 17 23:35:40.982: DHCPD: tableid for 172.13.1.2 on Vlan155 is 0

*Mar 17 23:35:40.982: DHCPD: client's VPN is .

*Mar 17 23:35:40.982: DHCPD: DHCPOFFER notify setup address 192.168.15.50 mask 255.255.255.0

*Mar 17 23:35:40.982: DHCPD: forwarding BOOTREPLY to client 1078.d2c1.6273.

*Mar 17 23:35:40.982: DHCPD: Forwarding reply on numbered intf

*Mar 17 23:35:40.990: DHCPD: no option 125

*Mar 17 23:35:40.990: DHCPD: Check for IPe on Vlan155

*Mar 17 23:35:40.990: DHCPD: creating ARP entry (192.168.15.50, 1078.d2c1.6273).

*Mar 17 23:35:40.990: DHCPD: SIOCSARP ioctl failed (error 22).

*Mar 17 23:35:40.990: DHCPD: broadcasting BOOTREPLY to client 1078.d2c1.6273.

-----------------------------------------------------------------------------------------------------------

The IP address highlighted in red is the IP from the HO. The user retains the same IP in the branch as well which means no connectivity.

Suggestions required.

Thanks.

Edison Ortiz · ‎02-23-2012

The offer is made by your DHCP server, the cisco devices are simply passing the information.

You need to verify your DHCP server configuration.

marat.ishmakov · ‎01-11-2016

Does anybody solve this issue? I got the same one.

Thank you beforehand.

khernandezruiz · ‎11-14-2018

Hi Sundeep Dsouza

Could you resolve your issue?

I could see the following with the info of your debug:

- You have a SVI Vlan 155 with IP address 172.13.1.2

- Inside the SVI 155 you had configured two IP helper-address: 192.168.11.10 and 192.168.11.11

- DHCP Server return you the IP Address 192.168.15.50 mask 255.255.255.0

- An error occured because an ARP issue. It cannot install that IP address that reside in another network (SIOCSARP ioctl failed (error 22).)

Please check:

- from DHCP Server: Assignation based on MAC Address or Client ID for endpoint with issues.

- a subnet overlapping or related misconfiguration

paul driver · ‎11-14-2018

Hello

@Sundeep Dsouza wrote:

The issue arises when a user either from the HO moves his laptop to the branch or vice versa. When this move happens, users are not able to get an IP from the DHCP server. Instead it would eventually retain its old IP, which means no connectivity. I have the DHCP debug output posted below, has anyone faced this issue before? Please suggest.

The IP address highlighted in red is the IP from the HO. The user retains the same IP in the branch as well which means no connectivity.

Suggestions required.

I would check the dhcp servers and see how they are setup, Are they using any superscopes, scopes that overlap, What DHCP options are set.

When the client restarts after having previously obtained a dhcp allocation it will request to the the dhcp server if it can reuse that same ip address, The dhcp server will receive this request and perfrom some validation checks on the ip address/subnet mask/gw within this request

Is the ip/subnet mask from any of its own scopes

Does the ip belong to the local interface the request came in on.
Is it related to any scopes that may have overlapping subnets
etc....

Now if any of its checks fail then the the dhcp server could either deny the client request or just not answer at all thus the client doesn't get any new ip address and retains the old invalid ip.

One option you have to negate such an issue is to set the dhcp server option so clients release there ip address when they shutdown thus they will obtain an new ip address when they boot back up.

Another option could be to ipconfig /release-renew which should resolve the problem but this is something you don't want to keep doing manually but I guess it could be scripted and pushed out to all clients via a gpo?

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul