Cisco Wireless Network Architectures

Hi Laz,

I have a followup question to your answer.

For the Split-MAC architecture, does the WLC do the switching but a connected router/L3 switch do the routing (I think yes, but just want to clarify)?

Assuming a connected router is doing the routing between SSID/VLANS, how does ARP work from the router’s perspective? Does the the WLC reply to any ARP requests or are they tunnelled back to the host?



Hello Samir

When a client connects to a particular SSID of a lightweight AP, the traffic is encapsulated in a CAPWAP tunnel that leads back to the WLC. Once the WLC receives this, the CAPWAP header is removed, and the packet is forwarded to the gateway that corresponds to the VLAN to which it belongs. So yes, the WLC will forward traffic to be routed to an external device such as a router or an L3 switch. Switching of traffic that belongs to the same VLAN will be switched within the WLC. Take a look at the diagram found in this Cisco documentation:

Concerning ARP, the following Cisco Learning Network thread may be helpful:

I hope this has been helpful!



Yes, that has clarified things.



1 Like

Hi guys from,

I had some questions regarding local MAC vs. split MAC.

Question 1 - Definition of local MAC vs. split MAC

I read the “Cisco Wireless Network Architectures” lesson, and other complementary articles on Internet [1] [2].

After reading everything, I had the understanding summarized in the following diagram:

Untitled Diagram

It is:

  • Local MAC is when all data frame process occurs on the AP, including switching/routing. Split MAC is when all non-real time data frame process occurs on the WLC, some real time functions are still on the AP, but data frames are always “tunneled” to the WLC, which is now responsible for switching/routing them.
  • RFC 5415 defines two modes for CAPWAP: local MAC and Split MAC. In local MAC mode, data frames are not encapsulated and sent to the WLC, and the switching/routing occurs on the AP (I don’t know if Cisco implements this, but it’s on the RFC).
    • So local MAC is not only when we have an Autonomous AP architecture. If I have a CAPWAP WLC-based architecture, I can use local MAC as well when I chose to do the switching/routing on the AP.
    • I understand that the Cisco Meraki Cloud-based architecture (although being a 3rd-party proprietary solution/protocol) is very similar to the way CAPWAP using local MAC mode is defined on the RFC.

This is the RFC relevant part:

The CAPWAP protocol supports two modes of operation: Split and Local MAC (medium access control). In Split MAC mode, all L2 wireless data and management frames are encapsulated via the CAPWAP protocol and exchanged between the AC and the WTP. […] The Local MAC mode of operation allows for the data frames to be […] locally bridged.

Is my understanding about local MAC vs. split MAC correct?


Question 2 - Advantages vs. disadvantages of the split MAC architecture

In the lesson, you guys talked a lot about the advantages of the split MAC architecture. But you didn’t talk much about the disadvantages. My understanding is that the split MAC architecture has some drawbacks (they may be be relevant for some use cases, or may be solved by ways - like adding more bandwidth and redundancy, but they exist). In my opinion, they are:

  • Increased bandwidth and latency due to traffic being sent to the WLC
  • WLC being a single point of failure
  • The network between APs and WLC being a point of failure

So, in some use cases, one could decide to use a WLC local MAC architecture (just like Cisco Miraki does) to circumvent these disadvantages.

Let me explain with an example:

Untitled Diagram-Page-2.png

So, when using split MAC:

  • If two users (connected to the same AP) decide to exchange files, this traffic must go through the WLC (going up on the infra network layers) before being switched to the user
    • One may argue that this case is not common, and local data traffic is usually pretty small nowadays (except on a datacenter, but in this case, we’ll not be using Wifi)
  • When a user needs to access Internet, we still need to pass through the WLC.
    • This way, if the WLC goes down, or if the network between the core SW and the WLC goes down, then we will have failure. And if we reach the maximum bandwidth of the link (between the core SW and the WLC), we’ll have slowness for all kind of traffic.

With a WLC-based but local MAC architecture, we would have the management benefits of WLC, but we would be reducing the blast radius of failures.

Now imagine the following scenario, when we have a big company, with a datacenter, and multiple office buildings, connected via a MPLS network (could be VPN as well):

Untitled Diagram-Page 3.png

I’m assuming the WLC (or WLCs, for redundancy) would be in the datacenter.

In a split MAC architecture:

  • All local data traffic should cross the MPLS network, consuming bandwidth and increasing latency
    • But again, one may argue this is a non-usual use case
  • All Internet traffic should cross the MPLS network as well. And the traffic that goes, must return before being routed via Internet (local Internet link in the Office building).
    • We could use the dedicated DC Internet links for this, but now the links (used by users/customers at Internet) would be shared with the internal users, and this could be a problem.
    • WLC being a point of failure is still a problem. But now, we rely much more on multiple network paths (more points of failures). And bandwidth and latency in the MPLS network can be a problem.
  • Private traffic (e.g. internal users reaching internal servers at DC) would traverse the MPLS network, but this shouldn’t be a big deal (since in both local and split MAC architectures this would be necessary anyway).

