Wireless Access

Good Morning,

 

I have a case logged with Aruba Support regarding an issue with iPads and iPhones (latest OS) and connectivity to an 802.1x enterprise network. To summarise:

 

ArubaOS (MODEL: Aruba3600), Version 6.1.2.7

 

Vlan1400                   10.147.0.0/24
Vlan1401                   10.147.1.0/24
Vlan1402                   10.147.2.0/24
Vlan1403                   10.147.3.0/24
Vlan1404                   10.147.4.0/24

 

SSID is assigned a vlan pool of the above.

 

- User device connects
- User authentication is successful
- User downloads Radius cert
- IOS device waits for an IP address
- **Using a static IP address, the user connects to network, web etc.**

 

logging level debugging network process dhcpd subcat dhcp
logging level debugging user-debug 40:b3:95:a7:c9:20
logging level debugging user-debug 40:b3:95:a7:c9:20 subcat configuration
logging level debugging user-debug 40:b3:95:a7:c9:20 process dhcpd

 

Detailed 802.1x Supplicant Information  

Name                                <removed>
MAC Address                         40:b3:95:a7:c9:20
AP MAC Address                      00:0b:86:77:ae:08
Status                              Authentication Success
Unicast Cipher                      WPA2-AES
Multicast Cipher                    WPA2-AES
EAP-Type                            EAP-PEAP

 

(config) #show log network 100 | include c9:20

May 14 16:17:05 :202541:  <DBUG> |dhcpdwrap| |dhcp| Received DHCP packet from Datpath, sos msg hdr flags 0x40 opcode 0x5a in0
May 14 16:17:05 :202534:  <DBUG> |dhcpdwrap| |dhcp| Datapath vlan1400: DISCOVER 40:b3:95:a7:c9:20 Options 37:0103060f77fc 394
May 14 16:17:05 :202546:  <DBUG> |dhcpdwrap| |dhcp| Datapath vlan1400: OFFER 40:b3:95:a7:c9:20 clientIP=10.147.0.90
May 14 16:17:05 :202546:  <DBUG> |dhcpdwrap| |dhcp| Datapath vlan1400: OFFER 40:b3:95:a7:c9:20 clientIP=10.147.0.90

May 14 16:17:06 :202541:  <DBUG> |dhcpdwrap| |dhcp| Received DHCP packet from Datpath, sos msg hdr flags 0x40 opcode 0x5a in0
May 14 16:17:06 :202536:  <DBUG> |dhcpdwrap| |dhcp| Datapath vlan1400: REQUEST 40:b3:95:a7:c9:20 reqIP=10.147.0.90 Options 34
May 14 16:17:06 :202548:  <DBUG> |dhcpdwrap| |dhcp| Datapath vlan1400: NAK 40:b3:95:a7:c9:20 clientIP=0.0.0.0
May 14 16:17:06 :202548:  <DBUG> |dhcpdwrap| |dhcp| Datapath vlan1400: NAK 40:b3:95:a7:c9:20 clientIP=0.0.0.0

May 14 16:17:16 :202541:  <DBUG> |dhcpdwrap| |dhcp| Received DHCP packet from Datpath, sos msg hdr flags 0x40 opcode 0x5a in0
May 14 16:17:16 :202534:  <DBUG> |dhcpdwrap| |dhcp| Datapath vlan1400: DISCOVER 40:b3:95:a7:c9:20 Options 37:0103060f77fc 394
May 14 16:17:16 :202546:  <DBUG> |dhcpdwrap| |dhcp| Datapath vlan1400: OFFER 40:b3:95:a7:c9:20 clientIP=10.147.0.90
May 14 16:17:16 :202546:  <DBUG> |dhcpdwrap| |dhcp| Datapath vlan1400: OFFER 40:b3:95:a7:c9:20 clientIP=10.147.0.90

May 14 16:17:17 :202541:  <DBUG> |dhcpdwrap| |dhcp| Received DHCP packet from Datpath, sos msg hdr flags 0x40 opcode 0x5a in0
May 14 16:17:17 :202536:  <DBUG> |dhcpdwrap| |dhcp| Datapath vlan1400: REQUEST 40:b3:95:a7:c9:20 reqIP=10.147.0.90 Options 34
May 14 16:17:17 :202548:  <DBUG> |dhcpdwrap| |dhcp| Datapath vlan1400: NAK 40:b3:95:a7:c9:20 clientIP=0.0.0.0
May 14 16:17:17 :202548:  <DBUG> |dhcpdwrap| |dhcp| Datapath vlan1400: NAK 40:b3:95:a7:c9:20 clientIP=0.0.0.0

 

