This question comes up and every now and then. So, let’s put it to bed.
If you have a ceiling mounted internal antenna AP (with built-in antennas), or external antenna AP with dipole antennas (AIR-ANT2524D), or with short dipole antennas (AIR-ANT2535SD), here are the correct Azimuth and Elevation angle settings.
This is how 0° Azimuth and 0° Elevation look like. Plus “squished doughnut” as a bonus to illustrate the coverage pattern 🍩
Azimuth angle does not matter in this case (it does for directional antennas), because these antennas have the same pattern regardless of how you rotate them clockwise or counterclockwise. Simply use the default value of 0°.
Elevation angle is 0° for this orientation.
Cisco DNA Center Azimuth and Elevation configuration
My Catalyst 9800-CL controller is hosted on a cloud, so I don’t need any hardware for that. Finally, my Catalyst 9136 Wi-Fi 6E AP is powered by a Catalyst 3560CX 10 Gigabit Ethernet multigigabit switch.
6 GHz 2×2 MIMO setup powered by PoE+
Catalyst 9136 is Cisco’s premium AP with all the bells and whistles including hexa-radio architecture and built-in environmental sensors for smart building use cases. It requires an 802.3bt/UPOE power source to enable 6 GHz radio in full performance 4×4 MIMO mode. The switch I use supports 802.3at/PoE+, which is great, but 6 GHz radio downshifts to 2×2. And that’s where an 802.3bt power injector comes to the rescue.
Since the Cisco injector isn’t widely available yet, I decided to test this Zyxel one. It provides 802.3bt power and allows the AP to run in full power and full 4×4 6 GHz radio mode with no compromise.
Do I like power injectors in production?
Absolutely not! Ideally you should design for 802.3bt/UPOE switches to power all your new APs via PoE.
It allows you to:
easily, centrally and remotely monitor how much power the APs use
enable/disable power on a port to bounce an AP
leverage redundant Platinum-rated power supplies for the AC to DC power conversion
manage the solution with ease – just think how difficult it is to manage more than 1 power injector, the number of AC power sockets, and what happens when someone disconnects the injector?
I still use C3650 UPOE mGig switch in my lab. Catalysts 9300 and 9400 the best choice these days.UPOE and mGig capable C3650 providing full power to the AP
Final look
Carrying a full-size switch is not really an option for me, because small form factor is my main goal. So a power injector works best for me. But if I could I would love to use a compact 802.3bt switch.
Are you wondering if the PoE splitter connected to my iperf3 server (the little black box with 3 Ethernet interfaces) actually negotiated 2.5 Gbps Full duplex with the switch? Yes, it did. But keep in mind that the PoE splitter is technically only rated for 1 GbE. So use as short patch cable as possible and ideally CAT6.
Still few things to tidy up and perhaps I could build this into a nice Pelican case
If you have not had a chance to see the new Cisco Catalyst antennas for Catalyst 9130AXE access points, here are a few photos of the C-ANT9103 antenna for your reference.
Optionally, you can order an AP + antenna collocation “pocket”, which the Catalyst 9130AXE slides nicely in. It is aesthetically pleasing it, and all it takes to install the AP and antenna is a single mounting bracket. You don’t have to worry about mounting the access point and antenna separately. This drastically simplifies temporary deployments – just think about Cisco Live for example.
Previous generation with a separate AP bracket and antenna bracketThe new collocated, and aesthetically pleasing, solution with AP installed just behind the antenna
Unboxing
Please always refer to the official Cisco documentation for the latest information and package contents.
Apple published a brief summary of the newly introduced “Private Address” Wi-Fi feature. Since it does not go into the detail, I tested the public iOS 14.0 release on an iPhone SE and iPad Mini in my lab. Here is how it actually works.
New Wi-Fi networks
For SSIDs you have not connected to before, iOS 14 devices generate a random MAC “Private Address” and they use this MAC address permanently for this SSID. This address does NOT change over time. This works as expected.
Previously used Wi-Fi networks
Known Wi-Fi networks you have already connected to at least once before the upgrading to iOS 14 get a different treatment though. And this is where things are not as straightforward as the documentation suggests.
After upgrading to iOS 14, I connect to a known network which I have already used before the upgrade. The MAC address that is used is actually the real hardware MAC address of the Wi-Fi adapter for 24 hours. Note that the “Private Address” feature is enabled. This could potentially be considered a UI bug.
24 hours after first connecting from an iOS 14 device to this known SSID, the “Private Address” feature kicks in and the MAC address for this SSID automatically switches from the real MAC address to a randomly generated MAC address. Personally, I assume that this 24-hour period has been developed to allow enterprises to disable Private Address feature on their managed iOS devices using MDM, but I may be wrong.
From this point onwards the same randomly generated Private Address is permanently used for this SSID and does NOT change over time.
Catalyst 9800 controllers come with built-in support for WLAN availability scheduling. When a WLAN becomes disabled, APs do not broadcast the SSID and channel utilisation decreases. Also, it can be implemented as a security enhancement to prevent client devices from connecting during specified hours.
At the time of writing IOS-XE 17.3.1 does not yet offer a GUI for this capability, but there is a couple of options how to schedule WLAN availability.
Before we start, please double-check time settings on the controller, enable NTP client and set a correct timezone.
Option 1: Built-in Calendar Profile
The configuration is self-explanatory, so let’s start with that. My example enables all WLANs mapped to the “default-policy-profile” from 9 am to 5 pm every week day. Outside of these times, the SSIDs will not be available for clients to join.
configure terminal
!
wireless profile policy default-policy-profile
shutdown
!
no wireless profile calendar-profile name WEEKDAYS-9-TO-5
!
wireless profile calendar-profile name WEEKDAYS-9-TO-5
day monday
day tuesday
day wednesday
day thursday
day friday
recurrence weekly
start 09:00:00 end 17:00:00
!
wireless profile policy default-policy-profile
calendar-profile name WEEKDAYS-9-TO-5
action wlan_enable
no shutdown
!
Verification
You can verify using a Wi-Fi client. If you do “show wlan summary”, the WLANs will still appear as “Enabled” and this is expected. To verify current status of WLANs controlled by the Calendar Profile, please use “show logging | include SCHEDULED_WLAN”.
If you like flexibility, an EEM script running on the controller triggered by CRON might work even better for you. Special thanks to Federico Ziliotto for this.
You may have used DHCP Option 43 to point an AP to its controller before. But only very few people know that Cisco APs can automatically convert themselves from the built-in controller mode (think Mobility Express or Embedded Wireless Controller) to Lightweight mode after they receive a special Option 43 from a DHCP server.
If you have a pallet of access points (or routers with built-in Wi-Fi in Mobility Express mode) next to your desk and need to convert all of them to Lightweight mode, simply configure DHCP Option 43 in the following format on your DHCP server and plug them into a PoE capable switch. After the APs boot up and receive the option from DHCP server, they automatically switch to the Lightweight mode and attempt to join the configured controller (192.168.130.2 in our case).
Option 43 format used for AP conversion
f2:05:c0:a8:82:02
“f2” tells the AP that we want it to switch to Lightweight mode
“05” means that only one controller IP address will follow
“c0:a8:82:02” is the controller IP address (192.168.130.2 in this case) in hexadecimal format, search for “IP to Hex Converter” if you do no want to do the math
Cisco IOS/IOS-XE DHCP server configuration
You can run DHCP server on a Catalyst switch. The DHCP scope configuration is straightforward.
ip dhcp pool <pool name> network <ip network> <netmask> default-router <default-router IP address> dns-server <dns server IP address> option 43 hex f205c0a88202
WLAN Pi, Raspberry Pi and any other Linux ISC DHCP server configuration
Special thanks to Nicolas Darchis, who helped me find the “vendor-encapsulated-options” option. It lets you enter Option 43 in the hex format and all it takes is a single line of DHCP server configuration.
If your DHCP server runs on a Cisco Meraki MX appliance, you can easily configure Option 43 using Dashboard. Here are the instructions.
Packet capture or it did not happen
Here is the DHCP Offer packet with the special Option 43 value sent from DHCP server to the APs. They will start the conversion automatically after receiving it.
Verify successful AP conversion to Lightweight mode
Console to one of the APs and you will notice this message:
[*08/25/2020 23:24:39.5620] Last reload reason : 2: AP type changed from ME to CAPWAP
Or you can let the AP finish its job. And then verify successful conversion to Lightweight mode whenever you are ready using the “show version” command.
9120#show version <output omitted> 9120 uptime is 0 days, 0 hours, 5 minutes Last reload time : Tue Aug 25 23:24:39 UTC 2020 Last reload reason : AP type changed from ME to CAPWAP <output omitted>
There is great document explaining how to configure Option 43 on ISC DHCP server on the Cisco website.
If all you need is a simple DHCP server which will assign Option 43 to all devices on the network, without selectively assigning it only to specific AP models using the class construct, you can simplify your ISC DHCP server configuration to this. It works great on a WLAN Pi.
Configuration
# Linux ISC DHCP server configuration in /etc/dhcp/dhcpd.conf
option space Cisco_LWAPP_AP;
option Cisco_LWAPP_AP.server-address code 241 = array of ip-address;
# eth0 DHCP scope
subnet 192.168.73.0 netmask 255.255.255.0 {
interface eth0;
range 192.168.73.100 192.168.73.200;
option routers 192.168.73.1;
option domain-name-servers 208.67.222.222, 208.67.220.220;
default-lease-time 86400;
max-lease-time 86400;
vendor-option-space Cisco_LWAPP_AP;
option Cisco_LWAPP_AP.server-address 10.10.10.10, 10.20.20.20;
}
Verification
The access point will get its IP configuration from the DHCP server including Option 43 and will try to join these controllers.
Here is how to configure Option 43 on an MX appliance for a Cisco Aironet or Catalyst AP to discover its Wireless LAN Controller (WLC).
My Catalyst 9800-CL controller IP address: 173.38.219.33
Meraki MX appliance DHCP server configuration
Open Dashboard and go to Security & SD-WAN > Configure > DHCP > scroll down to the right VLAN > DHCP options > Add a DHCP option:
Format of the hex string
In my example, the final string would be “f1:04:ad:26:db:21”
“f1:04” tells the AP that only one WLC IP address is used, followed by the actual address “ad” is hex representation of 173 “26” is hex representation of 38 “db” is hex representation of 219 “21” is hex representation of 33
To convert the 4 decimal octets of the IP address to hexadecimal format, you can use this online tool, macOS Calculator or Windows Calculator.
Verification on the AP
Two controllers
If you provide the AP with IP addresses of 2 standalone controllers (think N+1 HA mode), then simply change “f1:04” to “f1:08” and append the second controller’s IP address in hex representation to the end of the hex string.
Primary controller IP address: 173.38.219.33 Secondary controller IP address: 173.38.219.34 Hex string: f1:08:ad:26:db:21:ad:26:db:22
