Cisco Wireless Network Architectures

This topic is to discuss the following lesson:

1 Like

Dears ,

I have a question about CAPWAP tunnel ,what it is exactly purpose ,what i understood from explaination is CAPWAP existed to overcome on the problem of offering user VLANs into switchport where is connected with switch

“How can the lightweight AP offer an SSID that uses VLAN 20 or 30 while it’s connected to a switchport in VLAN 11? That’s what the CAPWAP tunnel is for; it tunnels VLAN 20 and 30 traffic from the lightweight AP to the WLC.”

question is i think it is normal to offer an SSID that uses VLANs 20,30 to be with VLAN11 ,just to let the port where is connected to switch to be member of three VLANs 11,20,30 , this is a way to do without using CAPWAP tunnel , Am i right ?

Hello Michael

Yes, you could do that, and connect the access point with a trunk link to the specific VLANs that you have configured. Such a network looks like this:

This means that you would have to make sure that all VLANs that are used for all SSIDs are made available to the appropriate ports on the switches that serve the APs. When the network gets large, this can be an administrative nightmare.

Imagine having 50 access points, with 12 different SSIDs, on a network with 12 switches, and you want to be able to provide various SSIDs to different APs. The whole VLANs configuration will be very complicated, and will also put a lot of overhead on protocols such as STP. And then imagine you want to add 3 more SSIDs to five specific APs. You must go into each switch and add the appropriate VLANs to the appropriate trunks and so on… You could just allow all VLANs on all trunks, and use VTP for VLAN pruning, but that’s not necessarily good network design (remember broadcast domains?). Now imagine all of that on a network with 500 APs and 100 switches. :crazy_face: As the network gets bigger, the complexity increases.

The purpose of CAPWAP is to simplify this. With CAPWAP you can configure a single VLAN for all of your APs, and have the intelligence of the AP and WLC automatically create the CAPWAP tunnels as needed on each AP.

I hope this has been helpful!

Laz

Many thanks , really appreciated

1 Like

Trying to clarify the APs that have to be used when using a Meraki Cloud based solution.

You mentioned:
“With the Cisco Meraki architecture, the management function is in the cloud and we use autonomous APs on the network.”

Even though the Meraki APs would have a cloud based WLC, it still needs to be autonomous AP because it still needs to send data traffic via trunk links? And a lightweight AP can’t do that, correct? It’s starting to sound like a Meraki AP is in the middle of an autonomous AP and lightweight AP.

I assume that the autonomus APs are also used in case the cloud management of the Meraki APs were to ever to go do down, you could do management functions on the AP locally?

Anyways, just some clarity on that would be helpful. Thank you!!

Hello Jonah

As you suggested, Cisco Meraki access points are a special case. They are not strictly speaking “lightweight” since they still have a level of intelligence higher than real lightweight APs. They are indeed somewhere between lightweight and autonomous APs. This is why they belong to the Cloud-Based AP Architecture category.

Only control plane traffic is exchanged between the AP and the cloud controller. All data traffic remains on the local network. For multiple SSIDs, it is possible to tag the traffic of each SSID with the appropriate VLAN ID, and configure those VLANs on the switchport for segregation of the network segments. More info on that can be found here:

I hope this has been helpful!

Laz

Hi

So an AP sends all its traffic through a CAPWAP tunnel to the WLC. If 2 PC’s want to communicate which are on the same subnet and also transmitting/receiving from the same AP, how does a frame from PC A get to PC B, and how does PC B get the return frame back to PC A. This is assuming the AP and WLC route to/from each other. I may be overcomplicating it in my head.

Shaun

Hello Shaun

This is an excellent question. You would think that the switching would take place locally at the AP, since this is more efficient, and you don’t actually need to burden the CAPWAP tunnel with that kind of traffic. But in actuality, when an AP joins a WLC, all traffic will be tunnelled through the CAPWAP including traffic between two clients on the same subnet connected to the same AP.

This actually does not create a big problem because in most wireless networks, clients will connect and communicate with devices on other subnets. It is rare for two wireless devices to communicate with each other when they are on the same VLAN and connected to the same AP, so such traffic will be very little, and will occur very rarely.

There is one exception to this rule, and it happens only under special circumstances. According to this Cisco documentation:

The only exception to this is when an AP is in hybrid-REAP mode. The hybrid-REAP access points can switch client data traffic locally and perform client authentication locally when their connection to the controller is lost. When they are connected to the controller, they can also send traffic back to the controller.

I hope this has been helpful!

Laz

Spot on, Thank you Laz.

Shaun

1 Like