I found some MS Tech blogs:

 

http://blogs.technet.com/b/teamdhcp/archive/2006/10/26/when-is-dhcp-nak-issued.aspx

 

“DHCP server will issue a NAK to the client ONLY IF it is sure that the client, “on the local subnet”, is asking for an address that doesn’t exist on that subnet.”

 

The DHCP scope has plenty of addresses available also.

 

This is a random issue, happening intermittantly, and seems to be isolated to iPads and iPhones.

 

When reviewing the DHCP logs, it shows the client mac sending mutltiple renews within the same vlan, but the server sending a NAK for each address. One address that was looked at was 10.147.0.90 and that was already leased to a client till 22nd of May???? I have no idea why the server would offer a client an address that is already leased.

 

My initial suggestion was to shorten the DHCP lease, which is currently at default of 8 days, this seems to long for me to a roaming wireless client.

 

If this rings any bells, or anyone has had the same experienve, it would be great to have some feedback.

 

Thanks.

I found this link which is something similar, but not entirely the same as to what I am seeing:

 

https://community.arubanetworks.com/t5/ArubaOS-and-Controllers/Erroneous-VLAN-tagging/m-p/15139/highlight/true#M6447

 

Just to show I have been searching, and searching, and searching, and searching......

 

Do you assign a static IPs using a VLAN pool with a set of VLANs or just one VLAN under the VAP ?

 

 

There is a vlan pool (Employee) with 5 /24 vlans assigned by MS DHCP. The VAP then references that pool:

 

(AMC1) #show wlan virtual-ap EMPLOYEE-VAP

Virtual AP profile "EMPLOYEE-VAP"
-----------------------------------------
Parameter Value
--------- -----
Virtual AP enable Enabled
Allowed band all
AAA Profile EMPLOYEE-AAA-PROFILE
802.11K Profile default
SSID Profile employee-ssid
VLAN EMPLOYEE-POOL

 

(AMC1) #show vlan mapping

Vlan Mapping Table
------------------
VLAN Name Pool Status VLAN IDs
--------- ----------- --------
EMPLOYEE-POOL Enabled 1400-1404

 

Thanks

 

David

 

 

You mentioned that you are assigning static IP addresses to those devices using a VLAN pool ?

Yes, as a test I assigned a static ip to an affected iPad mini. With a static IP address, no problem, web, internal mail, everything.

 

The failure is between the device being offered a valid IP, requesting it and being told "no you cannot have the IP address I have just offered you".

 

Perhaps there is some sort of VLAN tag issue? On the Core we have ip-helpers and all trunks are set correctly. I do not think it is a helper issue, as the server offers the client an address, but the request back from the client meets with a negative reply. In the DHCP server logs, there are many instance of iOS devices trying to request new or renew leases and getting NAK replies.

 

Have you tried just assigning one VLAN to VAP and see if still occurs ?

 

Are you using port-channels ?

 

Have you done any packet captures when this occurs ?

I have not tried reducing the VAP to one VLAN. Without making changes to scope size on the DHCP server, one /24 would fill quickly, but it is something we could test possibly. The renew/new request and NAK always stay rooted in the same vlan, the client does not hop between vlans making new requests. In this case VLAN 1400, 10.147.0.0/24.

 

No port channels to the controller, 1 physical GigE.

 

I intend to run "packet-capture udp 67,68" on my return on Monday.

http://community.arubanetworks.com/t5/ArubaOS-and-Mobility-Controllers/DHCP-Issues-Multiple-VLANs-for-single-VAP/td-p/34209

 

Out of interest, I was just checking on the load balancing per vlan mechanism. It's based on a MAC Hash.

Assigning the single VLAN I meant to try it in test VAP / test environment .

Do you see this issue on all the VLANs or on a particular VLAN?

Do you have other devices that are not experiencing this issue on that using those VLANs?

Thank you

Vic

Sure, thanks. I just wanted to also add that the afffected client I was testing with on the above could connect and get an IP in the Guest network with no problem. This is in a different vlan pool, but same vlan design with DHCP, accept using CP, not 802.1x.

 

