Centralized Traffic Flow with Guest Access (Cisco Wireless LAN Controllers) Part 1

In normal mobility, the first controller the client associates with will become its anchor. The auto-anchor feature allows you to force all clients accessing a specific WLAN to be tunneled to the same controller.

Auto-Anchor/Guest Tunneling

The auto-anchor/guest tunneling feature allows you to anchor the guest WLAN to a separate controller in the demilitarized zone (DMZ). Figure 14-16 shows a basic guest tunneling setup and the logical traffic flow. The anchor controller handles client DHCP and authentication.

Guest Tunneling

Figure 14-16 Guest Tunneling

In Figure 14-16, both the corporate user and the visitor are accessing Internet resources. The corporate user traffic is bridged by the controller directly onto the wired network. The visitor traffic, however, is sent to the anchor controller in the DMZ via an Ether IP tunnel, and the anchor controller bridges it to the DMZ network. The network firewall is configured to allow UDP 16666 and Protocol 97 traffic between the two controllers (covered in detail later in the "Troubleshooting Guest Tunneling" section of this topic). Because the anchor controller handles client DHCP and authentication, the laptop of the visitor has an IP in the DMZ VLAN range. Figure 14-17 shows a client DHCP discovery Ether IP packet between a foreign and anchor controller.


A single anchor controller can support up to 40 simultaneous Ether IP tunnels at one time. This means you can have 50 foreign controllers anchored to a single anchor controller, but only 40 of the foreign controllers can have active Ether IP tunnels to the DMZ.

Client DHCP in Ether IP, Packet 1912 Configuring Auto-Anchor

Figure 14-17 Client DHCP in Ether IP, Packet 1912 Configuring Auto-Anchor

Before you can designate a controller to be an auto-anchor for your guest WLAN, that particular controller needs to be listed in the mobility domain for the foreign controller.After you do that, to anchor your guest WLAN, first disable the WLAN and then go to WLANS > Advanced > Mobility Anchors. Then select the IP address of your anchor controller from the dropdown list and click on Mobility Anchor Create. The mobility anchor configuration page is shown in Figure 14-18.

An important configuration step that is often misunderstood is that the anchor controller should only have a mobility anchor configured as local. It should not have the foreign controllers configured as a mobility anchor. The foreign controller should only have the anchor controller(s) configured as mobility anchors for the WLAN. It should not have a local anchor configured. If this configuration is incorrect, you can create an anchoring loop as the controllers round-robin between the multiple controllers in the anchor list.

When multiple controllers are added as mobility anchors for a particular WLAN on a foreign controller to provide load balancing and redundancy, the foreign controller internally orders the anchors by their IP address and round-robins between them. The controller with the lowest IP is the first anchor. For example, 172.16.7.25 is first, 172.16.7.28 is second, and 192.168.5.15 is third. When the first client associates to the anchored WLAN of the foreign controller, that 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.

Mobility Anchor Configuration

Figure 14-18 Mobility Anchor Configuration

The process then begins again starting with the first anchor controller. Should one of the anchor controllers be detected as down, all the clients anchored to that particular anchor are deauthenticated by the foreign controller so that they go through the authentication and anchoring process again to a live anchor controller. You can verify the mobility configuration using the special ping commands eping and mping. These commands are described in detail in the next section.

Troubleshooting Guest Tunneling

In addition to all the possible issues mentioned earlier that can break web auth, added complexities are introduced with guest tunneling. Not only do you need to use the same debugs and troubleshooting methods outlined for basic web auth.

For guest tunneling to function, certain guidelines need to be met:

■ Controllers should run the same version of code. Starting with code Release 5.2, a foreign controller can have an anchor controller running 4.2 or higher code. This means a 6.0 controller can have auto-anchoring configured to controllers running 4.2, 5.0, 5.1, 5.2, and 6.0 code.

■ The controllers need to be in the same mobility domain.

