Devices are not accepting fixed IP and adopt 169.254.X.X / 16 (APIPA)

[Rafael Santos]

Hello,

I have a WI-FI network where access points are managed by a Cisco Wireless Controller.

The IP address distribution for all elements of this wireless network is done through a Windows DHCP server.

The wireless network in question is allocated to a VLAN for mobile devices.

The problem I am facing is the following, I want to put a new DHCP server in the environment and for this I have allocated a fixed IP within the VLAN destined for mobile devices. For this new server I have allocated a fixed IP that is not within the scope of distribution of the current DHCP server, however any fixed IP that I put on this new DHCP server it disregards and adopts IP 169.254.XX / 16, that is, it adopts the IP APIPA

I have already validated that the address I am trying to allocate is available, is not within the scope of distribution of the current server, I tested with other IPs available within the same network, but the new server in no way adopts the fixed IP that I am allocating and adopts automatically 169.254.XX / 16.

I did a test, I got a notebook, I set the fixed ip in the network of mobile devices but the same problem happened, the notebook discarded the fixed ip that I configured on the network card and adopted IP 169.254.X.X. With this I disregard cabling problem, and network card, since I tested on different network points and on different computers.

I came to the conclusion that any element that I connect through the wired network in the VLAN that serves the mobile devices, even configuring fixed IP, this ip is not accepted and an ip APIPA is adopted. With this I am not able to make the inclusion of the new DHCP server. Has anyone ever picked up a problem of this nature before and can you help me?

Network data:

Mobile network: 172.21.0.0 / 21
IP address of the current DHCP server: 172.21.0.3 / 21
DHCP scope of the current server: 172.21.2.0 through 172.21.7.254
IP of the new DHCP server: 172.21.0.6 / 21 <= It has been validated that this ip is available and does not respond on the network.
VLAN for mobile devices: 21

Thank you,
Rafael Santos

[Georg Pauwen]

Hello,

weird indeed. Can you assign a static IP address to the DHCP server when the server is not connected to anything, that is, when you unplug the cable ?

[Rafael Santos]

Hello,

When the DHCP server is not connected and the microcomputer also accepts the IP. The problem occurs when I connect the network cable. At this point it ignores the IP address that I configured manually and adopts 169.254.x.x.

[paul driver]

Hello

---

@Rafael Santos wrote:

Network data:

Mobile network: 172.21.0.0 / 21
IP address of the current DHCP server: 172.21.0.3 / 21
DHCP scope of the current server: 172.21.2.0 through 172.21.7.254
IP of the new DHCP server: 172.21.0.6 / 21 <= It has been validated that this ip is available and does not respond on the network.
VLAN for mobile devices: 21

Current dhcp server = 172.21.0.0/21
New dhcp server   = 172.21.6.0/21

First of all both are in the same ip range , You cannot just take a ip range for the /21 and use it, If you want to a second dhcp server allocating a specific vlan from that /21 range then you need to split the address block.

example:
                                               172.21.0.0/21

172.21.0.0/22                                                          172.21.4.0/22

                                             172.21.4.0/22

172.21.4.0/23                                                          172.21.6.0/23

                                              172.21.6.0/23 21

172.21.6.0/24                                                          172.21.7.0/24

Look at the top end of that /21 for instance, If you just want to use just a /24 (172.21.7.0/24) you need to make sure its peer subnets (/23 or /22 of /21) is not being used by anything else..

So at present your current/new dhcp server are in the same ip range.

[Rafael Santos]

Hello Paulo

Many thanks for the reply.

I do not understand why I need to split the / 21 to allocate to a new DHCP server on the 172.21.0.0 / 21 network.

For example, in the test that I did with the microcomputer and manually configured the IP 172.21.0.X / 21 (Validated that the IP was available), because this microcomputer when connecting the cable disregarded the IP that I configured and adopted 169.254.XX , the ip was not conflicting with any other and also was not DHCP enabled, which does not justify receiving the APIPA as it has been occurring?

Still with the microcomputer I performed the following test, I removed the IP that I configured manually, I was enabled to receive IP dynamically from the DHCP Server. The microcomputer received the IP of the DHCP server dynamically for a moment and after a few seconds adopted the 169.254.X.X.

