Clients Stuck on IP Learn (DHCP Troubleshooting)

[jbulloch]

Hi everyone,

In my quest to get cisco 9800 deployed, i have encountered a issue with DHCP.  I am looking for some advice on how to move forward with  troubleshooting. I am able to get EAP/DOT1X traffic to ISE and see clients authenticate,  but they never leave the 'IP learn'.  

Currently the device is setup for a single WMI with the default route pointing out, and a trunk link carrying L2 for vlans.  The SVI is on a "upstream" device and has holds the IP helper/relay. It is my understanding that with the 9800CL there is no need to disable any "dhcp proxy" setting as IOS XE will function in "bridge" mode automatically, if an interface with relay is not enabled. In the controller, i have "require dhcp" enabled (policy > advanced) but it is my understanding this is only required to force clients to need to use to dhcp, and therefore not allow any static addressing.

I've run a packet capture on the WMI interface and capture the capwap dhcp traffic. I've attached this below.  They are all discover broadcasts. I've run a capture on the SVI of the hosts and not seen any response traffic.  In an effort to attempt to troubleshoot further, i also attempted a relay and created an interface with an ip in the host's range and set an ip helper there. This resulted in the same results. I assume this is the only setup required for a relay.  I checked the DHCP server and see no hits for the clients mac in the leases. 

  I would like to run a capture on the DHCP server's interface, unfortunately it is in a remote data center and i am unable to access the connected switch. We will check out the ACL/other issue when we travel there next.  However, i am wondering where else to possibly make captures or troubleshoot the DHCP issue, as it appears the discovers are not being answered.

Thank you for your input.

[Saikat Nandy]

I would like to ask/point out few things but before that would you mind to share 'show tech wireless' from controller so that I can just have a look how the configuration is.

[jbulloch]

Hi saikat, 

Thanks for the reply again. I've attached the wireless. Is the 'central dhcp' slider in relation to local dhcp drop off? I suspected this morning this may be related, and am working to get a capture between here and the DHCP server. If a flex/local dhcp configuration is the issue, which settings are needed to be adjusted?

Again thank you.

[Saikat Nandy]

I have gone through your STW and I believe the issue is in the config. Here are the reasons - 

1. You are using 9800-CL. So the best practise is to keep the APs is flex mode. However all the APs are in Local mode.
2. If you really want to keep your APs in local mode, create a SVI for WMI and use Gig1 or Gig2 or both for data connection. Make sure the required vlans are allowed in the trunk.
3. If you shift towards Flex mode APs, there is no need for client SVI 116.
4. Policy Profile 'SYLAN-S1F-POL' is having AAA override & NAC enabled - do you really need this?
5. If you shift to Flex mode APs, you need to tweak the Policy Profile config as well + Need to create Flex profile

[jbulloch]

Hi saikat, again thanks for the assistance. Not sure cisco is paying you enough.

Yes, i have decided to use local mode. Our AP's are all talking back to ISE for IBNS/8X/MAB, and we have single pair at the core. It is my understanding the AP's on flex will be unable to authenticate anyone depending on mode for flex, as modes will allow sessions that exist to timeout in basis, and none will allow new dot1x clients to stay connected without use of a preshare so i am not sure what benefit it would otherwise have for us unless we put nearby AP's into a bridge mode.  Since our DHCP is also local to same core, went with local deployment and not flex profile. If we move to AP's at some remote sites, then possibly we can move to flex profiles at that time. 

I had enabled 116 SVI in an effort to use relay, to no success. I was using GI1 with IP in our  "server" range and then just GI2 L2 trunk for vlan traffic, as i understood with local there was no need for SVI on device due to DHCP bridge being done by helper upstream.

interface GigabitEthernet1
description WMI
no switchport
ip address 157.141.6.28 255.255.255.240
no ip redirects
no ip unreachables
negotiation auto
no mop enabled
no mop sysid
service-policy output AutoQos-4.0-wlan-Port-Output-Policy

Am i misunderstanding the SVI requirement here? 

[Saikat Nandy]

Under flex environment, you can have multiple scenarios and one of those is Central Auth - Local switching... means the client auth traffic will go from AP through the CAPWAP to WLC to AAA server and the same path will be followed for the return traffic as well. However the client traffic won't pass through CAPWAP and come to controller - it will pass from AP to switch to local core/router to internet and same path for return traffic. Traditionally people choose flex when they have controller and AP belonging to two different sites and talking to each other over SD-WAN, MPLS etc. But you can still do flexconnect even when AP and WLC belongs to the same site (in few cases this improves the endpoint throughput as well cz controller gets bypassed for data traffic). All you need is to ensure that required vlans are allowed in the AP switchport, rather than WLC switchport.
Since the issue is DHCP related, another very basic tshoot you can perform is by connecting a laptop directly to the switch where your APs are...put it in same vlan 116 and see if you are getting an IP address.

[jbulloch]

I believe you're suggesting not to use a routed interface after reading the post once over.

[Rich R]

Did you make any progress on this @jbulloch 
> I believe you're suggesting not to use a routed interface after reading the post once over.
SVI on WLC is not best practice (see the Best Practices link below)

If you're running 9800-CL on VMware ESX have you applied the required config tweaks on ESX (see the 9800 Install and Setup guides) and also mentioned in Best Practices?

Like @Saikat Nandy said make sure a LAN connected user can get an IP address first.  If not, then you need to solve the DHCP issue before looking at the WLC.