Now, if we would use the WLC with local MAC architecture, of course we would lose some benefits of the split MAC architecture (costs of using lightweight APs, simplified VLAN configuration, etc), but we will cross much less network paths for data frames.

Now, considering the Cisco Miraki solution, we have something very similar: just change the datacenter by the cloud, and the MPLS network will be the Internet. I guess the disadvantages above (specially increased bandwidth and latency between office and cloud, and network connectivity dependency) may be one of the reasons why Cisco Miraki decided to keep all data frame switching local.

Note: Vendors may have architectures when we have local WLCs (for instance, in the local office building) and create a management relationship between the WLCs in the DC and the local ones (similar to the way MS Active Directory works), but I don’t know if such a thing exists.

Is my understanding about advantages/disadvantages of local MAC vs. split MAC correct?


Just read lesson “Cisco Wireless AP Modes”, and I found this:

It’s possible to connect a local mode AP at a remote branch to the HQ’s WLC. This works, but it’s not a good idea. First of all, the AP encapsulates all wireless client data through the CAPWAP tunnel over the WAN link. Secondly, when the WAN link is down, your wireless network at the branch site is offline too. FlexConnect is an AP mode for situations like the one above. The AP can locally switch traffic between a VLAN and SSID when the CAPWAP tunnel to the WLC is down.

I think this reinforces that my understanding was correct (WLC in split MAC mode has drawbacks), and there are solutions like FlexConnect to reduce blast radius of a network failing between APs and WLC. FlexConnect is not intended to solve all issues (like Internet traffic), it is vendor-specific, but can solve the local traffic problem.

Hello Rarylson

Thanks for the detailed post.

Concerning the local and split MAC architectures, the truth is that different vendors may use slightly different definitions. However, the idea is that MAC functionality can either be fully in control of the AP alone, or it can be separated such that control plane functionality takes place at the WLC, and data plane at the AP.

Concerning the advantages and disadvantages, what you say is true, but you must weigh the benefits appropriately. For example, if you have 100 APs, it would be better to “tolerate” the disadvantages of using a WLC for the purpose of easy and quick administration, saving a lot of time and energy, and money.

Secondly, the disadvantages can be dealt with using an appropriate network architecture, making sure that you have enough bandwidth, and you have redundancy wherever you need it, to ensure that those disadvantages are mitigated. Remember, the network itself can be a single point of failure whether you use a WLC or not. And there are many single points of failure, other than the WLC, which can be mitigated by simply improving the network architecture.

I hope this has been helpful!


Hey Guys,

How does romaing work with autonomous AP’s?
Rene mentions below

“Let’s say you want the capability that wireless users can roam from one AP to another without losing their connection and DHCP assigned IP address. This is no problem, but it means you have to configure the same SSID and VLAN on all APs.”

Is it seemless roaming or is it an interruption\re -association?


Hello Josh

It all depends upon the context in which the term “roaming” is used. Take a look at this NetworkLessons note on WIreless Roaming Defined.

I hope this has been helpful!


Hi all,
i just configured the port of my cisco switch in a campus that is connected to the AIR-AP380 , the configuration of my port is:

switchport trunk native vlan 11
 switchport mode trunk
 switchport nonegotiate
 spanning-tree portfast trunk

Can i add also the comand spanning-tree bpduguard enable and switchport port-security mac-address sticky on the same port? thank you

Hello Valerio

You can add bpduguard and port security on the same port where you have connected an access point, however, you must keep the following in mind.

If the AP is operating in Layer 2 mode (that is, it is not performing routing) then the port-security mac-address sticky command may not be very useful. This is because every wireless client’s MAC address will appear on that interface, and thus you must have enough sticky MAC addresses configured to accommodate the estimated number of users connecting. If the AP is performing routing, then only the MAC address of the AP will appear on the interface, thus the “sticky” command is useful.

As for the bpduguard, it’s always a good idea to enable it on such ports as you should never receive BPDUs on such a port.

For more info, take a look at these related lessons:

I hope this has been helpful!


Hello, thank you for the great explanation, i will read the lessons.

1 Like


This lession mention the WLC must trunk all vlans, but i don’t understand why if the CAPWAP tunnel only needs L3/L4 reachabilty.

