Configuring H-REAP (Cisco Wireless LAN Controllers) Part 2

Configuring the Local Switch

The configuration of the local network switch port that the H-REAP AP will be physically connected to depends on how you have configured the WLAN and H-REAP switching. If you are simply doing central switching, all you need is for the AP to be connected to an access port in the correct VLAN (a VLAN that can route to the controller from the remote network).

Setting the Native VLAN

Figure 13-8 Setting the Native VLAN

Mapping WLANs to Local VLANs

Figure 13-9 Mapping WLANs to Local VLANs

If you intend to only have a single locally switched WLAN or if multiple WLANs do not need wired side separation, you can use an access port. If you have multiple locally switched WLANs that need wired side separation or you do not want a single locally switched WLAN to use the same VLAN as the AP, configure an 802.1q trunk port instead.


Assume that you have a remote office with three VLANs. The remote network uses VLAN 10 for management, VLAN 20 for internal users, and VLAN 30 for guest traffic. The local Layer 3 switch also serves as the DHCP server (DHCP configuration not shown). You want the AP to be in VLAN 10 and have two WLANs on the controller that will be locally switched: one WLAN for internal users and one for guest users. To achieve this goal, the configuration for the local network switch should look like Example 13-3.

Example 13-3 Local Switch Example Configuration

Local Switch Example Configuration

The H-REAP AP would have its IP address in VLAN 10, either via DHCP or statically assigned, and this VLAN would be designated as the native VLAN for the AP on the controller. The management VLAN is the only VLAN at the remote location that needs to be routed across the WAN for the H-REAP AP to communicate with the controller.

H-REAP Guidelines and Limitations

You need to keep several guidelines and limitations in mind when deploying an H-REAP configuration on the network:

■ A H-REAP AP can be deployed with either a static IP address or a DHCP address. In the case of DHCP, a DHCP server must be available locally and must be able to provide the IP address for the AP at bootup.

■ As is true for all lightweight APs, the network link between the remote office and the controller network cannot be less than 128 kbps.

■ H-REAP supports up to four fragmented packets or a minimum 500-byte maximum transmission unit (MTU) WAN link. This is the same value as an AP in local mode. With the introduction of CAPWAP for the controllers in 5.2 code, Path MTU Discovery is supported.

■ Depending on the number of APs located at a remote site, Radio Resource Management (RRM) functionality may not work optimally. It takes at least four APs to trigger the Transmit Power Control algorithm. Dynamic Frequency Selection (DFS) and dynamic channel assignment (DCA) still function.

■ Roundtrip latency must not exceed 300 ms between the AP and the controller, and LWAPP/CAPWAP control packets must be prioritized over all other traffic.

■ H-REAP APs can perform 802.11 authentication and association functions locally and then proxy that information up to the controller when in connected mode. Call Admission Control (CAC) and Traffic Specification (TSPEC) functions may not be desirable because of this. A client will likely be allowed to associate, but then, provided CAC or TSPEC limitations have already been met, the client connections may be severed as mandated by the controller.

■ The advertised location accuracy of Cisco is not supported. The location algorithm accuracy increases with the number of APs, and the majority of H-REAP deployments will only have a few APs at a single location. This does not mean that location is not supported with H-REAP—only that the accuracy of the location might not be within 10 meters.

■ True multicast is not supported when using locally switched WLANs. Only Multicast-Unicast is supported.

■ To use CCKM fast roaming between H-REAP APs, you need to configure H-REAP groups.

■ Roaming between H-REAP can take as long as 50 ms to 1500 ms. Keep in mind that all authentications while in connected mode must cross the WAN, be processed by the controller or external device (RADIUS, NAC, and so on), and the access-accept be sent back across the WAN to the AP. So if the WAN link is right at the limit of 300 ms round trip and the clients are using a form of EAP authentication in which you have lots of packet exchange, you can imagine how slow a roam might be before the client can pass traffic again. To help decrease the roaming times, all H-REAP APs should be configured with the same local VLAN mappings so roaming clients will not have to re-DHCP. The use of H-REAP groups and CCKM will help mitigate this.

■ H-REAP APs support a 1-1 Network Address Translation (NAT) configuration. They also support Port Address Translation (PAT) for all features except true multicast. Multicast is supported across NAT boundaries when configured using the Multicast-Unicast option on the controller. When Multicast-Unicast is enabled on the controller, the controller unicasts any multicast traffic to each AP joined to it. This means that if you had 100 APs joined, the controller would replicate a multicast packet 100 times instead of simply forwarding the traffic to the AP multicast address if you were using Multicast-Multicast instead. Multicast-Unicast can obviously be resource intensive on the controllers and is not a recommended configuration. H-REAP APs also support a many-to-one NAT/PAT boundary, except when you want true multicast to operate for all centrally switched WLANs. Keep in mind that the AP can be behind NAT/PAT, but the controller the AP is registered with cannot be behind a NAT/PAT network boundary.

■ PPTP is supported for locally switched traffic, provided that these security types are accessible locally at the AP.

■ H-REAP APs support multiple service set identifiers (SSID).

■ NAC out-of-band integration is supported only on WLANs configured for H-REAP central switching. It is not supported for use on WLANs configured for H-REAP local switching.

■ The primary and secondary controllers for an H-REAP AP must have the same configuration. Otherwise, the AP might lose its configuration, and certain features (such as WLAN override, AP group VLANs, and so on) might not operate correctly. In addition, make sure to duplicate the SSID of the H-REAP AP and its index number on both controllers as well as any other controller the AP can fail over to in the event of a controller failure.

Table 13-4 shows which security features are supported or partially supported with the different modes and states H-REAP operation.

Table 13-4 H-REAP Supported Security Features

Feature

Connected Mode (Centrally Switched)

Connected Mode (Locally Switched)

Standalone Mode (Locally Switched)

CCKM

Yes (if AP groups are used)

Yes (if AP groups are used)

Yes (if AP groups are used)

CAC and TSPEC

Yes

Yes

Not supported*

RFID1/location-based services

Yes

Yes

Not supported

Client load-balancing

Not supported

Not supported

Not supported

Peer-to-peer blocking

Yes

Not supported

Not supported

WIDS2

Yes

Yes

Not supported

RLDP3

Yes

Yes

Not supported

RADIUS authentication

Yes

Yes

Yes (4.2 and higher)

TACACS+ authentication

Yes

Yes

Not supported

RADIUS/TACACS+ accounting

Yes

Yes

Not supported

*An AP in standalone mode does not follow CAC and TSPEC rules and allows all client connections. 1RFID = Radio Frequency Identification 2WIDS = Wireless Intrusion Detection Sytem 3RLDP = Rogue Location Discovery Protocol

Next post:

Previous post: