Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Understanding Local Switching on Access Points


Local packet switching makes packets switch directly from access points to the wired network, instead of passing through a controller. When an access point is configured to perform local switching, the controller is removed from the forwarding path for client data traffic and the client VLAN is directly accessible through the wired interface on the access point. Packets can be switched directly to and from this interface.

Instead of using the WLAN controller for deep packet inspection, packet forwarding, and in some cases encryption, local switching offloads these functions to access points on a per service set identifier (SSID) or per application basis. This approach is more efficient and more reliable, because it leverages the processing capacity that each new access point adds to the network, and reduces the likelihood of congestion and high latency than can cripple real-time applications. Only control traffic gets tunneled back to the controller and the data traffic stays local on the switch.

Why Use Local Switching?

By allowing local switching at the access point, WLAN controllers are relieved of the packet forwarding overhead, and have more of their processing capacity available for dealing with control-plane traffic and security policy administration. The result is fewer controllers are needed to support all the access points in the network. Bypassing the controllers for traffic forwarding, also results in more efficient traffic flows across the network core, because it eliminates backhauling traffic across the network to be switched by the WLAN controllers in the Data Center.

How Does Local Switching Work?

When local switching is enabled on an access point, control traffic is managed by a controller and data traffic is handled by the local switches using CAPWAP.

Local switching uses two different data tunneling methods, depending on whether a VLAN is configured. If there is a VLAN for the local switching session and it is set to overlay mode, switching is done the same way it is done with local switching disabled—using an overlay tunnel. When no VLAN is configured on the access points, local switching uses a mobility domain tunnel to transport packets.

The following is a summary of the two tunnels:

  • Overlay tunnel—A data tunnel that exists between a controller and access points. When a client session is not locally switched, the overlay tunnel is used for client data traffic. Sessions that use this type of tunnel include:

    • Sessions with local switching disabled.

    • Sessions with local switching enabled but with the VLAN for the session set to overlay mode in the VLAN profile on the access point.

  • Mobility Domain tunnel—Data tunnel between two controllers, two access points, or a controller and an access point. It is used when an access point or controller with local switching enabled does not have the client VLAN configured on it and the traffic is tunneled from another controller or access point.

When to Use Local Switching?

When access points are deployed at remote locations, they are often configured to utilize a local switching configuration, so that user traffic stays at the remote site and the access points send the controller only various status updates and client authentication frames. Because the access points and controller exchange very little traffic in this state, they can often work quite well over a low bandwidth connection. Local switching solutions for remote offices eliminate the additional expense of distributed controllers at each and every remote site as shown in Figure 1.

Figure 1: Remote Office Using Wireless Local Switching
Remote Office
Using Wireless Local Switching

Applications that require fast switching, such as voice, benefit from local switching—see Figure 2.

Figure 2: Voice Application Using Wireless Remote Switching
Voice Application
Using Wireless Remote Switching

When not to Use Local Switching?

Local switching is extremely beneficial for simplifying management, but there can be issues when it is used in large environments with hundreds of access points. With too many access points requiring trunk and VLAN configuration on every access point port, in addition to the time required to manage them all on the downlinks back to the core, it can be more cost effective to deploy additional controllers. Additional issues include:

  • Instability due to extremely large broadcast domains spanning every access layer switch.

  • The large number of MAC addresses that have to be learned on every switch.

  • Administrative overhead needed to create a dot1q trunk for every access point deployed.

The following restrictions apply to access point local switching:

  • Restricting Layer 2 forwarding for a VLAN is not supported if the VLAN is configured for local switching.

  • The DHCP restrict feature is not supported for locally switched clients.

  • When the set ap apnum port portnum type command is used to specify a port on a directly attached access point, the access point cannot be configured for local switching. However, a directly connected access point with an unspecified port can perform local switching.

  • IGMP snooping is not supported with local switching.

VLAN Profiles and Local Switching

A VLAN profile consists of a list of VLANs and tags. When a VLAN profile is applied to an access point, traffic for the specified VLANs is locally switched by the access point instead of by the controller.

The tag on the VLAN for access points that are using local switching must be unique and not match any tag on any VLAN configured on the controller. This is because the wireless operating system uses both the name and the VLAN ID for various tasks such as moving client sessions, authentication requests, roaming, and data traffic.

How Do I Configure Local Switching?

A VLAN profile consists of a list of VLANs and tags. When a VLAN profile is applied to an access point, traffic for the specified VLANs is locally switched by the access point instead of by the controller.

From Network Director, enable local switching for access points by following the directions in Creating and Managing Local Switching Profiles, Assigning a Local Switching VLAN Profile to Existing Access Points, Assigning a Local Switching Profile During Access Point Configuration, Creating and Managing Remote Site Profiles), and Assigning a Local Switching Profile During Access Point Configuration.

Does a Web Portal Work with Local Switching Configured?

Yes, a Web portal works with local switching configured. When the VLAN for the Web Portal service exists locally on the controller, the controller must have an IP interface configured on this VLAN (either statically or by enabling the DHCP-client feature on the controller for this VLAN). However, with the local switching feature, it is possible that the VLAN for the WLAN client exists only at the uplink port of the access point with which the client is associated.

Does QoS Policy Enforcement Work with Local Switching Configured?

Yes, policy enforcement works with local switching configured. An ingress map determines how DSCP values are classified into CoS values. An egress map determines how CoS values are marked into DSCP. The controller and associated access points share the same set of maps, which means the QoS policy enforcement will work with or without local switching enabled.

What Happens if the Controller or WAN Link Goes Down?

Locally switched access points are managed either through the WAN or through the Internet by controllers at headquarters, and will maintain local session persistence indefinitely, if the WAN link goes down. If the connection to the controller is lost, wireless services continue uninterrupted—connected clients maintain wireless connection to the access point, new clients can connect and authenticate locally, and the Wireless Intrusion Detection System (WIDS) continues to work.

Is Local Switching Included in any Other Wireless Features?

Local Switching Profiles can also be included in Remote Site Profiles (see Creating and Managing Remote Site Profiles), when adding an access point to Network Director (see Adding and Managing an Individual Access Point), and in WLAN Voice Profiles.