H-REAP Modes & Groups

 

Central Authentication – Central Switching (valid only in Connected Mode)

In this state, for the given WLAN, the access point forwards all client authentication requests to the controller and tunnels all client data back to the controller, as well. This state is valid only when the access point’s CAPWAP control path is up. This means the H REAP is in Connected mode. Any WLAN that is tunneled back to the controller is lost during WAN outage, no matter the authentication method.

AP reboots and joins back to WLC.

When the client from MO connects to H-Reap ssid gets an ip address from the HQ vlan12.

All traffic is tunneled back to HQ.

If the clients tries to access local resources all traffic is tunneled back to HQ.

(10.10.120.129 is a subnet in MO)

 

Authentication Down – Switching Down (valid only in Standalone mode)

In this state, the WLAN on a given H REAP disassociates existing clients and stops sending beacons and probe responses. This state is valid only in Standalone Mode.
In order to simulate the WAN failure we shut down interface (CAT2 fa0/22).

LWAP-4 looses connection to WLC2.
Client looses the connection and LWAP-4 switches to Standalone mode.

If we no shut the interface

 

 

Central Authentication – Local Switching (valid only in Connected Mode)

In this state, for the given WLAN, the controller handles all client authentication, and the H REAP access point switches data packets locally.

We change the ssid to Local Switching.

 

 

The port which the LWAP-4 is connected is still on vlan 121.

Now we see that the client receives address from vlan 121 and the traffic is locally switched.

 

Now lets create a new Vlan 21 on MO.

The client must now receive ip address from vlan 21.

In order to pass multiple vlans we need to change the fa0/4 connection to trunk.

 

Vlan Mappings

The client receives an ip address from vlan 21 and traffic is locally switched.

 

 

Authentication Down – Local Switching (valid only in Standalone Mode)

In this state, for the given WLAN, the H REAP rejects any new clients that try to authenticate, but it continues to send beacons and probe responses to keep existing clients properly connected.

This is true only for clients that are configured for any EAP method.

WPA/WPA2 PSK NEW clients can connect even though WAN link or controller is down.

 

Local Authentication – Local Switching (valid in Connected & Standalone Mode)

In this state, the hybrid-REAP access point handles client authentication and switches client data packets locally. This state is valid in Standalone mode and Connected Mode.

For 802.1x/WPA2 in Standalone Mode we need to configure H-REAP Groups.
ACS 5 located in HQ will handle the authentication requests. In case of WAN failure, Local Radius on H-REAP AP will take over.

I have created 2 users, one in ACS (user: leap-acs) and one in AP Local Authentication (user: hreap).

 

Now let’s test client’s connectivity.

Even though the AP is in Connected Mode, the authentication request sources from LWAP-4 and not from the WLC.
Let’s shut down the WAN link (CAT-2 fa0/22)

Now the AP will use it’s local database for client authentication.

 

 

 

If we try to associate a client to LWAP-2 (HQ/local mode) we notice that authentication request sources from WLC-4.

So H-Reap Local Authentication on WLAN effects only the H-Reap Aps.

Auto-Anchor

In this post wil see how Auto-Anchor Mobility works.

Objective is to force clients to be on a particular controller/subnet regardless of the controller they

access the wireless network from. In our case client connects to LWAP-4 /Branch and traffic is tunneled

back to to WLC HQ, client also gets ip from vlan 12 HQ.

Mobility ping tests.

When using the auto-anchor mobility (guest tunneling) feature layer 2 security is handled by the foreign controller

and layer 3 security is handled by the anchor controller.

Mobility Groups-Lists

A Mobility Group is a group of Wireless LAN Controllers (WLCs) in a network with the

same Mobility Group name. These WLCs can dynamically share context and state of client

devices, WLC loading information, and can also forward data traffic among them.

Wireless LAN Controllers (WLCs) can be configured only in one Mobility Group.

 

Mobility Group notes:

• Up to 24 WLAN controllers and 3600 APs are supported per mobility group.
  
• It is recommended all WLCs to run the same software version.
• A mobility group requires all WLCs in the group to use the same virtual IP address.
• Each WLC must use the same ‘mobility domain name’ and be defined as a peer in each others ‘Static Mobility Members’ list.
• In order for a wireless client to seamlessly roam between mobility group members (WLCs), a given WLAN’s SSID and security configuration must be configured identically across all WLCs comprising the mobility group.

A Mobility List (or Mobility Domain) is a group of controllers configured on a single controller that specifies members in different mobility groups. Controllers can communicate across mobility groups and clients can roam between access points in different mobility groups if the controllers are included in each other’s mobility lists. Controller software release 5.1 supports up to 72 controllers (71+1) in the mobility list of a controller and seamless roaming across multiple mobility groups. During seamless roaming, the client maintains its IP address across all mobility groups. However, Cisco Centralized Key Management (CCKM) and Proactive Key Caching (PKC) are supported only for intra−mobility−group roaming. When a client crosses a mobility group boundary during a roam, the client is fully authenticated, but the IP address is maintained, and EtherIP tunneling is initiated for Layer 3 roaming.

 

 

 

source:

Enterprise Mobility 4.1 Design Guide

http://mrncciew.com

 

Mobility Theory

As wireless clients move between APs on the same controller and APs join to different controllers within the network, four different types of roaming events can take place:

■ Intra-controller

■ Inter-controller (Layer2)

■ Inter-subnet/Layer 3 mobility event

■ Auto-anchor mobility

Intra-controller Roaming

If a client roams between APs on the same controller, it is called an intra-controller mobility event.

WLC simply update the database with client state & security context as client roam from AP1 to AP2.

Inter-Controller Roaming
Inter-controller roaming occurs when a client roams between two APs registered to two different controllers,where each controller has an interface in the client subnet.

During roaming the controllers exchange mobility messages (over UDP port 16666) and the client database entry is transferred from the original controller to the new controller.

 

Inter-subnet/Layer 3
Inter-subnet/Layer 3 occurs if the client roams between APs registered to different controllers and the client WLAN on the two controllers is on different subnets.

If a client is on WLAN-X on Controller-1 using VLANx and the client roams to WLAN-X on Controller-2, but WLAN-X on controller-2 is using VLANy, then an inter-subnet roam for that client occurs.

When the client roams between them, the controllers still exchange mobility messages.

Client database entry change is completely different that to L2 roam(instead of move, it will copy).

In this situation the original controller marks the client entry as “Anchor” where new controller marks the client entry as “Foreign“.

The two controllers now referred to as “Anchor controller” & “Foreign Controller” respectively.

Client will keep the original IP address & that is the real advantage.

Auto-anchor mobility
Auto-anchoring is when you anchor a WLAN to a particular controller in the mobility domain.

You can force clients to be on a particular controller/subnet regardless of the controller they access the wireless network from.

Perhaps the most common use for auto-anchor is with guest networking.

 

 

 

 

source:

Enterprise Mobility 4.1 Design Guide

http://mrncciew.com

Deploying and Troubleshooting Cisco Wireless LAN Controllers