few questions regarding the H-REAP mode:
1. How many H-REAP mode AP's can be configured for 1 location?
2. Does H-REAP AP need some special settings from the network side? no NAT, static IP etc.?
3. which interface does the H-REAP AP should "see"? the management or the AP-Manager? or both?
Thanks in advance!
1. Depends on your software version. I believe it goes like this:
4.0 and previous = 3
4.1/4.2 = 8
5.0+ = unlimited
If anyone can confirm/correct this, that would be great :)
2. Each access point will now need to be connected to a trunk port, rather than connecting via an access port. No additional IP address policies are needed.
3. It should be able to see both the management and AP-manager interfaces. This should happen automatically, as they should really both be on the same subnet. Just make sure that the subnet is allowed on the access point trunk link, and make sure to extend that subnet out to the local switch.
4.1 and later is unlimited. Previous versions has a limit of 3. The only difference from a LAP in local mode is that the port is a dot1q trunk with the management of the LAP set to native vlan on the trunk port. WLAN will need to be configured for local switching and then once the ap is in h-reap mode, you must map the native vlan and the wlan ssid to a local vlan. this is done on the LAP H-REAP tab.
So how can i connect H-REAP, through my home connection into the controller located in my work?
in other words - can i connect H-REAP through the internet?
Aruba Networks has a similar solution called RAP which allows you to connect an AP through the internet along with split-MAC and local switching.
That is Aruba. Can't do it with the Cisco product. First, because you are NAT'd and second, you would have to open ports on your FW.
So if i want to summarize to limitations of the H-REAP:
1. no NAT between controller and AP's
2. maximum RTT 100ms
3. Works only on AP1130, 1240 and 1250
is that correct?
YES, you CAN perform H-REAP with NAT. However, as fella5 already mentioned, you can't do it with just plain old NAT, you must use static NAT and you cannot alter the destination ports. You should still be able to use multiple VLANs and trunks, but that will have to be routed by the time it hits the internet, and obviously won't work with standard SOHO equipment. I have tried this with a Netscreen firewall, and although I haven't had time to make it work, the join request made it to the controller. I used an additional public IP and only opened the necessary ports in the firewall for that IP. If I remember, the ports are 16666,16667,12222,12223 and 97. Here is an excerpt from the H-REAP Design and Deployment Guide (URL below):
Does H-REAP work behind a NAT? In a deployment where Static NAT is used, can the WLC and H-REAP AP be placed behind Static NAT?
Yes, for the AP. Make sure that the AP source ports are not changed during the operation time by the NAT device. Normally with static NAT, it is not an issue. However, take these points into consideration:
There are two main NAT'ed UDP dialogs between the AP and controller: LWAPP data and LWAPP control.
Source port in the AP is a temporary dynamic port (>1024). In the controller, it is a fixed destination port (12222, 12223).
UDP translations are based on timeouts. This means that a current entry is left created for an X amount of time then deleted if not used, which is based on the timeout (could be shorter or longer depending on which is your NAT device).
LWAPP control is active. In general, you would expect that it will send one packet each 30 seconds (echo keepalive). Thus, for NAT translations for LWAPP control, you can assume that it will keep the NAT timeout refreshed.
LWAPP data only sends traffic if there is activity. For APs without any clients around, the LWAPP data NAT translation entry can expire (for example, more than 90 seconds without activity), and the NAT device creates a new entry if the AP sends new traffic. If the new entry is the same source port number, then you will not have any problems. However, if the UDP source port changes, then the WLC will drop it, as now the LWAPP data tunnel information no longer matches what was created before when the AP joined controller.
Therefore, it works as long as your NAT device preserves the UDP source port for traffic between the AP and the WLC at all times, even after UDP translation has expired due to no activity. If not, the data traffic is dropped, and you will end with the AP joined to the controller, but no data traffic for wireless clients.