We are having a problem w/ devices getting two ip addresses according to an 7210 controller running 188.8.131.52.
This appears to be exhausting our DHCP scope.
--Verify there is no rogue dhcp.
--Restarted DHCP server and recreated scope.
Our DHCP is a windows server. I'm leaning toward it's a controller/Clearpass issue. Has anyone experienced this or have any suggestions on troubleshooting the issue.
Where exactly are you seeing this?You could deny the users(a wireless client with an IP) from sending a DHCP discover.This ensures that after a wireless client receives an IP it will not send DHCP discover.This might solve your DHCP exhaustion.(Can be applicable to wired users as well).
Here is an example.
ip access-list session DHCPuser any udp 68 deny // blocks user from talking to DHCPany any svc-dhcp permit // Allows wireless client (without an IP) to receive an IP
--Give Kudos: found something helpful, important, or cool? Click Kudos Star in a post.--Problem Solved? Click "Accepted Solution" in a post.
That's a great idea and I'll consider that for future issues. Yesterday our AD team deleted lease because our DHCP server was maxed out. After deleting the leases we saw devices getting two ip addresses on the controller using the "show user-table mac" command. I feel this is a configuration problem/controller issue. I rebooted both of our controllers last night and hoping this fixes the issue. I've asked for escalation w/ Aruba TAC as they recommended "enforce dhcp". I will continue to monitor and troubleshooting. Please continue w/ the input. Thanks
Is the second ip address in the same VLAN space? Your dhcp server should honestly only be giving out one lease to a single mac address.
You might be having leases that are too long in the first place.
In the second place there are mobile devices that will show up in the user table with two ip addresses, one that is given by your dhcp server and another that is on the mobile interface. The ip address on the mobile interface may or may not be in the same range as your user space, but it should not consume an ip address on your dhcp server. "Enforce DHCP" should make it so that interfaces that do not request dhcp will not end up in the user table.
In summary, your leases might be too long (30 minutes to an hour typically is good) AND you need to have "Enforce DHCP so that secondary interface ip addresses on mobile devices do not show up in the user table.
It's within the same vlan. I rebooted the controllers last night and I'm not seeing any bad addresses at the moment but students are out and we have low traffic.
I'm not sure about the lease times, I think it was set to 8hrs and then they dropped it down to 4hrs.
If you want to kick off all of the users, no need to do a controller reboot, just do a "aaa user delete all".
If you are doing Captive Portal on that same VLAN, 4 hours might be too much, because drive-bys (people who associate, but never connect) will consume a lease.
That's a great idea. I've used that command just w/o the "all". Our guest network is seperate from our 802.1X network, the 4 hour lease is for the 802.1X network.
-Verified there is no rogue dhcp server.
-Verified settings on DHCP server.
-Conducted packet captures of controller uplink and server.
-Enabled enforce dhcp, fast age and deleted all users from user-table.
-Rebooted all controllers
-Checked global timers
-Active ticket w/ Clearpass, controller and our core router.
We are still having the issue. Yesterday I opened a ticket w/ Clearpass and they noticed two different ip's for a single user. The accounting packet was different that what the user had. According to them the controller was sending the wrong accouting packet. After noticing this they spoke w/ controller engineers and explained there is a "bug" in 184.108.40.206 that could be causing a problem. Something to do w/ openflow. The frustrating part is the previous day I had a conference call w/ escalated Aruba TAC support, they saw the issue and not once mentioned anything about errors w/ the code. I understand things don't run in a "perfect world" but communicate to your customers and being honest goes alot further in building trust and quality relationships with your customers.
I will respond back once we figure out a solutions
Please let TAC/your Aruba Sales Person know how you feel about the issue, so that they understand how you feel.
As a person who regularly troubleshoots customer issues both onsite and offsite, I can say there is a significant blind spot to troubleshooting over the phone.
Please keep us up to date on your progress.
After hours and hours of troubleshooting we confirmed that it's a bug w/ 220.127.116.11. We disabled openflow and it resolved our DHCP problem. Thanks for everyones help!
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2021 Hewlett Packard Enterprise Development LPAll Rights Reserved.