We are pleased to announce the immediate availability of the IOS-XE release 17.3.1 for the Catalyst Wireless Controllers. The new code is now posted on the CCO and can be found at this link:
The section below provides information about the key new features and enhancements in the 17.3.1 release.
The C9105AXI and C9105AXW APs are ideal for cost-sensitive Wi-Fi 6 customers. Both of these are 2x2 on 2.4GHz and 5GHz bands and have a Gigabit Ethernet uplink. The infrastructure variant, which is a miniature version of the other Catalyst APs, is a ceiling mount and comes with all the capabilities of 802.11ax. The wall plate variant has a mGiG uplink because it provides three wired ports in addition to being Wi-Fi 6 ready. It comes with a wall-mount option and it is mounted similar to the 1815W.
Both of these have Wi-Fi 6 capabilities of OFDMA, BSS coloring, MU MIMO, and TWT and also, a built-in IoT radio for BLE, Zigbee, and Thread. The C9105AXW has a mGiG port, a USB 2.0, and POE out on one of the ethernet ports. They are both supported by Cisco DNA Center cloud and Cisco DNA Center on-prem.
We’ve had embedded wireless in SDA mode on Catalyst 9K switches before 17.3 using which it is possible to do deployments across multi-site architectures today. What we are introducing is the capability to introduce single-site wireless in a non-SDA deployment. This functionality can be enabled only via web UI on the Catalyst 9K switches. The control plane is CAPWAP from APs to the controller and the data plane is VXLAN tunnels.
The scale supported is 200 APs and 4000 clients per switch or up to 400 APs and 8000 clients per site with 2 switch stacks. Each one can independently be in SSO mode and they can be in N+1 between each other. Both direct and indirectly connected APs are supported in this mode.
This is supported by 9300L, 9300, 9400, and 9500 with a scale of 9300-L being half of the other variants.
In the virtualization and the cloud era, higher throughput for virtual instances is the demand from customers.
This release introduces three new variants for high throughput on small, medium, and large 9800-CL templates. These high throughput templates increase throughput in the order of about 30% compared to the low throughput templates.
High throughput templates require an additional 3 vCPUs that are allocated to data plane processing. Starting 17.3 on ESXi and KVM, we also support SR IOV. And what SR IOV is a specification that allows a PCI device to appear to be multiple separate physical PCI devices. Each virtual machine is directly assigned and given access to the physical resources (like network virtual functions) by the hypervisor. As a result, it improves controller packet forwarding performance by allowing traffic to bypass the host machine’s network sta. Finally with the support for ISSU and additional logging it requires higher disk space for functionality so the disk size recommended for all C9800-CL is now 16 GB.
In-Service Software Upgrade (ISSU) is a procedure to accomplish a wireless controller upgrade while packet forwarding continues uninterrupted which increases the network availability and reduces downtime. ISSU provides a complete image upgrade from one image to another without network downtime. All AP and client sessions are maintained, and the procedure is carried out natively from the controller without the need for an external orchestrator. Using the mechanisms of rolling AP upgrade and client steering with 11v, customers can upgrade their networks without scheduling a downtime window.
This feature enables monitoring the health of the system on standby controller in an HA pair using programmatic interfaces (NETCONF/YANG, RESTCONF) and CLIs without going through the active controller. This includes monitoring parameters such as CPU, memory, interface status, PSU (Power Supply Unit) failure, fan failure, and temperature. This feature is supported on the Cisco Catalyst 9800-CL private cloud, 9800-L, 9800-40, and 9800-80 wireless controller.
Wi-Fi operates in unlicensed 2.4- and 5-GHz bands. Many devices, such as microwave ovens, cordless phones, and Bluetooth devices also operate in these bands and can severely impact Wi-Fi performance. The Spectrum Intelligence feature scans for non-Wi-Fi radio interference on 2.4-GHz and 5-GHz bands and provides basic functions to detect interferences of various types, for instance, microwave oven which operates in the 2,4 GHz band, continuous wave (like video bridge and a baby monitor), wi-fi and frequency hopping (like Bluetooth and frequency-hopping spread spectrum cordless phones). Keep in mind that SI only shows the most damaging interference. E.g. video devices would be displayed over a microwave oven. And a microwave oven would beat out a cordless phone and or a Bluetooth device.
The Cisco Catalyst 9130 Series access point can run 5 GHz in 8x8 or dual 4x4 mode. The default mode on the 9130 Series is 5-GHz 8x8 and 2.4-GHz 4x4 mode. This default mode provides the highest throughput per single radio, with performance gains mainly in MU-MIMO client environments. Presently, in mixed client type environments, it can be beneficial and produce higher capacity outcomes by using dual 4x4 interfaces.
Flexible Radio Assignment (FRA) allows the access points to intelligently determine the operating mode of serving radios based on the RF environment and traffic demands and can dynamically switch between 8x8 5GHz and dual 4x4 5GHz mode. Furthermore, in the 4x4 Dual 5GHz mode, FRA can decide between 5GHz and monitor radio role. In auto mode, the available choices for FRA will be between client-serving and monitor and will be assigned by FRA based on the number of active 5-GHz interfaces that are available and the availability of non-interfering channels for assignment to the first and second 5-GHz interface.
This set of enhancements for rogue detection is around enhancing the detection of rogue impersonation. Release 17.3 adds information about the Direct-Sequence (DS) parameter set which indicates the channel number used by the rogue AP. If an impersonation attack is detected, we check to see if the channel used by the rogue matches one of the recent channels used by our managed APs. If it doesn’t, we raise it as an alarm.
All Cisco APs in the same RF network share a domain secret that allows them to authenticate each other. This is present in beacons and probe responses. If the AP authentication IE has an incorrect signature field, or the timestamp is off, or the AP Authentication IE is missing, the rogue is moved to malicious list and marked as a threat. This can be enabled in the Web Interface.
Infrastructure MFP adds message integrity checks to the management frames transmitted by managed APs. This way managed APs can validate other APs they can hear over the air. When infrastructure MFP is enabled and managed APs find that the message integrity check is missing or not as expected, it gets flagged in the rogue report as rogue impersonation
A wireless denial of service attacker can take advantage of the privilege granted to the RTS ( Request to send ) and CTS ( Clear to send) frames to reserve the RF medium for transmission. By transmitting back-to-back CTS and RTS frames with a large transmission duration text box, an attacker reserves the wireless medium and force other wireless devices to share the RF medium to hold back their transmissions. With 17.3.1 we can detect these two types of attacks with the base signatures on the 9800.
The mDNS feature has been supported on 9800 controllers for a while now, starting release 16.10. Release 17.3 introduces mDNS Gateway support on the FlexConnect APs supporting a maximum of 1024 services providers per FC site. This feature supports 64 services (e.g. iTunes, Airplay, AirPrint, etc) and up to 16 instances of each service.
Using the Gateway database and function implemented on the APs, FlexConnect APs can distribute the mDNS service information across IP subnets to clients without the need of the controller other than the initial phase of configuration. Just like the mDNS gateway on the C9800 controller, the mDNS gateway on AP can function in 3 different modes. These mode configurations will be pushed from the controller to AP (mode configuration is per WLAN): mDNS gateway (mDNS snoop) mode, mDNS bridge mode, or mDNS drop mode.
Cisco’s Application Hosting on Catalyst APs feature at a high-level provides users with the ability to load 3rd party containerized IOx applications directly onto Cisco’s access points to leverage them as an IoT gateway. Once loaded, the 3rd party application now gains complete access to specific access point software and hardware resources. Depending on the IOx application developed, it can have the ability to promptly communicate with 3rd party software through its internal VLAN, and hardware through its external-facing USB port. A typical business running a Cisco powered wireless infrastructure will have access points deployed throughout all employee inhabited facilities. With the ability for 3rd party vendors to create applications and leverage these access points as IoT gateways, it has created endless possibilities for the Internet-of-Things movement. Cisco DNA Center provides the option to download an Application Hosting package and install these packages on top of the base Cisco DNA Center software.
The Cisco Teleworker solution is based on Cisco Office Extend AP (OEAP). This solution has been available even before 17.3 but is being relaunched with additional testing and use-cases. It is specifically designed to allow teleworker users to connect their corporate devices to the organization's on-site wireless network. This way remote workers can have the same level of application experience and security as they have in a corporate office. IT admins can provision, manage, and deploy consistent policies across all distributed home and micro-offices remotely and securely via a centralized device like the controller and Cisco DNA Centre.
For the zero-touch experience, customers can use the plug and play application to pre-provision the site and add Cisco access points to the site. We also support split tunnel on the OEAP solution which allows traffic to be locally switched for local devices and applications which avoids the extra latency and WAN bandwidth consumption.
When on a home network, it’s easy enough to use streaming technology, such as Google Chromecast or Apple Airplay, to stream movies and TV shows. In a shared network environment, such as a school dormitory, it can be much harder to find your TV among all the other student’s devices. This can also cause confusion and annoyance as students can accidentally stream to a device owned by a different student. This problem is not just limited to streaming to a TV but for any device using Link-Local Multicast protocols.
Cisco UDN (User Defined Network) solves this problem by segmenting the user’s devices while still being on the same SSID. Users will be given their own private UDN where only devices they register will be allowed to communicate with each other. This eliminates the problem above and creates a more secure network environment.
Users will be given access to the Cisco UDN application, available on the Google Play Store or Apple App store, which will be used to register the devices MAC address before arriving at the shared network environment.
Uplink Multi-user multiple-input and multiple-output (UL MU MIMO) feature is supported in Cisco Catalyst 9130 APs in this release. This is conceptually similar to Downlink MU-MIMO, which is already supported in Cisco Catalyst 9130 APs and allows multiple clients to send traffic
simultaneously, thus saving air time. It is supported in 20-MHz, 40-MHz, and 80-MHz channels, but not supported in the 160-MHz. It is only supported only in the 5-GHz band ad is limited to support three users. When more than three users are connected, UL MU-MIMO scheduling does not occur, and the AP falls back to single-user (SU) transmission.
Both Uplink and Downlink Orthogonal frequency-division multiple access (UL OFDMA and DL OFDMA) features are supported in Cisco Catalyst 9130 APs in this release. Before 17.3 this was limited to support eight users in a DL OFDMA transmission. In this release, 37 users are supported in 80MHz and 160MHz.
In some deployments, IT wants to assign a different VLAN to a campus-wide SSID according to the location from where the client is joining. For example, if the client joins from building 1, assign it to VLAN 10, if they join from building 2, assign VLAN 20, and so on. This can be easily achieved by using a different policy tag per group of APs in those buildings and mapping the same SSID to a different policy profile (where the different VLAN is defined). Until 17.2, C9800 doesn’t support seamless roaming across the same SSID but different policy profiles. This is possible with 17.3 and the client will retain the original VLAN and IP without disconnecting even when the client roams across different policy profiles associated with the same SSID
A mismatch in the controller and AP operational status can result in a service impact for wireless clients. This includes instances where the controller and AP are out of sync on configurations.
To detect this, two flagging mechanisms have been provided in IOS Release 17.3
Config Checker: This feature helps in auditing the application of wireless policies during the AP join phase. Any discrepancies at this stage is reported on the controller. When you try to configure any of the AP attributes: name, IP address, controller info, tag, mode, radio mode, and radio admin state, AP parses the CAPWAP payload configuration from the controller and reports error detected back to the controller with proper code. If a discrepancy is detected, the controller flags the error using a syslog.
Config Audit: This feature helps to perform a periodic comparison of operational states between AP and controller post the AP join phase and while the AP is still connected. Any discrepancies are reported immediately on the controller. When triggered, AP sends configurations from the database to the controller and the controller compares the configurations against the current configuration. If a discrepancy is detected, the controller flags the error using a syslog.
The Hotspot 2.0 R3 has added options such as new ANQP elements, Terms & Conditions, and integration of OSEN security and WPA2 security on the same SSID. As part of Passpoint R3, it is possible to enable both WPA2 & OSEN on the same SSID. This means having a single SSID for both Encrypted Online sign up and Hotspot 2.0 SSID. Also, when a wireless client connects to a Hotspot 2.0 SSID, the RADIUS server can ask the user to accept some terms & conditions before the user can browse the internet.
With more and more devices turning on the MAC Randomization and MAC privacy when connecting to the Wireless network, this tends to break quite some functionalities like MAC filtering, CWA, etc. in the network.
With Android 10 turning this on by default and Apple iOS 14 going the same way, the first step is to identify that the client is using the Random mac or Locally Administered Address (LAA). LAA is a type of administered MAC address, and it is possible to change the LAA of a network adapter to any address of allowed length. When the LAA is set, the network adapter uses the LAA as its MAC address. Otherwise, the network adapter uses the Universally Administered Address (UAA) as its MAC address. Some clients pick a random LAA and use that for the association to the wireless network. Such clients will use that MAC address with the BSSID throughout the association. The client may decide to use another LAA on the next day depending on the client’s implementation. Upon association, the Catalyst 9800 checks if the client MAC is a locally administered one. This is very useful for network administrators when they get log messages about a given client by checking client details
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.