HREAP VLAN Mapping

[Jurgens L]

Hi,

I've searched around to see if someone else has experienced the same issue regarding HREAP AP's losing their VLAN mappings; however I could not find any related topics.

Scenario

I've got a 5508 WLC running ver 7.0 with local VLANs assigned as follow:

VLAN 241 - Data Users

VLAN 253 - Voice Users

The HREAP AP's (Cisco 1242AG) running at the remote branches is mapped to the following:

VLAN 2 - Data Users

VLAN 253 - Voice

The Problem...

HREAP works perfect; users get the local DHCP addresses at the branch office and have no issues with connectivity. Once and a while some of the HREAP AP's will lose the VLAN mapping I've assigned to them. In this case I've mapped VLAN 2 to the SSID for the Data Users, I will get complaints that users can't connect to the network when I go check the HREAP AP's VLAN mapping it defaulted back to VLAN 241 (the same VLAN the local AP's at head office use for the same SSID). Of course with the Voice SSID I don't have this problem as it's using the same VLAN ID as head office.

Once I've corrected the mapping everything works perfect.

Why...

I just want to know why this happens, I've rebooted the AP's to see if they retain the mappings and they did. I've seen in the HREAP design deployment that it is preferred to use the same VLAN ID's of the head office where the WLC is located as for the same to the branch offices where the HREAP AP's are located.

I can see why as this will resolve my problem, however this network was designed without the knowledge of HREAP being deployed to the remote sites and I would like to minimize change from a LAN perspective.

Will this be my only solution by standardizing the branch office VLAN ID's the same as the head office network or should I be able to use different VLAN ID's for the branch offices?

Thanks for your time reading this and for your input. If you know any discussion regarding this, please add the url.

Regards

Jurgens

[Surendra BG]

Hi Jurgens,

Most probably we are hitting the software bug.. CSCsw68997

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsw68997

We need to wait for the next release to get the fix..

lemme know if this answered your question..

Regards
Surendra
====
Please dont forget to rate the posts which answered your question and mark it as answered or was helpfull

[Jurgens L]

Thank You for you prompt response Surendra,

I see that in bug report you send me it was fixed in ver 6.0.200 and 7.0.112(23). I'll upgrade my old image (7.0.98.0) to the ones recommended.

Thanks Again

Jurgens

[Surendra BG]

Ok!! Lemme know how this helps..

lemme know if this answered your question..

Regards
Surendra
====
Please dont forget to rate the posts which answered your question and mark it as answered or was helpfull

[danilosavido]

Hi,

I'm having the same problem. And I have two WLCs (WISM) with 7.0.220 version.

I think because of this BUG: http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtw92394&from=summary

Anyone knows how can I solve this problem?

I Have 42 HREAP APs, and when I have some link problem on the remote Branch and the AP lose for a few seconds Connectivity to the 1º Controller its loses the VLAN Mappings (all turned to the Native VLAN).

[Jurgens L]

Hi There,

Try the following:

(Cisco Controller) >config advanced timers ap-primed-join-timeout ?

      Configures AP Primed Discovery Timeout value between 120 and 43200 seconds(12 hours).

Can you try this command on the WLC ( chose the maximum timeout )

[danilosavido]

Tks Simon,

But if I use, for example, a time of 3600 (1hour). If my 1º Controller Downs. The HREAP AP will take an hour to register to the second controller?

[Jurgens L]

Hi Danilo,

This won't have an affect on your HREAP heartbeat, if your heartbeat is set on the default (30 seconds) your AP will still use this to verify if it can still connect to the controller or not.

Regards

Simon