■ The anchor and foreign controller do not need to be in the same mobility group.

■ If a firewall is involved, ports 16666 (16667 if using secure mobility) and protocol 97 must be allowed bidirectionally between the IP addresses of the controller management interfaces.

■ The guest WLAN configuration must match between the foreign and anchor; that is, if DHCP required is selected on the foreign guest WLAN, you should select it on the anchor guest WLAN as well.

■ The 2000 and 2100 series controllers and network modules cannot be used as anchors but can be anchored to 4400 series controllers.

■ The guest WLAN on the anchor controller is anchored to itself.

■ The guest WLAN on the foreign controller is anchored to the anchor controller.

■ Web auth is the only Layer 3 security supported.

■ DHCP option 82 is not supported.

■ Prior to 4.2, mobility did not work with Network Address Translation (NAT). Mobility group lookup has changed to use the MAC address because NAT changes the source IP in the IP header.

A common misconception is that the anchor controller needs to be configured with the same mobility group name for guest anchoring to function. This is not the case. In fact, for security reasons, you actually want the mobility group names to be different. When you are configuring mobility between the foreign and anchor controllers, the output of show mobility summary on the two controllers should look like that in Examples 14-4 and 14-5.

Example 14-4 show mobility summary from Foreign Controller

show mobility summary from Foreign Controller

Example 14-5 show mobility summary from Anchor Controller

show mobility summary from Anchor Controller

 

 

show mobility summary from Anchor Controller

Notice that the mobility group name configured for each controller in the other controller’s mobility summary matches the default mobility name for that particular controller. When mobility messages are exchanged between the controllers, the receiving controller is expecting to receive the packet from a particular MAC address, IP address, and mobility name from the other controller.

You might have noticed in the output of show mobility summary from both the anchor and foreign controller that symmetric tunneling is disabled. Based on that configuration, you would expect reverse path forwarding (RPF) to be an issue. With auto-anchoring, however, RPF does not come into play because auto-anchoring always uses symmetric tunneling. The symmetric tunneling configuration option applies only to normal foreign and anchor mobility situations as a client roams between controllers.

Example 14-6 shows an incorrect mobility configuration on the anchor, which means anchoring will fail.

Example 14-6 Incorrect Mobility Configuration on Anchor Controller

Incorrect Mobility Configuration on Anchor Controller

A common mistake is incorrect firewall rules blocking mobility and Ether IP traffic between the controllers. The firewall should allow UDP 16666 and protocol 97 and not port 97. Example 14-7 shows a sample ACL from an Adaptive Security Appliance (ASA).

Example 14-7 Sample ASA ACL to Permit Mobility Anchoring Between Controllers

ciscoasa(config)#access-list inbound extended permit UDP 199.199.199.0 255.255.255.0 10.0.10.0 255.255.255.0 eq 16666

ciscoasa(config)#access-list inbound extended permit UDP 199.199.199.0 255.255.255.0 10.0.10.0 255.255.255.0 eq 16667

ciscoasa(config)#access-list inbound extended permit 97 199.199.199.0 255.255.255.0 10.0.10.0 255.255.255.0

If the control path (UDP 16666/16667), data path (protocol 97), or both are down between the controllers, this is reflected in the mobility information. From the controller CLI, you can issue epings or mpings to test Ether IP and mobility, respectively. Packet captures, firewall logs, and TCP dumps can show if the epings and mpings are reaching the firewall, being passed to the DMZ controller, and vice versa. Mping and eping are not Internet Control Message Protocol (ICMP) pings; therefore, just because you can ping between the controllers does not mean that mping or eping should also work.

Example 14-8 shows sample output of control and data path issues on a controller. Example 14-8 show mobility summary Command Output Showing Some Mobility Issues

 shows sample output of control and data path issues on a controller. Example 14-8 show mobility summary Command Output Showing Some Mobility Issues

