Thursday, October 28, 2010

Auto-Anchor Mobility Fundamentals

Having a fully redundant guest network architecture can be beneficial for service availability. Depending on business and operational requirements, many organizations use the guest architecture for purposes where traffic needs to be tunneled to a single point in the network, not necessarily just "guest" traffic in the traditional sense.

In a Cisco Unified wireless network deployment, this is accomplished with Auto-Anchor Mobility Tunneling by establishing Mobility peer relationships between internal production controllers and isolated controllers (typically in a bastion host or DMZ segment firewalled from the internal network). When using the auto-anchor mobility feature, these controllers do not need to have the same mobility group name because no layer 2 fast roaming or session state synchronization needs to occur between the controllers (layer 3 roaming is still performed to allow the IP address to be maintained by the client).


Typically, the DMZ anchor controllers are simply termination points within the isolated network segment and do not directly control any lightweight access points. This allows the DMZ anchor controllers to be smaller scale controllers, sized for bandwidth and throughput rather than AP licensing. Typically 4402-25 or 5508-25 controllers are used. Also, layer 2 roaming between APs on the controllers does not come into play.

Also, note that each production internal controller should have a mobility peer relationship with every other DMZ anchor controller to which it will send traffic. However, each DMZ anchor controller only needs mobility peers with each production internal controller, not with other DMZ anchors controllers.

Mobility communication between controllers occurs using their management interfaces, and uses the following protocols:

  • UDP 16,666 is used for Mobility control traffic between peers (Control Path)
  • IP Protocol 97 is used for Ethernet-in-IP traffic tunneling of client traffic (Data Path)

To setup the mobility peer relationship, navigate to the Controller > Mobility Management > Mobility Groups section. Add a new mobility group member by specifying the peer's management interface MAC address, IP address, and it's mobility group name (not the local one).


The status will initially show both the Control and Data paths down. Once communication is established, the status will show as "Up". Mobility peer connection establishment and keep-alive is performed at a periodic interval which defaults to every 10 seconds.

Note - The control and data paths may individually be shown as down if communication can be established using one protocol but not another. Check network ACLs or firewalls for traffic restrictions if this is the case.

To verify connectivity and peer kee-palive timers at any time, the following CLI commands may be useful:

  • mping peer-ip-address - used to test the Control Path between mobility peers
  • eping peer-ip-address - used to test the Data Path between mobility peers
  • show mobility summary - used to view mobility configuration and timers

Next, anchor the guest WLAN to multiple anchor controllers in the DMZ for round-robin client load balancing and redundancy. All mobility anchor controllers are used (active/active operation). This is accomplished from WLANs > WLAN Name Blue Arrow Drop-Down Button > Mobility Anchors.

On the production internal controller - specify one or more DMZ anchor controllers as the mobility anchors for the WLAN.



On the DMZ anchor controllers - specify its own IP address (local) as the mobility anchor for the WLAN since it will be the termination point for the client traffic.




It is also important to mention that the WLAN configuration on the production internal and DMZ anchor controllers all be identical with only one exception:

  • Interface - the production internal controllers should have the "management" interface assigned to the WLAN to allow the client traffic to be tunneled to the DMZ anchor controllers. The DMZ anchor controllers should have a dynamic interface assigned to the WLAN to forward client traffic out to the network (this is where clients will obtain IP addresses).

In a failover scenario, once the production internal controller recognizes that the anchor controller is no longer reachable (during the next keep-alive interval), it marks the anchor as Down, de-authenticates clients, forces client re-authentication, and anchors them to one of the remaining Up anchor controllers. Failover could occur because of a controller failure, or even failure of a single port link if not using link aggregation (LAG). In the event of a single port failure, the anchor controller migrates the affected logical interface to the backup port assigned to the interface. Production controller failover to other active DMZ anchor controllers does occur, but re-establishment of the mobility relationship occurs within 10 seconds once the backup port becomes active and new clients are allowed to terminate on the anchor again.

Note - this may result in clients obtaining a new IP address if the anchor controllers are not attached to the same client subnets (perhaps they are in different data centers for instance).