Hello Rene and Laz,
This lesson gave me some doubts and clues, let me expose it:

  1. I understood according to your diagram, you can have your WLC connected to the Switch Core, and the connection between them are on trunk, let`s say the Switch Core has 4 vlans declared 10,20,30 and are dedicated for SSID traffic, and vlan 40 for management traffic (CAPWAP), also its corresponding DHCP pools lives here, but on the Access Switch side, you only need to declare on each port where the AP is going to be connected as an Access port vlan 40, in order to reach the WLC through this CAPWAP tunnel, it means that when a wireless client is gonna be connected to each SSID that is mapped to VLAN 10,20 and 30 is going to receive IP addr from the DHCP server which resides on the Core Switch through the CAPWAP tunnel established, am I right?
    On this scenario your WLC has a Management IP 192.168.10.1, and APs must have an IP on the same subnet 192.168.10.0/24, ( that could be assigned by a DHCP server by the core Switch or statically).
    It is called Layer 3 CAPWAP or LWAPP discovery within the same subnet.

  2. Lets say you have the WLC on a Data Center, and the APs are on a branch connected to an Access Switch, but the only method to reach the connection between the WLC and APs through the CAPWAP tunnel, is under a configuration called FlexConnect, the CAPWAP must travel through the WAN link and only this traffic should be allowed in order to avoid a saturation, the SSID traffic or client traffic is working as a local switching, and the DHCP server resides on the Access Switch.
    And my doubt is that according to your diagram the AP with IP 192.168.11.1 and WLC with IP 192.168.10.1 are connected through CAPWAP tunnel, this type of connection might be called also Layer 3 CAPWAP or LWAPP discovery on different subnets, am I right?
    Now lets imagine that we have a second WLC in another place for redundancy, obviously with a different management IP, in a different subnet, when the primary WLC is offline all APs associated to the primary WLC will declare this CAPWAP tunnel as totally down, because there is no join response messages, the AP at this point is going to try to connect with the secondary WLC through a new CAPWAP tunnel, one is established the end to end connections also will be the same, I mean the AP with an IP on one subnet and the WLC in another subnet.

  3. Speaking about Cloud Meraki solutions, I suppose that it is possible to connect APs on the Access switch as an access port vlan X (the same configuration as the Aironet APs), also this access vlan must have connection directly to the internet and avoid some restrictions by the firewall side, at this point the AP can be connected to the Meraki dashboard cloud through CAPWAP tunnel, and you can manage all the necessary vlans for each SSID, but a new doubt arises in my head, if you manage on your core, distribution or access Switch your DHCP scopes, and you have more than two SSIDs and each should have a dedicated subnet, I concluded that is mandatory to have a trunk connection on your port where the AP is gonna be connected, or can you keep the same access port configuration for each ap, even though the SSIDs on your Meraki dashboard has different vlans?, I think it might be not the same because the cloud Dashboard, is outside of your infrastructure.
    It might sound more logical if you declare the DHCP scopes on your Meraki dashboard, and the CAPWAP tunnel using access ports for communication, but I think a new issue might be happening, the roaming might be a little bit problematic, because when your client jumps between one AP to another, it should start again the entire connection (4 way-handshake and DORA), and it brings delay.
    Well in summary it is curious how the CAPWAP tunnel works using cloud technology.

At the end, I read on your post: “We only use the cloud for control plane traffic. Data plane traffic remains on the local network and is not forwarded to the cloud. This means that each AP requires a trunk to the switch, similar to autonomous AP architecture.”
This can give us a conclusion that on cloud technologies is mandatory always to use a trunk connection, right?

Let me know if that appreciation is ok, or if I have some misunderstandings.

Regards!

Hello Elihu

I’ll do my best to respond to your questions.

Yes, that is correct. You mention that the AP and WLC will be on the same subnet, which is acceptable of course, but is not a prerequisite.

Yes, this is how it works. You don’t actually call it a Layer 3 CAPWAP tunnel, it is simply a CAPWAP tunnel between the AP and the WLC, regardless of whether or not the WLC and the AP are on the same subnet.

Now concerning Meraki, it doesn’t use a CAPWAP tunnel. It uses its own unique set of features to create a control plane (traffic between AP and cloud based controller) and data plane (user traffic). It’s kind of like using Flexconnect for communication with the cloud, and normal network connectivity for user traffic. This is internally taken care of by the Meraki devices and cloud, you don’t actually have to configure this funcitonality.

Actually, having deployed Meraki devices myself, you don’t actually need a trunk connection. The Meraki device creates the appropriate tunnels with the cloud and routes the control plane traffic to the tunnel, and the data plane traffic to the local network.

Here are some links that will help clarify some of these concepts further:

I hope this has been helpful!

Laz
https://www.ciscopress.com/articles/article.asp?p=2999384&seqNum=5

1 Like

Thanks Laz,

Is useful!!

Regards!

1 Like

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?

Thanks,

Sam

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:

https://learningnetwork.cisco.com/s/question/0D53i00000Ksssv/traffic-flow-in-wlc-based-wlans

I hope this has been helpful!

Laz

Hi,

Yes, that has clarified things.

Thanks,

Sam

1 Like