5508 WLC and Office Extend AP's

[spirotsares]

I have a 5508 wireless lan controller with a WPlus 100 AP license installed on it. The controller MGMT IP address is an internal IP (172.x.x.x).  I setup a 1:1 static NAT, with an externally accessible (208.x.x.x) being translated to the inside mgmt address (172.x.x.x) of the controller with ports  5246, and 5247 UDPports open.  I've connected the OEAP (1142)  to the controller inside my network (primed it) and set it to H-reap mode. I then selected the office extend ap under the H-reap tab as per the 6.0 config guide.In the High Availabilty tab I've put the name of the controller and the externally accessible IP (208.x.x.x).

When I connect the OEAP to the outside world I look under the montior -> statistics -> AP join page and I see the AP with a successfull discovery phase message :"Received Discovery request and sent response" However the Join phase statistics are all zeroed out. Is there something I'm missing? Does the controller have to be in the DMZ or have an external MGMT IP for OEAPs to join?

Thanks

Spiro

[George Stefanick]

Thanks Terry I didnt know that ...

This is only if you use a "inside" controller as your O/E controller as well. Correct ...

[jbeauchamp1]

weterry thanks so much that did the trick! I know OE is somewhat new to TAC, but wish I hadn't spent 4 hours + 2 more days without hearing from them. Cheers!

[weterry]

I'll see what I can do to spread the word about this particular "feature".  Unfortunately it is different in all 3 versions of 7.0, so that is greatly adding to the confusion.

[jbeauchamp1]

I still can't understand why the default wouldn't be disabled. The only time you would ever want it enabled is if you had a WLC dedicated for OEAP's in your DMZ....just food for thought. Thanks again, saved my bacon!

[ahmed.morsy]

• SOLVED 
• You can control the address(es) are sent in the CAPWAP discovery responses when NAT is enabled on the Management Interface using the following command:

config network ap-discovery nat-ip-only { enable | disable }

Here:

– enable — Enables use of NAT IP only in a discovery response. This is the default. Use this command if all the APs are outside the NAT gateway.

– disable —Enables use of both NAT IP and non-NAT IP in a discovery response. Use this command if APs are on the inside and outside the NAT gateway; for example, Local Mode and OfficeExtend APs are on the same Cisco WLC.

So ... run the following Command on the controller 

config network ap-discovery nat-ip-only disable 

I used v8.0.121.0 release this command solve my Problem 

[Vinay Sharma]

Hello,

For More information on OEAP-600, please watch the "Community Tech-Talk Series" Cisco Office Extend Access Point OEAP-600

https://supportforums.cisco.com/community/netpro/wireless-mobility/begin-wireless/blog/2012/02/24/cisco-office-extend-access-point-oeap-600

Thanks,

Vinay Sharma

Community Manager - Wireless

[trent.husking]

Hi,

The fix to this DMZ issues listed above have not worked for our new deployment. We have a dedicaed WLC2504 in a DMZ with a private IP assigned. A static NAT IP assigned and UDP-5246 and UDP-5247 are allowed.

The Firmware on the controller is 7.0.220.0.

The link below is also another reference document used however the discovery message back to the ap600 is the private address.

http://www.cisco.com/en/US/products/ps11579/products_tech_note09186a0080b7f10e.shtml

The syslog from the ap600 shows the incorrect discovery response at 13:56:56.719.

*Apr 10 13:56:46.751: CAPWAP State: Init.

*Apr 10 13:56:46.753: CAPWAP State: Discovery.

*Apr 10 13:56:46.779: Starting Discovery.

*Apr 10 13:56:46.780: CAPWAP State: Discovery.

*Apr 10 13:56:46.873: Discovery Request sent to [EXTERNAL_IP] with discovery type set to 0

*Apr 10 13:56:46.911: Discovery Response from [EXTERNAL_IP]

*Apr 10 13:56:46.912: Dot11 binding decode: Discovery Response

*Apr 10 13:56:56.719: Selected MWAR '[HOSTNAME]' (index 0).

*Apr 10 13:56:56.719: Ap mgr count=1

*Apr 10 13:56:56.719: Go join a capwap controller

*Apr 10 13:56:56.719: Choosing AP Mgr with index 0, IP = [INTERNAL_IP], load = 0..

*Apr 10 13:56:46.751: CAPWAP State: Init.
*Apr 10 13:56:46.753: CAPWAP State: Discovery.
*Apr 10 13:56:46.779: Starting Discovery.
*Apr 10 13:56:46.780: CAPWAP State: Discovery.
*Apr 10 13:56:46.873: Discovery Request sent to [EXTERNAL_IP] with discovery type set to 0
*Apr 10 13:56:46.911: Discovery Response from [EXTERNAL_IP]
*Apr 10 13:56:46.912: Dot11 binding decode: Discovery Response
*Apr 10 13:56:56.719: Selected MWAR '[HOSTNAME]' (index 0).
*Apr 10 13:56:56.719: Ap mgr count=1
*Apr 10 13:56:56.719: Go join a capwap controller
*Apr 10 13:56:56.719: Choosing AP Mgr with index 0, IP = [INTERNAL_IP], load = 0..

Has anyone else seen these issues with this version although is showing as being supported with this configuration?

Trent

[weterry]

Looks like you are seeing:

CSCts52998    WLC 2504 doesn't respond to discover requests with Public AP manager IP

Resolved in 7.0.230.0 or 7.2.103.0

[JASON WELCH]

I'm not sure if you ever got this working or not, but you also need this command entered at the command prompt of the controller that you enabled the NAT address on "

config network ap-discovery nat-ip-only disable"

This makes it so the controller will pass both the NAT address and the private internal address for CAPWAP discovery when an AP joins.  This works fine for me, I'm running version 7.2.103

Hope that helps.

[rchester]

looks good thanks

reload in 25 years

[rmueller@willkie.com]

Hi,

how can I force internal APs to use the internal management IP of the 5508 WLC (7.6.130.0)?

All works fine, internal and external OE600 APs can successfully join. But internal APs seem to prefer the NAT IP of the WLC which means they create their own tunnel from a remote office instead of using the company WAN which creates performance issues. A workaround is to block the NAT IP in the firewall of each remote office but it would be nicer if the WLC would tell the internal APs where to go in the first place.

Thanks!

[glen.leichty]

Robert,

We had the same issue, but only at our facilities that have direct internet access.  As all our internal AP's are assigned a static IP address in a specific range used only for AP's, we block internet access for those IP addresses on the firewall.  As the AP's cannot access the internet, they revert back to the internal address and connect without issue.

Hope this is helpful.