Cisco WLC Deployment Models

Lessons Discussion
1

This topic is to discuss the following lesson:

2

Great overview, thanks :slight_smile:

Kind regards,
Martin

1 Like
3

In the Cisco ENCOR Blueprint it mentions models like centralized, distributed, and controller-less. I can see that Unified is the centralized model, and possible distributed is the embedded, but what about the controller-less model. Which one of models mentioned in this video would be controller-less? Am I right about the embedded?

4

Hello Curtis

The Cisco ENCOR Blueprint does indeed outline the wireless deployment models that you mention. Specifically:

1.2 Describe wireless network design principles
1.2.a Wireless deployment models (centralized, distributed, controller-less, controller-based, cloud, remote branch)

These are covered in the lessons like so:

  1. Centralized uses a dedicated hardware/appliance Wireless LAN Controller (WLC) in a central location, managing all APs. It provides unified configuration, RF management, and policy enforcement. This aligns with the “Unified WLC” deployment.
  2. Controller-less model uses APs that operate independently without a central controller. Each AP is manually configured making it suitable for small deployments. This matches the “Autonomous AP Deployment”.
  3. Distributed is where APs connect to a central WLC but can switch traffic locally during WLC outages, blending centralized management with distributed data forwarding. This architecture is not the same as embedded WLC, but it aligns with FlexConnect.
  4. Embedded WLC is actually the case where a switch or router or even an AP hosts the WLC. While distributed geographically, this still uses a controller and doesn’t qualify as controller-less. It supports smaller-scale deployments.

I will let Rene know to take a look at this and ask him to consider rephrasing some of the names so that it aligns better with the blueprint terminology. Thanks for the question, it’s helpful to work these things out!

I hope this has been helpful!

Laz

5

Hello everyone.

My book describes the following:

Catalyst 9800 Embedded Wireless for a Switch
Catalyst 9800 wireless controller software for the Cisco Catalyst 9300 switch brings the wired and wireless infrastructure together with consistent policy and management. The Cisco Catalyst 9800 embedded wireless controller software package can be installed on Cisco Catalyst 9300 Series switches to enable wireless controller functionality for distributed branches and small campuses.

Catalyst 9800 Embedded Wireless for an AP
The Cisco Embedded Wireless Controller on Catalyst Access Point (EWC-AP) is a next generation Wi-Fi solution that combines the Cisco Catalyst 9800 Series wireless controllers with the latest Wi-Fi 6 Cisco Catalyst 9100 access points.

Cisco Mobility Express
This is a reliable and affordable wireless solution for enterprise branches or small
to medium-size businesses that want a managed AP solution without being required to buy, maintain, and manage a separate WLAN controller appliance. Cisco Mobility Express is a virtual wireless LAN controller that is integrated into an access point. By default, all access points run the Cisco Aironet CAPWAP image.

What is the difference between EWC and Mobility Express? Is EWC the more modern option for 9800 WLCs while Mobiliy Express was for older APs/AireOS WLCs?

Thank you.
David

6

Hello David

EWC runs on modern IOS-XE platforms, including the newer Cisco Catalyst 9100 Access Points. This is the same software platform as the 9800 series controllers. So it’s a scaled down version of the same software as the independent controller running on the switch, but it runs on the specific series of access points.

Cisco Mobility Express is based on the older AirOS platform and lacks many of the advanced capabilities of EWC.

I hope this has been helpful!

Laz

7

Hello Rene :slightly_smiling_face:

If we opt for the first architecture, where the controller is directly connected to the core, do you think this design is secure? In this case, there is no firewall in between to filter traffic between the core and the controller.

What would be the best recommendation to properly protect this traffic? For example, would implementing ACLs on the controller management VLAN be a good approach? Can you give more advices ?

Thanks Rene !

8

Hello Abderrahmanearhzane

This is an excellent observation, and an important one! The truth is that connecting the WLC directly to the core is a standard, common, and secure architecture when you implement proper defense security controls. This is somewhat different than standard firewall deployments due to the WLC architecture involved. In practice, the WLC itself is not usually placed behind a firewall, but you can choose specific traffic VLANs (i.e. guest networks) to get “firewalled”.

This design is actually the recommended approach for most enterprise wireless deployments. The security doesn’t come from inserting a physical firewall between the core and WLC. Instead, it comes from logical segmentation and layered access controls. A firewall between the core and WLC can actually cause more problems than it solves. For example, CAPWAP traffic uses encapsulated UDP that often suffers from fragmentation, throughput bottlenecks, and latency issues when passing through stateful firewalls.

To deploy such a network securely, here are some best practice approaches for securing a network where a WLC is deployed:

  1. VLAN Segmentation
    This is the fundamental security defense. Place the WLC management interface in a dedicated management VLAN, separate from user wireless VLANs and other network segments. Use separate VLANs for different wireless user groups (Corporate, Guest, IoT, Voice). Keep AP management traffic in dedicated AP VLANs. Advanced option: Consider placing the WLC management in a dedicated VRF for even stronger isolation in high-security environments
  2. Infrastructure ACLs at the Core/Distribution Layer: Concerning ACLs, you are absolutely correct, this is one of your most essential controls. However, apply them at the core/distribution switch rather than only on the WLC. Specifically, you can
    • Create an infrastructure ACL (iACL) on the core switch SVI for the WLC management VLAN
    • Apply it inbound on the interface to filter traffic entering the WLC management segment
    • Use a “deny by default” approach: explicitly permit only required traffic, deny everything else

Why filter at the core? Filtering at the core/distribution layer protects the WLC CPU by dropping unwanted traffic before it ever reaches the controller.

Additional measures to employ include:

  • management plane hardening
  • out of band management
  • CAPWAP security using CAPWAP DTLS
  • Control plane policing (CoPP)
  • Monitoring and logging

A firewall is recommended primarily for guest wireless traffic, and you can route that traffic via a firewall as you see fit.

Your instinct about security in a WLC environment and about ACLs was spot-on. Just remember to apply them at the core switch (upstream filtering) rather than relying only on WLC ACLs, and you’ll have a robust, secure deployment.

I hope this has been helpful!

Laz