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.
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.
