Cisco Wireless LAN Controller (WLC) Basic Configuration

Hello Costa

First of all, I’m not sure which issue you are referring to. The post you are replying to is dealing with a different topic. However, I see that you are trying to reach the management IP of the WLC from a wireless client on the same VLAN.

It is considered best practice to ensure that wireless clients are unable to gain direct access to the management interface from the wireless network. Indeed, Cisco documentation states the following:

To prevent or block a wired or wireless client from accessing the management network on a controller (from the wireless client dynamic interface or VLAN), the network administrator should ensure that only authorized clients gain access to the management network through proper CPU ACLs, or use a firewall between the client dynamic interface and the management network.

It could be that precautions have been configured to disallow this communication. Now if that is the case, you should be able to create an exception in the ACL for a PC on the wireless network, so that if you as an administrator connect, you will have management access.

Let us know how you get along in your troubleshooting.

I hope this has been helpful!

Laz

Thanks a lot for explanation, greatly appreciate it

Hi,

is it necessary for the trunk link between WLC and switch to support management VLAN since CAPWAP tunnel is operating at layer 3?

In addition, is there any scenario where we don’t need to configure the management wlan on the trunk link?

For example, if WLC and APs are in different subnet and there is only Layer 3 routing in some part between them, do we still need to enable the management wlan on the trunk link?

Hello Quirik

You are correct in that CAPWAP carries both user data as well as control data between the WLC and the APs, as seen in this lesson:

However, in this particular topology, we are not employing CAPWAP. We are manually creating VLANs that will be mapped to SSIDs on the APs. This of course is not very scalable, so for larger networks, the implementation as described in the linked lesson above should be used.

I hope this has been helpful!

Laz

Hi,

With regards to lesson:
Cisco Wireless LAN Controller (WLC) Basic Configuration

I have recreated the lab exactly. When connecting an AP, it does not seem to pair up.
When checking the AP, I see the following:

%Error opening flash:/update/info (No such file or directory)
ERROR: Image is not a valid IOS image archive.
Download image failed, notify controller!!! From:7.5.1.73 to 0.0.0.0, FailureCode:3

archive download: takes 48 seconds