This problem only happens with the wired network, because the devices that connect through the wireless receive the IP of the network 172.21.0.0 / 21 without any problem.

Regards,

Rafael Santos

[Leo Laohoo]

So you created a new subnet and a new VLAN?
Is this new VLAN allowed on the Trunk link? Check by pinging the default-gateway IP address from the controller.

[Rafael Santos]

Hello,

The network and the VLAN are the same. My goal is to just replace the DHCP server by placing the IP 172.21.0.6 / 21. When the server goes to accept this address and stops adopting 169.254.x.x I will stop the DHCP service on the old server (172.21.0.3) and upload the DHCP service on the new server.

[Leo Laohoo]

So where is the DHCP helper IP address pointing at? The new server or the old server?

[Rafael Santos]

In this case, because the DHCP server is on the same network to which you are allocating the IP addresses, there is no IP helper address configuration. That is, the segment in question is just layer 2.

[paul driver]

Hello

---

@Rafael Santos wrote:
Hello,

The network and the VLAN are the same. My goal is to just replace the DHCP server by placing the IP 172.21.0.6 / 21. When the server goes to accept this address and stops adopting 169.254.x.x I will stop the DHCP service on the old server (172.21.0.3) and upload the DHCP service on the new server.

---

This makes more sense, The way I interpreted it was you were trying to have two dhcp servers using the same subnet but not distributing that subnet correctly over those two servers.

Is the client on the same subnet.vlan as a wireless client? 
Is the switch the wired client is attached have the correct vlan?
Does the port the microcomputer is attached to have stp portfast enabled and in the correct vlan?

Can you ping the dhcp server from the switch or the L3 interface of the vlan the client is attached to?

[Rafael Santos]

Hello Paulo,

Is the client on the same subnet.vlan as a wireless client?
Yes, the client is on the same network and VLAN as the wireless clients. The only difference is that it is in the wired network.

Is the switch the wired client attached to the correct vlan?
A: The switch to which I connected the client for testing is correctly passing the vlan TAG of mobile devices, ie the VLAN 21.

Does the port the microcomputer is attached to have stp portfast enabled and in the correct vlan?

A: The port to which the microcomputer is connected has stp porfast enabled and is configured in access mode by passing VLAN 21.

Can you ping the dhcp server from the switch or the L3 interface of the vlan client is attached to?
A: From the current DHCP server I can ping the default gateway (172.21.0.1).

[amikat]

Hi,

This may be related to IP device tracking (IPDT). You can check the status via the "show ip device tracking all" command. If enabled you can try to disable the feature either globally or on the interface basis and see if there is any improvement.

Best regards,

Antonin

[Rafael Santos]

Hello Antonin,

I checked the equipment involved in the network and there is no incidence of the IPDT parameter.

Network routing 172.21.0.0 / 21 is done through a Cisco ASA.

I do not know much about NAT, but I found the parameter below. Could this be generating the condition of the problem I am facing?

global (outside) 1 interface
global (inside) 1 172.21.0.2-172.21.7.254 netmask 255.255.248.0
nat (inside) 1 172.21.0.0 255.255.248.0

Thank you,

Rafael

[amikat]

Hi,

Thanks for the reply. Before I go any further my observation is that you may be using rather outdated SW version with ASA as the "global" command was depreciated at about 8.3.

With NAT you are actually using "proxy-arp" feature which MAY have some connection to the issue you are experiencing. You MAY consider to disable this feature temporarily via the "sysopt noproxyarp inside" command to see if there is any improvement. But please be cautious. I have very little information about your network and the ASA configuration so cannot guess the implication of such configuration change.

Good luck!

Best regards,

Antonin

[Rafael Santos]

Hello,

I was able to solve the problem.

I made the following change:

IN:
global (inside) 1 172.21.0.2-172.21.7.254 netmask 255.255.248.0

FOR:
global (inside) 1 172.21.0.7-172.21.7.254 netmask 255.255.248.0

That is, I put the global rule to catch only after the IP that I booked for my new server. After this action the IP that I configured manually was accepted and the previous IP 169.254.X.X IP was stopped.

I do not know about NAT, could you explain why the problem was occurring with the previous configuration?

Thankful,
Rafael Santos