AP always turn into DHCP

[XJoss]

Hi everybody,

Here I have a problem that I think is quite difficult for me to identify what the problem is. Then I came to this forum to ask you guys.

So the problem is that our Access Point always changes its IP address. I don't know why but it never happened before after we implemented Allot in our network. I've checked the logs on the access point but I don't have a clue. I'll show you the log of the access point below. If you have experienced something similar please help and let us know.

Nov 29 23:06:17 kernel: [*11/29/2021 23:06:17.3679] Re-Tx Count=1, Max Re-Tx Value=5, SendSeqNum=6, NumofPendingMsgs=3
Nov 29 23:06:17 kernel: [*11/29/2021 23:06:17.3679]
Nov 29 23:18:43 kernel: [*11/29/2021 23:18:43.8930] ethernet_port wired0, ip 172.20.74.248, netmask 255.255.255.0, gw 172.20.74.1, mtu 1500, bcast 172.20.74.255, dns1 172.20.70.60, dns2 172.20.2.88, vid 0, static_ip_failover true, dhcp_vlan_failover false
Nov 29 23:18:44 kernel: [*11/29/2021 23:18:44.2488] AP IPv4 Address updated from 172.20.74.13 to 172.20.74.248
Nov 29 23:18:44 kernel: [*11/29/2021 23:18:44.2497] systemd[1]: Starting dnsmasq watcher...
Nov 29 23:18:44 kernel: [*11/29/2021 23:18:44.2512] systemd[1]: Starting ntp watcher...
Nov 29 23:18:44 kernel: [*11/29/2021 23:18:44.2538] Cleanning up DTLS connection.
Nov 29 23:18:44 kernel: [*11/29/2021 23:18:44.3148] systemd[1]: Started ntp watcher.
Nov 29 23:18:44 dnsmasq[27033]: exiting on receipt of SIGTERM
Nov 29 23:18:44 kernel: [*11/29/2021 23:18:44.3174]
Nov 29 23:18:44 kernel: [*11/29/2021 23:18:44.3174] CAPWAP State: DTLS Teardown
Nov 29 23:18:44 kernel: [*11/29/2021 23:18:44.3221] systemd[1]: Stopping DNSmasq for host...
Nov 29 23:18:44 kernel: [*11/29/2021 23:18:44.3263] systemd[1]: Starting DNSmasq for host...
Nov 29 23:18:44 dnsmasq[31042]: started, version 2.82-6-ge9db3fd cachesize 150
Nov 29 23:18:44 dnsmasq[31042]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-nettlehash no-DNSSEC loop-detect inotify dumpfile

[Sandeep Choudhary]

Hi,

Normally if the AP loses connectivity to the WLC it will directly try to use the DHCP IP address instead of the statically configured IP address. I suspect that there is some heartbeat loss and when that happen the AP directly falls back to use the static. Usually there is a number of heartbeat loss (3 for example) before declaring the AP as disassociated. In this case what happens it seems the AP loses one heartbeat (not 3) and directly falls back to use the DHCP instead. Check the traplog/msglog. If there is any heartbeat loss it will probably be reported.

Additionally, make sure that the DHCP scope does not overlap with some static IPs that are being already used by some other APs. If so then the disassociation is pretty normal due to the IP conflict and the AP falls back to the DHCP and get an IP address that does not conflict.

Regards

Dont forget to rate helpful posts

[XJoss]

Hi, Thanks for reply my discussion.

Regarding heartbeat, if you mean an event between AP and WLC is not connected. So the answer is Yes, because some time ago I saw that the AP was not on the WLC wireless list. Then they appear again after a while later with the IP change to DHCP.

If that's the case what are you going to do so they don't change to DHCP again?

[Rich R]

You obviously need to resolve the connectivity issue because that what is causing the problem.

As far as I know you cannot disable the fallback behaviour - that is by design.

Worth remembering that using DHCP is the Cisco recommended best practice so the AP recovery behaviour is based on the assumption that the APs are/should be using DHCP.

[MHM Cisco World]

follow

[Haydn Andrews]

Best practice if you want the APs to have static IP is via DHCP reservations. As mentioned above if the AP loses connectivity to the WLCs it will attempt DHCP to try and get option 43.

Also ensure if you have multiple DHCP servers servicing the subnet that the reservations are on both of them