For example, in a large company, you could have many branches and the HQ. In the HQ you place the WLC connected to a Core node, so between the WLC and the Core Router you could only use a /30 subnet, and also configure a loopback on the WLC (i don’t know if you could do configure logical interfaces in the WLC). So, a /30 or /31 between WLC <-> Core router, and using vlan 10 , and then the Core router could propagate via an IGP this subnet or loopback address to the other branches.
The LWAP could reach the IP of the WLC via its default gateway (Core branch router).

So why in this lesson says the WLC must trunk all vlans ?

1 Like

Hello Juan

I believe that the WLC by design requires a trunk port to all of the VLANs where access points are connected. This is the case when using LWAP in the Unified WLC deployment.

If however, you use FlexConnect, then it is possible to use an access port and layer 3 connectivity to the APs. If user traffic comes back to the WLC via a CAPWAP tunnel, trunks must be used.

More info can be found at the below Cisco Community forum post.

I understand that the logic of the CAPWAP states that you only need L3 connectivity to make the tunnel work. However, the WLC by design needs those trunks for it to function correctly.

I hope this has been helpful!


1 Like


Can someone please help me understand this?:
“Real-time functions: Transmission of 802.11 frames”

The online course I worked through said that “802.11 to 802.3 communication” is handled by the WLC, and Wendell Odom’s CCNA book also implies the same:
“Or consider roaming for a moment. If at one instant a packet arrives for your phone, and you are associated with AP1, and when the next packet arrives over the wired network you are now connected to AP4, how could that packet be delivered through the network? Well, it always goes to the WLC, and because the WLC keeps in contact with the APs and knows that your phone just roamed to another AP, the WLC knows where to forward the packet.” (This is at the very end of “Appendix K: Analyzing Ethernet LAN Designs.”)

On page 638 of his book, Wendell Odom lists these Real-Time Functions:
• RF Transmit/Receive
• MAC Management
• Encryption

So the “Transmission of 802.11 frames” means taking care of the Physical/L1 side of things, right?

Do I understand it correctly that with lightweight APs, the user traffic goes to the lightweight AP, then through the switches to the WLC, and from the WLC back through the switches to the lightweight AP, and finally the lightweight AP transmits the user traffic to the original user? I assume the function of the CAPWAP Data tunnel is to accomplish communication between the Ethernet (802.11) and wireless (802.3) network.


Hello Attila

Real-time functions, including the transmission of 802.11 frames, refer to the tasks performed by the AP to handle wireless communication. These tasks take place on both the user plane and the control plane and include things like dealing with RF signals, MAC management, and encryption/decryption. These tasks are indeed related to Layers 1 and 2 of the OSI model.

Now specifically with lightweight APs, the user traffic goes through the following steps:

  1. User traffic is sent to the lightweight AP (over the wireless 802.11 network).
  2. The lightweight AP encapsulates the user traffic inside a CAPWAP tunnel and forwards it through the wired Ethernet network (802.3) to the WLC.
  3. The WLC processes the traffic, makes decisions (e.g., access control, quality of service), and forwards the traffic as necessary, either back to the same AP or another AP (in case of roaming).
  4. The receiving AP decapsulates the CAPWAP-encapsulated traffic and transmits it to the user over the wireless 802.11 network.

You are correct in understanding that the CAPWAP data tunnel is used for communication between the Ethernet (802.3) and wireless (802.11) networks. The WLC plays a crucial role in managing lightweight APs, user traffic, and overall network performance. Does that make sense?

I hope this has been helpful!


1 Like

Comparing Auntomous design VS Split-MAC design (CAPWAP Tunnel) :

It’s pretty clear for me Autonomous design requires VLAN implementation everywhere (besides other configs such as mgmt, tx power, ch assignation, etc etc that you do per Autonomous AP basis). in Access Layer (between Access switches and APs) , trunks between Access switches and Distribution Switches and then on trunks between Distribution and Core.

In the other design, Split-MAC is also clear for me because of this CAPWAP tunnel we move the mgmt functions to the WLC and the real time remains in the AP.

But its not 100% clear for me, the switched tunnel vs routed tunnel. For me switched means no L3 involved, if we say a switched tunnel we dont need an IP add configured on both AP and WLC ? how the tunnel is established in a switched tunnel ? lets say we use VLAN 10 for Mgmt , so we configure it in the LWAP , and also in the WLC, but if guess in this case we would need to configure VLAN 10 all across the network such as an autonomous design…

The routed tunnel is more clear for me because im acostumed to other kind of tunnels such as GRE , while you reach the ip add of the other side its ready to go then the tunnel is established.

Hello Juan

When talking about CAPWAP tunnels, there is really no distinction concerning routed or switched tunnels. CAPWAP tunnels are created between an AP and its WLC over an underlay network that can traverse routers, switches, multiple subnets etc, just as long as the AP can reach the WLC. The CAPWAP tunnel is specially created to carry the multiple VLANs that correspond to the SSIDs that an AP may be serving.

