WLC Marking Interfaces as Dirty

[A.Swinnen]

Hi all,

Our configuration is as follows:

- WLC 5508 (HA), release 7.3.112.0

- Cisco 2600 AP's

- 5 Interface Groups

- DHCP Proxy disabled on the WLC

Complaint:

Users sometimes loose their connection after idling their device. Disable/Enable of the WiFi settings on their devices.

Investigation:

Interfaces get marked as Dirty. If a user previously was connected to vlan 2000, but re-enables his device, the user is assigned vlan 2001 (within the same interface group). Interface vlan 2000 got marked as dirty while the user's device was idle. However, the device doesn't do a DHCP renew, so it tries to communicate with a wrong default gateway address.

Analysis of logging on the DHCP server shows that some devices intensively issue DHCPREQUEST message, typically for addresses in the 192.168.x.y range (while our WiFi network is entirely 10.0.0.0/8 addressed).  We suppose that this is caused by devices previously connected at home, and that the devices tries to reuse its previously assigned IP address. However our DHCP server seems to drop those requests (as it is non-authoritative for this subnet).

Questions:

- Does the WLC mark interfaces as dirty when it doesn't see response for those DHCPREQUEST messages? (after x times) Or does this only hold for DHCPDISCOVER messages?

- Can the values for marking interfaces as dirty be finetuned?

- Can an interface marked as dirty be cleared manually?

- We re-enabled the DHCP Proxy on the WLC. Will this resolve the issue (and not count DHCPREQUEST messages for addresses not matching the interface's subnet).

[Richard Atkin]

Hi Arnout,

Firstly, have you seen this document?

http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bb4900.shtml

Second, I suspect you're probably hitting the same 'sleeping client' problem that alot of others have encountered.  You can try to extend your WLC's ARP and Client Idle Timeout limits, but it doesn't always fix all the problems.  There's more support for sleeping clients coming in later versions of software.

To answer your specific questions;

1. It's based on a timeout (ie, no response to the DHCP Request)

2. Not really, the closest you can get to achieving this is via "config dhcp timeout"

3. No, but you can at least check it via "show interface group detailed [GroupName]

4. Possibly, but unlikely (depends on your network architecture and if you're using multiple DHCP Servers)

[Amjad Abdullah]

+5.
Your discussion is allowing me to see one of my problem's more clear.
I am having this dirty interface messages while I am not using interface groups!!
Now, saying if users come with a home PiP address and try to connect that really could be a valid point to investigate.
BTW, the interface in my case does not really go dirty since all clients work fine after receiving the trap and all can get an IP.
I think the dirty interface message should not appear if no interface groups are in use.
What do you think??

Thanks.

Amjad

Sent from Cisco Technical Support iPad App

[Richard Atkin]

Agreed Amjad; if you're not using interface groups I don't think you should see that message.

[A.Swinnen]

For clarity, I always the interfaces marked as Dirty on the CLI (sh interface group detail ). The are marked with an asterisk...

I did see the document RikJonATK mentioned, but I'd like to know in detail what the mechanislm for marking an interface as dirty is (aparemter values and types of messages to trigger ).

At present we only have 1 cluster of DHCP servers.

Which is the issue you are referring to withsleeping devices?

[Richard Atkin]

Interfaces are marked as dirty if the DHCP Server fails to respond three times in a row, with the timeout period for each attempt being configurable, but defaulted at 10 seconds.

The Sleeping problem is one where a Client is happily on the WLAN, but then goes to sleep for a long period of time (like shutting the lid on an iPad).  In this sleeping time, the Client is forgotten about by the infrastructure.  When the Client wakes up, it expects the infrastructure to 'just work' because it was previously authenticated, but this doesn't happen because it has been forgotten about.  This leads to a situation where Users get annoyed at having to frequently re-authenticate themselves.  Adjusting the timeouts in the WLC can help to a point, but 'proper' support for sleeping clients comes in a later software release.

[A.Swinnen]

After a few weeks running with DHCP Proxy enabled, I observe an increase in Dirty interfaces. At some times, 3 out of 4 interfaces in an interface group are marked as dirty.

I launched some packet sniffing on the Etherchannel connecting the WLC, and observe the following behaviour:

- Interface vlan 4 gets marked as dirty (for some odd reason, to investigate further)

- Clients connected to interface vlan 4 are pushed to other vlans. Assume Client 1 now pushed to vlan 3

- Client 1 issues DHCP Requests for it's address in vlan 4 (although it is connected to vlan 3)

- The DHCP Server doesn't respond, as the Relay Agent doesn't match the configured scop

- If this happens for a few clients, the WLC marks interface vlan 3 as dirty.

[Richard Atkin]

Tried turning DHCP Proxying back on?

[Freemen]

Hi guys,

So what is the solution for this Issue? Kindly advice

[Scott Fella]

If you look at your dhcp server, do you see any addresses being marked bad? Do you actually see the leases being all used? Maybe you need to lower your lease time down to like 16 hours and see if the problem still exists.

Sent from Cisco Technical Support iPhone App

[A.Swinnen]

Hi,

DHCP is not full, but maybe some devices (BYOD) issue DHCPRequests for networks not matching our scopes (e.g 192.168.1.1). Off course our DHCP servers drops those (inapropriate) requests...

DHCP Proxy enabled or disabled doesn't change anything...

[Scott Fella]

That isn't normal, but since your using the HA feature, anything is possible.  The stability isn't there yet and your best bet is to upgrade to v7.4.100.60 and see if that helps.  Before you do that, please do read the release notes as you will have to disable AP SSO and upgrade each WLC and then enable AP SSO again.  The latest has many fixes for HA, but not 100%.

Thanks,

Scott

Help out other by using the rating system and marking answered questions as "Answered"