., 1) 8 11:36:49.507: %CAPWAP-3-ERRORLOG: Retransmission count for packet exceeded max(CAPWAP_ECHO_REQUEST
*Mar  8 11:36:49.507: %DTLS-5-SEND_ALERT: Send FATAL : Close notify Alert to 192.168.10.100:5246
*Mar  8 11:36:49.507: %LWAPP-3-CLIENTERRORLOG: LWAPP LED Init: incorrect led state 255
*Mar  8 11:36:49.511: %LWAPP-3-CLIENTERRORLOG: Config load from flash failed. Initialising Cfg

*Mar  8 11:36:49.511: %CAPWAP-3-ERRORLOG: Failed to load configuration from flash. Resetting to default config
*Mar  8 11:36:49.523: %CAPWAP-3-ERRORLOG: capwap ifs:  read error or timeout
*Mar  8 11:36:49.527: capwap_image_proc: problem extracting tar file
*Mar  8 11:36:49.527: %CAPWAP-3-ERRORLOG: Dropping dtls packet since session is not established. 192.168.10.100, 147E, 192.168.10.5, 8908, 0
*Mar  8 11:36:59.523: %CAPWAP-3-ERRORLOG: Go join a capwap controller 
examining image...
*Mar  8 11:36:59.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent peer_ip: 192.168.10.100 peer_port: 5246
*Mar  8 11:36:59.499: %CAPWAP-5-DTLSREQSUCC: DTLS connection created sucessfully peer_ip: 192.168.10.100 peer_port: 5246
*Mar  8 11:36:59.499: %CAPWAP-5-SENDJOIN: sending Join Request to 192.168.10.100perform archive download capwap:/ap1g2 tar file
*Mar  8 11:36:59.503: %CAPWAP-6-AP_IMG_DWNLD: Required image not found on AP. Downloading image from Controller.
logging facility kern

From what I read, the correct IOS image for the AP is missing on the WLC?

Hello Jaco

Yes, the underlying problem is that the AP is trying to receive an image that is either invalid or nonexistent. There may be various reasons for this including your WLC version and your AP. Make sure that your WLC platform and version are compatible with your AP model. Here is an example of a similar failure due to the version of the controller:

You may find this compatibility matrix useful in determining if your specific hardware is compatible.

Let us know how you get along and if there is anything else that we can help you with.

I hope this has been helpful!

Laz

There is an interface that gets created using the wizard gigabit0 and I don’t see any physical interface gigabit0 this interface has vrf Mgmt-intf. I created a management vlan and associated that vlan to a physical interface te0/0/0 but I can reach the gateway and the wlc is connected via Layer2 to a router where the gateway vlan is defined.
I was wondering if anyone in this forum is running a 9800 wlc

Thanks,

Juan

Hello Juan

When configuring a Cisco 9800 WLC, the interface GigabitEthernet0 you’re referring to is actually a virtual interface, often referred to as the “out-of-band” management interface. This virtual interface is used for system management and is usually tied to the Management VRF (in your case, it’s called “Mgmt-intf”).

You cannot directly assign a physical interface to this GigabitEthernet0 interface. Instead, your physical interface (te0/0/0 in your case) connects to the network switch, and then you associate this connection with the VLAN that you have configured for management purposes.

Once you configure that switch port, the VLAN on the WLC, and the router as the default gateway, you should be able to reach the default gateway from your WLC. If not, there may be other issues concerning the configuration of the rest of your network. Let us know how you get along so we can see how we can help you further.

I hope this has been helpful!

Laz

Hello All,

I am having a problem with associating a Cisco 9166I AP with a 9800 WLC. One of the document that I found this issue could be the AP is in Meraki Management mode and the AP need to perform a migration procedure. I don’t have a support contract for the AP and I can’t open a Cisco TAC case. I would appreciate if you have ran into this issue or know how to perform a migration procedure.

Thank you

Juan

Hello Juan

Based on the information you have given us, it is not possible to determine the reason for the problem you are facing. However, if you have determined the problem to be that the AP is indeed in Meraki Management mode, then you must perform the migration procedure as you suggested. There are some requirements in order for this to be successful. First of all, here is some info from the datasheet of the product concerning migration:

Included are step-by-step instructions to achieve the migration.

Secondly, here you can see that if you want to migrate from Meraki to the 9800 WLC (DNA center administration), you must have sufficient licensing for the migration. You will have to check on the Meraki cloud subscription that manages that particular AP, if the appropriate licensing is compliant for a migration. If not, you may need to purchase the appropriate license.

https://documentation.meraki.com/MR/Other_Topics/CW916x_Family_Frequently_Asked_Questions#Do_I_need_to_be_in_licensing_compliance_to_migrate.

This information should be enough to get you started on the migration process. Let us know how you get along and if you need any further assistance.

I hope this has been helpful!

Laz

Hello Laz,

Thank you so much for taking the time to answer my question. Your information that you provided is really good and I’m sure will help me on the problem.

Again, I appreciate your response and have a great day.

Juan

1 Like

There are a lot of commands to learn in this section. Do you have any suggestions for best practices to learn these, including the amount of time to spend, in the context of the many topics covered in your CCNA curriculum?

Hello Jim

For the purposes of the CCNA certification, it is not necessary to memorize each and every command. However, what I would suggest is to perform the lab a couple of times so that you get an idea of the steps and processes involved in delivering a basic configuration of a WLC and any connected switch. Once you are proficient in understanding the processes and steps involved, I believe you will have covered the primary content necessary for the CCNA exam.

From a strictly experiential point of view, if you want to be able to set up a WLC from scratch in a production environment, then you will probably have to go over various pieces of Cisco documentation to go beyond what is described in the lesson. But there you have reference material available for you, and you don’t really need to memorize the process. Does that make sense?

I hope this has been helpful!

Laz

Laz,

I’ll lookout for a lab to run the basic configurations. Thanks.

1 Like


Does anyone understand how this “authbypass” feature works in the L3 Webauth — or what problem it solves?
It sounds like MAB but what is it doing in Webauth where the whole idea is for the client to enter credentials?

Is this feature possibly related to the L2 “MAC Filtering” feature in the WLAN setup?

Hello Sandro

The “authbypass” feature in Layer 3 Web Authentication, is a feature that allows certain users or devices to bypass the usual authentication process. This can be useful in situations where certain devices that don’t correspond to a specific user (like printers or IoT devices) cannot interact with the web-based login page to input credentials.

For Authbypass, the network administrator identifies the MAC address of the device that should bypass authentication. This MAC address is then added to a whitelist on the network controller.
When this device attempts to connect to the network, the controller checks its MAC address against the whitelist. If the device’s MAC address is on the whitelist, it is allowed to bypass the usual web-based authentication process and connect directly to the network.

Remember that while this feature can be convenient, it also poses a security risk. If a device with a whitelisted MAC address is lost or stolen, or if a whitelisted MAC is learned and spoofed, someone could potentially connect to your network without having to authenticate. Therefore, it’s important to manage your whitelist carefully and remove devices from it when they are no longer needed.

I hope this has been helpful!

Laz

1 Like

Hello Lazarus,

Thanks for the follow up.

I eventually received some clarification on this issue from the Cisco community over the weekend.
Evidently the authbypass feature is not supported on WLCs.
Here is the link that I was provided in the post:

Knowing all this it begs the question why this option is even present at all in the WLC OS.

But, all that being said - this feature sounds exactly like MAB.
So if my understanding of authentication on the WLC is correct, it goes something like this:

  1. use 802.1x with RADIUS; if that fails (IoT device for instance) then
  2. use MAB; and as a last resort
  3. use Webauth with user-provided credentials.

This is why having the authbypass feature in Webauth made no sense to me at first glance…

Hello Sandro

Thanks for sharing the solution that you have discovered, and for sharing the documentation. Indeed, on the WLC based on the Catalyst 9800 series devices, the authbypass feature is not supported. Specifically, it’s not supported on the wireless component of the operation of the device.

However, as mentioned in the documentation you provided:

Authbypass: The controller uses the MAC address as the client identity and validates this with the authentication server that has a database of client MAC addresses that are allowed network access.

The feature itself is functional on wired connections as described above, and it is indeed useful for situations where we connect devices such as printers, IP cameras, and IoT devices.

As for your comparison of the authbypass feature to MAB, they do have similarities, but they are not exactly the same. MAB is a fallback method that allows devices without 802.1x capability to connect to the network, while the authbypass feature (where it is supported) bypasses the authentication process entirely.

I hope this has been helpful!

Laz

1 Like

Thank Lazarus, that helps clear things up for me.

1 Like