Cisco Wireless Network Architectures

Lessons Discussion
1

This topic is to discuss the following lesson:

1 Like
2

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 ?

3

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:

image
image2048Ă—1552 465 KB

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

1 Like
4

Many thanks , really appreciated

1 Like
5

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!!

6

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

1 Like
7

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

8

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

2 Likes
9

Spot on, Thank you Laz.

Shaun

1 Like
10

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!

11

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

1 Like
12

Thanks Laz,

Is useful!!

Regards!

1 Like
13

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

14

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

15

Hi,

Yes, that has clarified things.

Thanks,

Sam

1 Like
16

Hi guys from NetworkLessons.com,

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?

[1] https://www.techtarget.com/searchnetworking/definition/CAPWAP-Control-and-Provisioning-of-Wireless-Access-Points
[2] https://datatracker.ietf.org/doc/html/rfc5415

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

image
image771Ă—761 31.3 KB

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

image
image1531Ă—781 65.4 KB

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?

Update:

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.

17

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!

Laz

18

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?

Thanks
Josh

19

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!

Laz

20

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