There is Primary and Secondary Radius servers within the profile. Often, when "forgetting" a network in iOS, the client can switch between a radius cert from the primary, but sometimes get a cert from the secondary. I do see that quite often in iOS clients.

Please enable the following debugging commands:

Logging level debugging security
Logging level debugging user-debug <device MAC address>

and when this occurring can you run this command show auth-tracebuf | include <device MAC address>

Do you have other type of devices using those VLANs?

Good Morning:

 

May 20 08:27:19  station-up             *  40:b3:95:a7:c9:20  00:0b:86:77:b0:18                  -      -     wpa2 aes
May 20 08:27:19  eap-id-req            <-  40:b3:95:a7:c9:20  00:0b:86:77:b0:18                  1      5    
May 20 08:27:19  eap-id-resp           ->  40:b3:95:a7:c9:20  00:0b:86:77:b0:18                  1      15    UKSCROSSLE
May 20 08:27:19  rad-req               ->  40:b3:95:a7:c9:20  00:0b:86:77:b0:18                  65505  210  
May 20 08:27:19  rad-resp              <-  40:b3:95:a7:c9:20  00:0b:86:77:b0:18/LONPVMISRAD1  65505  90   
May 20 08:27:19  eap-req               <-  40:b3:95:a7:c9:20  00:0b:86:77:b0:18                  2      6    
May 20 08:27:19  eap-resp              ->  40:b3:95:a7:c9:20  00:0b:86:77:b0:18                  2      198  
May 20 08:27:19  rad-req               ->  40:b3:95:a7:c9:20  00:0b:86:77:b0:18/LONPVMISRAD1  98     431  
May 20 08:27:19  rad-resp              <-  40:b3:95:a7:c9:20  00:0b:86:77:b0:18/LONPVMISRAD1  98     239  
May 20 08:27:19  eap-req               <-  40:b3:95:a7:c9:20  00:0b:86:77:b0:18                  3      155  
May 20 08:27:19  eap-resp              ->  40:b3:95:a7:c9:20  00:0b:86:77:b0:18                  3      69   
May 20 08:27:19  rad-req               ->  40:b3:95:a7:c9:20  00:0b:86:77:b0:18/LONPVMISRAD1  31     302  
May 20 08:27:19  rad-resp              <-  40:b3:95:a7:c9:20  00:0b:86:77:b0:18/LONPVMISRAD1  31     191  
May 20 08:27:19  eap-req               <-  40:b3:95:a7:c9:20  00:0b:86:77:b0:18                  6      107  
May 20 08:27:19  eap-resp              ->  40:b3:95:a7:c9:20  00:0b:86:77:b0:18                  6      43   
May 20 08:27:19  rad-req               ->  40:b3:95:a7:c9:20  00:0b:86:77:b0:18/LONPVMISRAD1  65     276  
May 20 08:27:19  rad-accept            <-  40:b3:95:a7:c9:20  00:0b:86:77:b0:18/LONPVMISRAD1  65     218  
May 20 08:27:19  eap-success           <-  40:b3:95:a7:c9:20  00:0b:86:77:b0:18                  6      4    

 

There are many devices on the VLAN's, but in the main, the reporting of issues is coming from iOS users, iPad and iPhone.

 

I am having the server team decrease the DHCP lease time, as it is at default of 8 days currently. Aruba Support recommend 3-6 hours for a reasonably static network and a few Guest users passing through. This issues does not affect Guest users, or the above device on the Guest network....

Is there any update to this issue?

 

I'm experiencing the same thing with 6.2.1.2. All androids, windows, macs work 100% of the time and get a DHCP lease.

 

iOS is hit or miss. Some devices never respond to the OFFER. Some do. Same VLAN/DHCP server.

 

 

I am monitoring the situation. Since reducing the lease time on the Employee SSID DHCP scope to 4 hours, I have had no more issues reported to me, that's not to say they may not be happening, but the users have not seen any performance issues. On the Guest portal, the scopes were all 4 hours anyway, and iOS devices had no problem with that SSID.

 

Have you looked at the DHCP lease time? My current opinion is that the DHCP server (Microsoft) was not refreshing the releasing expired leases correctly. By reducing the lease time, the server is refreshing more regularly.

Thanks for the update. This seems so hit or miss with the iOS device. I had an older ipad running 5.x software that would never get an IP, then some various devices that may or may not. Debug logs show the lease being offered.

 

I will have the customer lower the lease time and monitor. Thanks