Mping sends mobility echo packets on UDP port 16666/16667, and eping sends Ether IP echo packets using protocol 97. To test mobility connectivity between your controllers, use the controller CLI and issue either an eping or mping (or both) to the IP address of the other controller, as shown in Example 14-9.

Example 14-9 mping and eping from a Controller CLI

mping and eping from a Controller CLI

 

 

mping and eping from a Controller CLI

If mping or eping fails, you can investigate the appropriate rules on the firewall or network ACLs to find what is blocking that traffic.

Tip It is important to make sure that the physical network connectivity for your controllers is configured properly. Speed and duplex settings on the switch or firewall ports that the controller is connected to need to be correct. If you are using link aggregation (LAG), you need to verify that the etherchannel load-balancing on the switch is src-dst-ip. If you are not planning to use LAG but are going to connect multiple distribution ports on the controller, make sure you have an AP-Manager interface assigned to each port even though the anchor controller will not have APs joined to it. Failure to heed these basic setup guidelines will cause incorrect traffic flow into and out of the controller. Incorrect traffic flow will result in mobility issues—that is, epings work, but mpings don’t—and break your auto-anchor configuration even if all the mobility, mobility anchor, and firewall configurations are correct. Even though the anchor controller usually has no APs joined to it, it must be in Layer 3 transport mode just like the foreign controller.

Additional debugs to help troubleshoot guest tunneling are used to investigate any mobility issues between the controllers.

The mobility debugs are as follows:

■ debug mobility handoff enable: Debugs mobility packets.

■ debug mobility director enable: Debugs mobility error messages.

■ debug mobility keepalive enable: Shows what controllers are sending and receiving mobility keepalives and if they missed.

Example 14-10 presents sample output from these debugs showing sent and received keepalives as well as a down mobility member.

Example 14-10 Sample Mobility Debug Output

Sample Mobility Debug Output

Example 14-10 Sample Mobility Debug Output

Sample Mobility Debug Output

The output from these will also show any configuration issues between the guest WLANs on the controllers and whether mobility packets are being sent and received. Example 14-11 shows output that is indicative of a WLAN configuration mismatch.

Example 14-11 Mobility Debug Output Indicating a WLAN Configuration issue

Mobility Debug Output Indicating a WLAN Configuration issue

When the client entry is anchored to the controller in the DMZ, the WLAN security policy (think of this as the configuration of the WLAN) is such that the hex value is 0×2000. This means that the WLAN is anchored, but DHCP is not required. The different configuration options for the WLAN cause this security policy value to change. Therefore, if the WLAN is anchored, DHCP is required, and web auth is enabled, the security policy value would be 0×2050. This value is calculated by the following:

tmp195-112_thumb

The important aspect to take away from this is that the security policies must match between the foreign and anchor controllers. If not, the anchor will fail and you will see the preceding output in debugs.

When a successful mobility anchor takes place, the output of show client detail client mac should look like that in Example 14-12 for the foreign controller and Example 14-13 for the anchor controller.

Example 14-12 Partial Client Detail Output from Foreign Controller

Partial Client Detail Output from Foreign Controller

 

Partial Client Detail Output from Foreign Controller

Because the foreign controller is not responsible for authenticating the client, the state of the client on this controller is RUN.

Example 14-13 Partial Client Detail Output from Anchor Controller

Partial Client Detail Output from Anchor Controller

Notice that the state of the client on the anchor in Example 14-13 is WEBAUTH_REQD, indicating that the client has yet to authenticate.

If the foreign controller shows the mobility state of the client as local, the mobility anchor is not working correctly. In this case, try the following:

Step 1. Disable the guest WLAN on both the anchor and the foreign controller.

Step 2. Remove the mobility anchor configuration from the WLAN on both controllers.

Step 3. Save the configuration on both controllers.

Step 4. Re-create the WLAN anchor on both controllers.

Step 5. Enable the WLAN on both controllers.

Next post:

Previous post: