C9800-CL: client don't get IP address from internal DHCP server

[Tenere]

Good morning from Germany,

in my homelab I noticed that one client (only one) don't get an IP address from my C9800-CL (17.9.1). All other clients (phones, laptops, a camera, even a washing machine) can connect like desired.

My setup:
I have a C9800-CL (17.9.1) with two 9115AIX. The clients asociating with the WLAN in question (172.20.2.0/24; VLAN100) get their IP adresses from the internal DHCP server on the C9800. In policy profile of the mentioned WLAN in the Advenced tab the checkbox "IPv4 DHCP Required" is ticked and the IP address of the C9800 (192.168.178.229) is registered in the field "DHCP Server IP Address". The size of the DHCP scope is sufficient.

Processing the radioactive trace in the Cisco Wireless Debug Analyzer shows the following:

2022/09/09 05:01:56.830	client-orch-sm	Client made a new Association to an AP/BSSID: BSSID 5ce1.76d7.0be3, WLAN Guest_Access, Slot 0 AP 5ce1.76d7.0be0, AP-01-EG
2022/09/09 05:01:56.831	dot11	Association success for client, assigned AID is: 3
2022/09/09 05:01:56.831	client-orch-sm	Client started layer 2 authentication (either dot1X or PSK)
2022/09/09 05:01:56.838	client-keymgmt	Sent M1 for EAPOL 4-Way Handshake
2022/09/09 05:01:56.842	client-keymgmt	Received and validated M2 for EAPOL 4-Way Handshake
2022/09/09 05:01:56.842	client-keymgmt	Sent M3 for EAPOL 4-Way Handshake
2022/09/09 05:01:56.846	client-keymgmt	Received and validated M4 for EAPOL 4-Way Handshake
2022/09/09 05:01:56.846	client-keymgmt	Negotiated the following encryption mechanism: AKM:PSK Cipher:CCMP WPA Version: WPA2
2022/09/09 05:01:56.846	client-auth	Client successfully completed Pre-shared Key authentication. Assigned VLAN: 100
2022/09/09 05:01:56.846	client-orch-sm	Client passed layer 2 authentication
2022/09/09 05:01:56.846	client-orch-sm	Policy profile is configured for local switching
2022/09/09 05:01:56.846	client-orch-state	Starting Mobility Anchor discovery for client
2022/09/09 05:01:56.848	avc-afc	AVC is enabled for the client session
2022/09/09 05:01:56.849	client-orch-state	Entering IP learn state
2022/09/09 05:01:57.697	auth-mgr-feat_dsensor	Not performing DHCP profiling as it is not enabled
2022/09/09 05:01:57.697	sisf-packet	Sending DHCP Discover to: 255.255.255.255 on vlan 100 through gateway 0.0.0.0
2022/09/09 05:01:57.697	auth-mgr-feat_dsensor	Not performing DHCP profiling as it is not enabled
2022/09/09 05:01:57.697	sisf-packet	Sending DHCP Discover to: 255.255.255.255 on vlan 100 through gateway 0.0.0.0
2022/09/09 05:01:59.956	auth-mgr-feat_dsensor	Not performing DHCP profiling as it is not enabled
2022/09/09 05:01:59.956	sisf-packet	Sending DHCP Discover to: 255.255.255.255 on vlan 100 through gateway 0.0.0.0
2022/09/09 05:02:04.602	auth-mgr-feat_dsensor	Not performing DHCP profiling as it is not enabled
2022/09/09 05:02:04.602	sisf-packet	Sending DHCP Discover to: 255.255.255.255 on vlan 100 through gateway 0.0.0.0
2022/09/09 05:02:12.926	auth-mgr-feat_dsensor	Not performing DHCP profiling as it is not enabled
2022/09/09 05:02:12.926	sisf-packet	Sending DHCP Discover to: 255.255.255.255 on vlan 100 through gateway 0.0.0.0
2022/09/09 05:02:30.516	client-iplearn
2022/09/09 05:03:32.586	auth-mgr-feat_dsensor	Not performing DHCP profiling as it is not enabled
2022/09/09 05:03:32.586	sisf-packet	Sending DHCP Discover to: 255.255.255.255 on vlan 100 through gateway 0.0.0.0
2022/09/09 05:03:34.766	auth-mgr-feat_dsensor	Not performing DHCP profiling as it is not enabled
2022/09/09 05:03:34.766	sisf-packet	Sending DHCP Discover to: 255.255.255.255 on vlan 100 through gateway 0.0.0.0
2022/09/09 05:03:38.206	auth-mgr-feat_dsensor	Not performing DHCP profiling as it is not enabled
2022/09/09 05:03:38.206	sisf-packet	Sending DHCP Discover to: 255.255.255.255 on vlan 100 through gateway 0.0.0.0
2022/09/09 05:03:45.256	auth-mgr-feat_dsensor	Not performing DHCP profiling as it is not enabled
2022/09/09 05:03:45.256	sisf-packet	Sending DHCP Discover to: 255.255.255.255 on vlan 100 through gateway 0.0.0.0
2022/09/09 05:03:56.850	client-orch-sm	Controller initiated client deletion with code: CO_CLIENT_DELETE_REASON_IPLEARN_CONNECT_TIMEOUT. Code means: Client timed out while trying to get an IP address
2022/09/09 05:03:56.854	dot11	Disassociation packet sent with code status: 108

To me it looks like the client associates with the AP but the DHCP server don't get the Discover. As mentioned this is the only client which causes trouble.

Please advise and any hints and comments are welcome!

Regards,

Jörg

[marce1000]

 - Check network settings for the particular client , make sure that  the dhcp is set in network settings (/configured) to acquire an address.

 M.

[Tenere]

Hallo M.,

thanks for your answer.

I can't really check the network settings. I can only connect to the client with an app (Siemens HomeConnect) where I can only specify SSID and PSK.

The client expect a DHCP server.

Jörg

[marce1000]

                                >....I can't really check the network settings.

 I am sorry but consider this a 'vital initial step' , for tracking the problem ,  also check this bug report https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvt37259 , finally albeit being a single client problem it is always useful to review the current C9800-CL configuration with the CLI command : show  tech   wireless , have the output analyzed by  https://cway.cisco.com/tools/WirelessAnalyzer/  , please note do not use classical show tech-support (short version) , use the command denoted in green for Wireless Analyzer.               Checkout all advisories!

 M.

 M.

[Tenere]

Thanks and I know that thos is vital! This app is designed for Joe Sixpack
I can rule out the bug. Tried the workaround w/o success. 

Obviously the output of "sh tech wireless" can't be processed by the Wireless Analyzer. The output is empty.

THANKS!!

[marce1000]

             >...Obviously the output of "sh tech wireless" can't be processed by the Wireless Analyzer. The output is empty.

 (Obviously ?) -> This usually doesn't happen and I have  mentioned it to lots of people so far. Make sure the wireless is appended to the end of the show tech  command as mentioned, make sure the file input to Wireless Analyzer is native and does not contains something else.

 M.

[ammahend]

Seems buggy, disable DHCP required and try again see if it gets DHCP address. 
I am assuming other clients getting address are in same vlan 100

[Tenere]

Exactly.
All other clients are in VLAN100.
I tried to disable DHCP required without success.

[ammahend]

I had a similar issue in different iOSxe platform, clearing dhcp binding resolved the issue for me. You can give it a shot. 

[Tenere]

Thanks for the hint.

But unfortunately there is no DHCP binding for this network configured.

[Rich R]

> All other clients are in VLAN100.
> But unfortunately there is no DHCP binding for this network configured.
If all the other clients are in the same VLAN 100 then you *must* have bindings for them if they are working.
- Get a packet capture of the DHCP to (if any) and from the client and take a close look at that.
- Debug the DHCP server on the WLC
https://www.cisco.com/c/en/us/support/docs/ip/dynamic-address-allocation-resolution/27470-100.html#anc87 (not all those may apply to 9800 and I would not "debug ip udp" because all your CAPWAP is UDP!)
- do a conditional packet trace on the DHCP packets from the client to see if IOS-XE is dropping them for some odd reason.
https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-9/config-guide/b_wl_17_9_cg/m_debug_ra_ewlc.html#id_97897

[Tenere]

Hello,

of course there's a binding but I mixed it up with "mac/ip static binding" in DHCP. Sorry for the confusion.

The client is still stuck in "IP learning state" but I have no idea how to debug the internal DHCP.
I used this as a guide.

I gave up and set up a new WLAN which is now working as planned (internal DHCP, VLAN100, everything's fine).

BUT

I set up another VLAN (VLAN20), configured a SVI and WLAN for VLAN20, configured a new DHCP scope on the internal DHCP server and copied the settings from the WLAN on VLAN100 by hand. Now all clients stuck in IP learning state.

TimeTaskTranslated

2022/09/27 10:33:39.977	client-orch-sm	Client made a new Association to an AP/BSSID: BSSID 5ce1.76d7.0bef, WLAN IoT, Slot 1 AP 5ce1.76d7.0be0, AP-01-EG
2022/09/27 10:33:39.978	dot11	Association success for client, assigned AID is: 5. Client performed fast roam.
2022/09/27 10:33:39.991	client-keymgmt	Negotiated the following encryption mechanism: AKM:FT-PSK Cipher:CCMP WPA Version: WPA2
2022/09/27 10:33:39.991	client-auth	Client successfully completed Pre-shared Key authentication. Assigned VLAN: 20
2022/09/27 10:33:39.991	client-orch-sm	Policy profile is configured for local switching
2022/09/27 10:33:39.991	client-orch-state	Starting Mobility Anchor discovery for client
2022/09/27 10:33:39.994	client-orch-state	Entering IP learn state

I have no idea what is different as I crosschecked the settings several times.

Does anyone have an idea what I've done wrong??

Regards,

Jörg

[Rich R · Accepted solution]

You have the WLAN configured for local switching so DHCP is going out on the local VLAN on the switch which the AP is connected to.
Internal DHCP can only ever work for a centrally switched WLAN.

2022/09/27 10:33:39.991

client-orch-sm

Policy profile is configured for local switching

[Tenere]

No, I don’t. Yes, i did! 
I have two WLANs. One one VLAN1 and one on VLAN100. The WLAN on VLAN1 uses a central DHCP server, the other WLAN on VLAN100 uses the internal DHCP server.
Both are (now) working properly.

Yes, i did! 

VLAN 100 still used an external DHCP server I wasn't aware of that it was still active!

THANKS!