Cisco Centralized vs Distributed Data Forwarding
For access points (APs) at my customer’s main site where the wireless controller (WLC) is located, local mode, Cisco’s implementation of a centralized WLAN architecture, is an appropriate choice since traffic must flow from the edge through the distribution layer to the core, then to their server farm for services or out to the internet. In this scenario, all wireless traffic (management, control, and data planes) traverse a Control and Provisioning of Wireless Access Points (CAPWAP) tunnel to the WLC where data traffic may then continue on its way to the required resources. The switchport at the edge is configured for access mode with a disabled VLAN. When an AP successfully authenticates to the wired network, a VLAN dedicated to the APs is dynamically assigned to the switchport by the network access control (NAC) appliance, Cisco Identity Services Engine (ISE). Routing is configured between the AP VLAN and management VLAN where the WLC resides. The WLAN is also configured for a disabled VLAN. When a wireless client successfully authenticates to the WLAN, the appropriate user VLAN is dynamically assigned and sent to the WLC for use with the session.
My customer also has a smaller detachment site which has its own external connection, perimeter security stack, and services to local users. Additionally, there is a dedicated connection between the main and detachment sites.
Cisco’s FlexConnect feature is an example implementation of a distributed data forwarding model which moves the portal for data plane traffic to the AP while management and control plane traffic continue to traverse a CAPWAP tunnel to the WLC. At a conceptual level, distributed data forwarding seems simple enough. However, when it comes time for implementation, intricacies of this method pose some interesting challenges.
Since data plane traffic will diverge from management and control plane traffic at the AP, a trunk is required between the AP and the connected edge switch for VLAN segregation. The switchport at the edge is still configured for access mode with a disabled VLAN. When an AP successfully authenticates to the wired network, an interface template is dynamically assigned to the switchport which configures the interface for trunk mode with the dedicated AP VLAN as native, or untagged, using the same routing between the AP VLAN and management VLAN where the WLC resides. The WLAN is also still configured for a disabled VLAN. When a wireless client successfully authenticates to the WLAN, the appropriate user VLAN is dynamically assigned and sent to the AP via the WLC for use with the session.
Their configuration baseline of an edge switchport is for “multi-auth”, or multiple authentications. This means that every device connecting through this switchport must authenticate. Wireless clients connecting through a FlexConnect AP would see both the switch and the WLC as 802.1X authenticators. In the logs on ISE, we discovered both successful and failed authentication attempts for every FlexConnect WLAN connection, where the successful attempts were of the WLC as the authenticator, and the failed attempts were with the switch as the authenticator. The result was inappropriate dynamic VLAN assignment and inability of wireless clients to access network resources.
The switchport may alternatively be configured for “multi-host” mode which means that once an initial authentication succeeds (i.e. the AP), all other connections through that interface are allowed through. Wireless clients will still ultimately authenticate via the WLC and are then able to obtain appropriate VLAN assignment and access to network resources. However, this is not without caveat. As an example, if an adversary were to insert another device in between the AP and the switch, such as a hub, they would be able to piggyback on the authentication of the AP and have access to network resources. Furthermore, this adds a variant to the switchport configuration baseline. My philosophy on the matter is that the more we have to keep track of, no matter how good documentation may be, the more there is to potentially forget. This is compounded by the inherent personnel turnover with my customer organization.
Still, these caveats may be outweighed by alternatives. It is certainly possible for APs at the detachment to be configured for local mode, but this would mean data traffic will need to traverse, even a dedicated, wide area network (WAN) link then back again to reach local services and resources. It is also possible to deploy another WLC dedicated to the detachment site, but this introduces an even greater burden for sustainment as well as on configuration management and possibility for divergence.