In my testing, failover occurs within 6-10 seconds of taking the anchor controller offline.

There are a ton of related features, requirements, and design considerations for auto-anchor mobility, but this should provide a basic overview.

Cheers,
-Andrew

22 comments:

  1. HOOOOOOOOOLY CRAPOLA batman. That's "all there is to it?" First, I love your blog...it's crazy thorough and always well-written. Posts like this one turn even my Wi-Fi centric brain inside out. Second, if Cisco makes Auto-Anchor any more complicated, we'll all need to go get that CCIE-Wireless to sort it all out. Good grief.

    Aerohive does this same thing with about 2 clicks in the GUI. I think several other Cisco competitors make this alot easier as well. Thanks for the heads-up on this - again, a very nice post. I didn't know Cisco made this quite so complicated. As we run into Cisco, where guest networking is a customer requirement, I need only to point the customer to this blog. :) If the customer is like me, they'll appreciate the detailed, educational nature of your blog and be shocked at the overly-complicated mess of Cisco's Auto-Anchor solution.

    Devin

    ReplyDelete
  2. Hi Devin,
    Actually, no, that's NOT all there is to it! There are a lot of other related guidelines and design decisions/recommendations that need to go into configuring auto-anchor mobility. Not to mention how the organization wants to handle guest account management, which gets complicated as well. (See my other blog post on this subject: http://revolutionwifi.blogspot.com/2010/08/scalable-guest-account-provisioning.html)

    To be sure, Cisco typically has the enterprise features for the most part, but understanding and configuring those features may not be "trivial". Most SMB or multi-hat network administrators will need help from a Cisco partner or Cisco directly to configure certain features.

    Only engineers that have the time and enthusiasm to focus on wireless networking in a Cisco-centric environment will be able to design and deploy everything on their own.

    As always, Devin, thanks for keeping things in perspective. It's always appreciated!

    -Andrew

    ReplyDelete
  3. Another enjoyable read.

    One question I have is whether you employ/come across guest account management solutions? This is to say that in many countries, typically Europe, there is a requirement to log Guest activity, in much the same way as we would with Corporate.

    The problem with this setup, as with other vendors, is that it is an enabler to secure communications over a network which you as an organisation are responsible for. So, if the Guest starts to engage in questionable activities, like downloading a load of MP3's, then you as the organisation is liable, unless you can prove the Guest (who was 'X') was on your network at this time visiting 'X' website.

    The only solutions I am aware of is using Cisco NAC to log the activity of the Guest user. This is typically too expensive, so are you aware of other solutions?

    ReplyDelete
  4. Hi Andrew,
    Logging guest activity is not really a network device function.

    For scalable guest account provisioning, see my previous post. You'll likely be interested in the Cisco NAC Guest Server because you have an audit trail of guest accounts that were provisioned.

    http://revolutionwifi.blogspot.com/2010/08/scalable-guest-account-provisioning.html

    Then, force acceptance of an acceptable use and liability policy by using L3 authentication, either through web authentication or web passthrough. Put the acceptable use policy right on the login page on the controller. If they click through then they have agreed to take liability for their actions.

    Use backend RADIUS authentication and accounting to log user access to the network. Also log DHCP leases. Then you can tie the IP address to MAC address via DHCP logs, and MAC address to user via RADIUS logs. Now you know what user actually used a given IP address at a specific time.

    Then you still need to log their activities online. For guest activity logging you would need an application layer proxy. I would suggest searching for "application proxy" or "web proxy" on the Internet. Some common ones are Microsoft ISA and Watchguard. Use this to block bad activity like P2P or file sharing, as well as to log what activities were performed by specific IP addresses at specific times.

    As an alternative, you could remove web authentication from the wireless controller and perform it on the web proxy instead. That way your logs may become much easier to correlate since the web proxy will have direct logs about the user's activities (rather than having to correlate DHCP, RADIUS, and web proxy logs).

    Finally, if you are approached about illegal activity, you have the user accepting liability as well as a trace of what user performed the activity in question. Demonstrating to authorities that you took proper preventative steps with the proxy and then logged the activity, they are unlikely to come after your company and go after the individual instead.

    Cheers,
    Andrew

    ReplyDelete
  5. Hi Andrew,
    Thanks for the very simple depiction of guest anchoring. We have a problem in one of our customer deployments with redundant DMZ controllers. When the primary internal controller fails and AP's failover to backup controller, the guest clients no longer get ip address. We have DHCP scopes (same subnet ) created on the two dmz controllers, but with different range of IP's from the same scope (eg: half of /24 subnet on dmz contrller 1 and half on dmz controller 2) . Is this the right way to do it ? Both the DMZ controllers are connected to the same DMZ switch. controller running latest 7.0 code. All eoip tunnels between internal and dmz controllers are up.

    regards
    Mannie

    ReplyDelete
  6. Hi Mannie,
    A redundant DMZ controller design works just as you described with non-overlapping DHCP scopes. It sounds like the issue is with the backup internal controller that APs failover to when the primary internal controller fails. On the backup, ensure that both DMZ controllers are up in the mobility group list, and also ensure that the WLAN mobility anchors are configured correctly.

    Andrew

    ReplyDelete
  7. thanks Andrew, Very nice blog and well explained,but how about the integration of IPV6 in the controller, is there any limitations??

    ReplyDelete
  8. Hi Lazhar,
    The Cisco WLC currently only support bridging of IPv6 traffic. No native capability exists to process this traffic. This results in some limitations of support for IPv6 including the inability to perform auto-anchor mobility.

    See the Cisco WLC configuration guide for version 7.0.116.0 for more information.

    Thanks,
    Andrew

    ReplyDelete
  9. Thanks Andrew For that information

    ReplyDelete
  10. Hi Andrew,

    by default if we have many Anchor Controllers the controllers round-robin between the multiple controllers in the anchor list, how we can turn off this behavior and make the anchor controllers as active / standby for a foreign controller. I don't want to round robin between them.

    best regards
    Lazhar

    ReplyDelete
  11. Hi Lazhar,
    Round robin load balancing is the only anchor method supported and it cannot be changed. There is no Active/Standby option available.

    Andrew

    ReplyDelete
  12. Hi Andrew,

    i have a DHCP issue with redundant Anchor configuration,i have a wireless topology with 2 anchor controllers with 2 differents scope DHCP, i've a client for example attached to Anchor 1 and have an IP address in scope 1, my issue is that when the Anchor controller 1 fail so the client will loose connectivity and he must renew his IP address to migrate to the second Anchor and have a new IP in the scope 2, have you Andrew any idea how to resolve this porblem without the contribution of the client.

    Thanks
    lazhar

    ReplyDelete
  13. Hi Lazhar,
    That is expected behavior. If an anchor controller is unresponsive, all clients previously tunneled to that anchor will be de-authenticated from the WLAN and forced to re-authenticate at which time they will be tunneled to a different anchor controller and receive a new IP address.

    Andrew

    ReplyDelete
  14. Hi Andrew

    we have a Anchor mobility configuration in place. We have created a WLAN SSID on the Anchor controller named x-WLAN, same SSID has been created on the foreign controller as well and pointed to the RADIUS server at Anchor WLC site for authentication. Anchor controller is conencted to the foreign WLC through the MPLS cloud. Users from site A where the achor wlc is hosted used to travel to site B where the foreign controller placed and they will connect to the WLAN SSID x-wlan from site B. users were able to connect to the wireless network all these days and suddenly reporting issues in connecting to the x-wlan ssid now from site B, where as users at site A are still able to connect to x-wlan ssid. We have checked and obsereved below log messages on the site B WLC (foreign controller).

    12 Wed Jan 11 12:27:34 2012 RADIUS server 10.255.160.65:1813 deactivated on WLAN 1
    13 Wed Jan 11 12:27:34 2012 RADIUS server <> failed to respond to request (ID 224) for client 00:21:5d:c9:93:d4 / user 'unknown'

    Can you please advise on this.

    ReplyDelete
  15. Hi Chandru,
    Based on your logs, it appears you have a RADIUS server issue or an issue with the connection between the foreign controller and RADIUS server (if using layer 2 security on the WLAN being referenced). See if the RADIUS server is alive, or if the foreign WLC can reach the RADIUS server through the MPLS cloud.

    If you need further help you should open a case with Cisco TAC.

    Andrew

    ReplyDelete
  16. Hi,

    First of all thanks for the info its great.

    I have been asked to look at trying to converge two separate wireless networks. They want their corporate SSIDs available at both sites by anchoring the corporate SSID to the anchor controllers at the respective sites. this is due to members of both companies regularly visiting each others sites.

    From what ive read I wouldnt be able to use auto anchoring on a WLAN that uses say EAP-TLS as its authentication method, it has to be web authorization and nothing else, is this correct?

    many thanks in advance,

    Matt

    ReplyDelete
  17. Hi Matt,
    You definitely CAN use auto-anchoring for 802.1X/EAP secured WLANs. You configure the mobility anchor for the WLAN the same as you would for a guest WLAN (using the blue drop-down arrow).

    I wrote these two articles that you should read:
    Auto-Anchor Mobility Fundamentals
    Cisco Mobility Tunnel Client Authentication

    Cheers,
    Andrew

    ReplyDelete
  18. Hi Andrew,

    I have gone through your blog and fixed one of the issue with my configuration about interface. However, Clients connected to remote WLC appears on Anchore AP and also trying for DHCP but they are not getting any DHCP addresses. I am really clue less. I have open a discussion on cisco learning today to get some help. Below is the link.
    https://learningnetwork.cisco.com/message/274074#274074

    This link has some output as well. I am not sure what needs to be done to get this DHCP working.

    Can you please help me out with this ?

    Kind Regards,
    Nilay Vyas.

    ReplyDelete
  19. Hi Andrew have you ever encaunter architecture were you created local clients on Anchore WLC to enable for them quest acces? Also other question is if in such architecture you enter backup Anchore controller, is it possible for Anchors databse clients be updated at the same time, on both controllers ?

    Maybe it would be simple by this explanataion: Two anchors in DMZ, one primamry and backup, We created local clients base on primary anchors can it be propagated to backup anochre automatically ?

    ReplyDelete
    Replies
    1. Hi Blazej,
      WLCs do not synchronize their configuration or local user databases. Therefore, you will need to use Cisco NCS or Prime Infrastructure to create configuration and user templates and push them out to multiple WLCs at once to ensure they are consistent.

      Or, you could use an external database (such as RADIUS or LDAP) instead as the single point that both Anchor WLCs authenticate users against.

      Cheers,
      Andrew

      Delete
  20. Hello,

    What would you recommend me setting up for a small office with 2-3850 switches with the mobility license and 2-3702's ap. WE just purchaed the controller mobility license for the switch. We would like to have one corporate SSID and Guest. The guest i'm confused about, so if i wanted to purchase an anchor controller to separate it out... How would the guest anchor talk to the AP's? The AP's will be connected to the 3850 and obviously used for the corporate wifi, but how would the guest anchor controller talk to the aps?

    ReplyDelete
    Replies
    1. Hi Joey,
      You can implement a Guest SSID in a few different ways. The simplest would be a separate guest VLAN on your local network on the 3850s and any upstream router/firewall. You would configure the Guest WLAN to assign clients into the guest VLAN and have the layer 3 gateway or firewall filter traffic through an access control list (ACL) to prevent internal access.

      Second, you could use auto anchor mobility and tunnel guest traffic into a remote DMZ network segment that is attached to a separate anchor controller (e.g. a Cisco 2504, 5508, 5520, 5760, etc.). You would configure the local controllers and anchor controller in a mobility group and configure the WLAN to forward all traffic to the anchor controller in the DMZ. This would be done by the 3850 sending the traffic inside a CAPWAP mobility tunnel to the anchor controller. The APs wouldn't communicate directly with the anchor controller. You can see which controller you may need as an anchor controller based on your size/scale requirements here:
      http://www.cisco.com/c/en/us/support/docs/wireless/4400-series-wireless-lan-controllers/107458-wga-faq.html#qa2

      Cheers,
      Andrew

      Delete