Rene states in the lesson that “Tunneled traffic can be switched or routed” and this phrase may be the source of your question. The idea here is that the underlay network that carries the CAPWAP tunnel can be either routed or switched. Rene goes on to say that this:

…means the lightweight APs and WLC don’t have to be in the same VLAN. This is useful since APs are typically on the access layer, and the WLC is in a central location (core layer or data center attached to the core).

So it’s not referring to the tunnel as a Layer 2 or Layer 3 entity, but in the way the tunnel is encapsulated and transmitted over the underlying (layer 2 or layer 3) infrastructure. Does that make sense?

I hope this has been helpful!


Thanks @lagapidis

But why is necessary to tag all vlans between WLC and Core ? for establishing the capwap lwap uses the mgmt ip add to reach the wlc , you only need to tag the mgmt vlans for each lwap, but the ssid vlan why ? its because the vlan must be present at both ends of the tunnel for encapsulation/dencapsulation purpose ?

lets say SSID “my-wifi” VLAN 100 configured on LWAP 1 , CAPWAP is already established, so LWAP 1 wants to forward traffic to VLAN 200 configured on LWAP 2 (this lwap also has established capwap) LWAP 1 encapsulates VLAN 100 traffic into the CAPWAP tunnel using udp 5247, 2 WLC receives the CAPWAP pckt and deencapsutale it, it see that is destined for VLAN 200 (LWAP 2) 3. WLC encapsulates it traffic VLAN 200 into a new CAPWAP pckt and forward it to LWAP 2, 4. LWAP 2 deencapsulte it and forward it to the client ?

Hello Juan

To establish the tunnel between LWAP and WLC, all you need is the IP address because the CAPWAP tunnel is created over the underlay network infrastructure that exists between the WLC and LWAP. As long as those two can reach each other, the CAPWAP tunnel can be established.

Why do we need all VLANs between WLC and the core? Well, it depends upon where you are performing your routing. If the routing takes place at the core network, then this must be done in order for the clients connected to each SSID to reach the default gateway of each VLAN. The default gateway will actually exist within the core itself. However, you can change that topology and make the WLC itself the default route for every VLAN/SSID. In that case, you wouldn’t need a trunk between the WLC and the core network. The scenario you described in your post assumes routing takes place in the WLC.

The question is, what is considered best practice in this? Well, typically we don’t want to overburden the WLC with routing, especially in a large network where it would have to act as router to all wireless clients. If the WLC has to handle, say, 50 or 60 clients, then you should be OK with routing at the WLC. However, if you have a network with thousands of wireless clients, it is best to leave routing to a different device, and this is why you need the trunk. That way the WLC will only be burdened with the management of the LWAPs and not routing as well.

Creating a trunk and performing routing on the core network is considered best practice, even in smaller networks. Does that make sense?

I hope this has been helpful!


1 Like

Thanks @lagapidis

Taking the following diagram in mind :

The only purpose for vlan 11 in AP1 is for associating a subnet such as 192.168.11.x ? that has allocated the ip host used to establish CAPWAP with WLC ?

In this case the link Core ↔ WLC is a trunk with all vlans passing through it including the vlan used for 192.168.10.x (i guess it could be and interface vlan X lets say, so AP1 can reach through the Core , DG an the core itself resolves the routing because it also has the directly connected network… therefore AP1 can establish CAPWAP and encapsulates mgmt traffic UDP 5246 and data traffic UDP 5247 (i guess both ends, LWAP and WLC encapsulate when they want to send to the other end , and dencapsulte when they receive from the other end).

The last one, this excerpt from this lesson, the one in bold , i think CAPWAP is routed, this phrase was generic regarding any tunnel or CAPWAP ?

Tunneled traffic can be switched or routed

Thanks for your patience (i dont have any WLAN experience because the environment i work on daily basis does not require this knowledge but im interested in it).

Hello Juan

Yes that is correct, and I believe your subsequent explanation is correct as well. Routing between the AP and the WLC is achieved within the core network, while the CAPWAP tunnel uses that routing to terminate on the WLC and the AP. The core network is the underlay network which can be routed/switched, while the CAPWAP tunnel is the overlay network.

As I mentioned in my previous post, the idea here is that the underlay network that carries the CAPWAP tunnel can be either routed or switched. Also, the CAPWAP tunnel may terminate on the WLC and be routed there, or (ideally), it should be switched to the core network to be routed within the core.

No problem at all, that’s what we’re here for, to help people learn new things!! I hope this discussion has been helpful and if you have any further clarification questions, feel free to ask them!

I hope this has been helpful!


1 Like