topic Scenario 1If all of the AP's in Wireless

Load-Balancing between Foreign and two Anchors

acontes — Mon, 05 Jul 2021 07:51:58 GMT

Hi, we have two foreign controllers (one active, one standby) and two anchor controllers. All APs are connected to the active foreign controller. The layer 3 networks for the wlan clients on both anchors are different for the same SSID. SSID: Internet, anchor 1: Subnet A, anchor 2: Subnet B. So when a client is getting anchored to Anchor 1, the clients will get an ip from subnet A and when the client is getting anchored to anchor 2, the client will get an ip from subnet B.

This is so far not a big problem because we only have a few accesspoints in some rooms. But what will happen, when we have a full covered wlan and the client roams from one AP to the other AP? Is there a possibility, that the client will anchored to a different anchor while roaming? I think this will result in a lack of connectivity because without a real disconnect the client will not ask for a new IP address.

Other question: Is it possible to disable this load-balancing between anchor controllers? Or can i make a client sticky to only one anchor as long as an access-session is established?

All controllers are 5760 with 3.3.3 software.

Scenario 1If all of the AP's

chestes — Sat, 31 May 2014 03:21:31 GMT

Topology?

WLC-A, Subnet-A <--EoIP--> Anchor A (DHCP PoolA)

WLC-B, Subnet-B <--EoIP--> Anchor B (DHCP PoolB)

Scenario 1

If all of the AP's remain on controller A and are Anchored to Anchor A, there will not be a problem.

Scenario 2

If AP's are evenly disbursed across the primary controllers, an inter-subnet roam will be performed, as follows:

The primary controller will perform a mobility hand off from controller A to B and proxy the IP address for the client, therefore, this should not cause a problem. You do want to make sure that DHCP required is not selected on the WLAN, otherwise it will break roaming since DHCP Required forces the client to obtain a new IP address on the subnet where the client has roamed to. If this is a guest network, it is a best practice to use DHCP required and therefore seamless mobility (roaming) is not intended to function.

This is the limitation to

Scott Fella — Sat, 31 May 2014 15:29:45 GMT

This is the limitation to having multiple anchors. You will not be able to specify a primary or secondary, so the foreign controller will decide in which to place the traffic between the multiple anchors.

Hi chestes,topology:WLC-A <-

acontes — Mon, 02 Jun 2014 05:03:53 GMT

Hi chestes,

topology:

WLC-A <--EoIP--> Anchor A (DHCP Pool A)

WLC-A <--EoIP--> Anchor B (DHCP Pool B)

This just matters. Ignore WLC-B because WLC-B is just the backup if WLC-A fails. If so, the topology is the same, just with WLC-B instead of WLC-A. Remember: All APs are connected to WLC-A. So under normal conditions, i have a one foreign, two anchors topology.

The main question is:

1) What happens if my clients roam and

2) Would it be better to choose the same DHCP Pool on both anchors?

3) How would you design this 🙂

Hi Scott,is this just in case

acontes — Mon, 02 Jun 2014 05:07:15 GMT

Hi Scott,

is this just in case of a new access session (initial client connection to wlc) or will the controller decide this also if there is already an access session on the wlc (client roams).

Hi acontes, It's an

chestes — Mon, 02 Jun 2014 06:40:37 GMT

Hi acontes,

It's an interesting question.

In this case, if all AP's are on WLC-A and there is no possibility that an L3 inter-subnet roam will occur between WLC-A and WLC-B, I would just forward WLC-A to Anchor A and WLC-B (in the event of fail over) to Anchor B (if Anchors reside on different subnets). If you must specify Anchor A and Anchor B on each WLC for redundancy purposes, it's important to understand the guidelines and limitations with regard to Foreign / Anchor Design.

As Scott mentioned, the limitation with Anchoring design is that there is no primary / secondary configuration for an Anchor on the Foreign WLC.

If WLC-A has two entries (1) for Anchor-A and (2) for Anchor-B, the EoIP tunnels are establish and load-balancing occurs in a round robin fashion.

Keep in mind the following with regard to guest N+1 redundancy:

•A given foreign controller load balances wireless client connections across the list of anchor controllers configured for the guest WLAN. There is currently no method to designate one anchor as primary with one or more secondary anchors.

•Wireless clients that are associated with an anchor WLC that becomes unreachable are re-associated with another anchor defined for the WLAN. When this happens, assuming web authentication is being used, the client is redirected to the web portal authentication page and required to re-submit their credentials.

Since traffic is transported at Layer 2 via EoIP, the first point at which DHCP services can be implemented is either locally on the anchor controller or the controller can relay client DHCP requests to an external server. Since the IP address directly correlates to the DMZ subnet or the interface where the traffic egresses, it is possible for some clients to get IP's from both Subnet A or Subnet B in the event that WLC-A is building EoIP to both anchors.

1) What happens if my clients roam?

Nothing... since all AP's are on WLC-A, it's Intra-Controller Roaming

Each controller supports same-controller client roaming across access points managed by the same controller. This roaming is transparent to the client as the session is sustained, and the client continues using the same DHCP-assigned or client-assigned IP address. The controller provides DHCP functionality with a relay function. Same-controller roaming is supported in single-controller deployments and in multiple-controller deployments.

Would it be better to choose the same DHCP Pool on both anchors?

It's probably better to have redundant anchors on the same subnet, but it's not required.

3) How would you design this 🙂

WLC-A <--EoIP--> Anchor A (DHCP Pool A)

WLC-A <--EoIP--> Anchor B (DHCP Pool A)

It's important to remeber what Scott mentioned about the lack of a primary / secondary relationship. If multiple controllers are added as mobility anchors for a particular WLAN on a foreign controller, the foreign controller internally sorts the controller by their IP address. The controller with the lowest IP address is the first anchor. For example, a typical ordered list would be 172.16.7.25, and 172.16.7.28. If the first client associates to the foreign controller's anchored WLAN, the client database entry is sent to the first anchor controller in the list, the second client is sent to the second controller in the list, and so on, until the end of the anchor list is reached. The process is repeated starting with the first anchor controller.

If any of the anchor controller is detected to be down, all the clients anchored to the controller are deauthenticated, and the clients then go through the authentication/anchoring process again in a round-robin manner with the remaining controller in the anchor list. This functionality is also extended to regular mobility clients through mobility failover. This feature enables mobility group members to detect failed members and reroute clients.

Re: This is the limitation to

clearcall — Wed, 04 Apr 2018 08:33:36 GMT

I know this is an old post but I believe since AireOS version 8.1x it is now possible to have more control of the anchor WLC's. I did a search and this post came up. I was looking for answers about having multiple anchors in different DC's but on the same subnet.

Re: This is the limitation to

Scott Fella — Wed, 04 Apr 2018 09:23:58 GMT

That is correct. Cisco has implemented a new feature that allows you to specify the anchor priority. Back then, this was not the case.