EoS and EoL roll-up for Cisco AirOS Wireless, ASA, and Switching

End of Sale and End of Life dates for AireOS Cisco Wireless LAN Controllers – AIR-CT-3504AIR-CT-5520AIR-CT8540AIR-CTVM 

End of Sale and End of Life dates for ASA 5506, 5512 & 5515, 5508 & 5516, 5525, 5545 & 5555, 5585-X, 5585-X FP

End of Sale and End of Life dates for Cisco Catalyst – 2960X/XR2960L/P3650SUP9E


Evolving Smart Licensing, what’s coming and when?

Does anyone else feel like they need a Ph.D. in Cisco licensing?! Good news is that there are some changes coming to help make our lives easier.

Most of you are likely familiar with Smart Licensing. However, you can go here if you need more information. During Cisco’s transition to subscription-based licenses, Smart Licensing (SL) was introduced. Cisco believed Smart Licensing would streamline the way customers activate and manage Cisco licenses across the organization. Transitioning from the traditional PAK based licensing method to SL wasn’t the only goal for Cisco. Amongst others, it served as a way to combat the grey market gear. The thought was that upon purchasing a product from Cisco, a Smart Account would be associated with the order, which in return would entitle the organization to their licenses, products, and services.

A Smart Account is hierarchical and serves as the top-level domain for the organization. You can further organize your Smart Account into sub-accounts, known as “Virtual Accounts.” It is very much structured, like a domain. A “DEFAULT” Virtual Account serves as your catch-all bucket and is persistent and can’t change.

After Cisco launched the new licensing model, they found that the customers purchasing processes became complicated, increased their operational overhead, and challenged their security practices. Therefore, Cisco took this feedback and decided they needed to evolve SL to be less detrimental. 

You can find the current list of Smart License enabled products here

Introducing Smart Licensing Using Policy

Starting with IOS-XE 17.3.2/17.4.1 all products running these versions of the software will only support Smart Licensing Using Policy. These currently include. 

  • Cisco Catalyst 9000 series switches. 
  • The routing platforms such as the ASR1K, ISR1K, ISR4K. 
  • The Next Generation virtual routers starting with Polaris IOS-XE release 17.4.1 
  • Cisco Catalyst 9800 Series Wireless Controllers and APs. 
  • Internet of Things (IoT) Next Generation platforms such as Industrial Router IR 1101, Industrial Ethernet IE
  • 3200/3300/3400 and any Next Gen IoT products will also adopt Smart Licensing Using Policy. 
  • Collaboration products; CUBE, SRST, and CME with their November release.

With Smart Licensing Using Policy you can expect: 

  1. The product will not boot in evaluation-mode (see screen shots below)
  2. per product software registration is not required
  3. And on-going communication every 30 days with Cisco isn’t needed.

Registering a device before use and on-going communication is going away. However, reporting to Cisco may still be a pain point. The good news? Reporting is only required if there is a change in software level for Perpetual or Subscription. Changing software levels doesn’t happen too frequently, so it may not be too big of an issue. 

For example, if you purchase a Catalyst 9120 access point with DNA Essentials from the factory and 30 days later, you realize you need EasyQoS. You’d have to change to DNA Advantage, which means you now need to report this change to Cisco. 

This change would need to be reported within 90 days to Cisco. 

What happens if you don’t? Most of the products will turn into a nag box, sending out syslog/alarm notifications. However, you should review the enforcement rules specific to the particular device to avoid potential interruptions.

You can find the enforcement rules per product here


You can report to Cisco in a couple of different ways. 

1. New reporting utility called Cisco Smart Licensing Utility (CSLU): which is a small Windows application that can be configured to send the data to Cisco in with a push or pull operation. 

2. Cisco DNA Center controller with Cisco Smart Licensing Utility (CSLU): Cisco DNA Center has connectivity to Cisco Smart Software Manager (CSSM). Periodically, exchange information with Cisco to keep in sync with CSSM. 

3. Offline: where the data is taken off the device onto a storage and then uploaded into CSSM.

In the end, not having to register a product before makes sense but reporting may be still be cumbersome. I’m thinking theres a way you could script this with Python.

Here’s a screen shot of pre IOS-XE 17.3.2 and post IOS-XE 17.3.2.


Smart Software Licensing Overview. (2020, November 26). Retrieved from https://www.cisco.com/c/en/us/products/software/smart-accounts/software-licensing.html

Cisco DNA Software Subscription Matrix for Wireless. (2020, November 17). Retrieved from https://www.cisco.com/c/m/en_us/products/software/dna-subscription-wireless/en-sw-sub-matrix-wireless.html?oid=porew018984

(n.d.). Retrieved from https://www.cisco.com/c/dam/en/us/products/collateral/software/smart-accounts/smart-licensing-feature-roadmap-by-pf-external-v20201102.xlsx

(n.d.). Retrieved from https://software.cisco.com/download/home/286285506/type/286327971/release/1.0.0-2

Cisco IOS XE Gibraltar 16.11.x

There is somewhat of a major caveat when upgrading to IOS XE Gibraltar 16.11.1 that you must consider before upgrading.

When upgrading to IOS XE 16.11.1, on Cisco Catalyst 9500 Series Switches (C9500-24Y4C, C9500-32C, C9500-32QC, and C9500-48Y4C) . The default switchport state changes from a Layer 3 switchport to a Layer 2 switchport. Which means when you reload your switch with IOS XE 16.11.1, your switchports will be in a Layer 2 switchport state by default. This will break your routed infrastructure if you do not perform the pre-installation tasks!

The reason for this changes is to enable day 0 discovery when using Cisco Digital Network Architecture (DNA) Center (or Cisco DNA Center).

You have the option to change the L2 interfaces back to L3 by performing this manually or scripted. It’s completely up to you how you handle this step but Cisco does provide a step by step guide on how to script this procedure.

Below is the release notes for this version which includes the pre-installation procedures to ensure that after a reboot your Layer 3 ports maintain their Layer 3 state.

I will try to get my hands on a 9500 to perform this and will report it here. For the mean time please refer to the below.

IOS XE Gibralter 16.11.1 Release Notes


What is a fabric?

I get the question a lot. What is a fabric? Most have an idea of what it is, but its a blurry idea. Fabric is a word that is being thrown around by many. It can be intimidating to ask, what exactly is a fabric. So today our goal is to provide an overview to the question. What is a fabric? I define it in the first section but get into some of the components throughout the post.

A fabric is a two layer construct. There is an underlay which is your physical make up of the network. Responsible for moving the packet. The overlay is the abstract service layer, it is responsible for things such as policies, segmentation, and mobility. Some overlay technologies that you may be aware of: CAPWAP, GRE, MPLS, DMVPN, OTV, ACI, LISP.

Overlays can come in two ways:

Layer 2 Overlays – Offers single subnet mobility within layer 2, extending L2 flooding.
Layer 3 Overlays –  Offers IP mobility, Transports IP packets, contains failure domains.

So the new term for a LAN enabled fabric is ‘campus fabric’. However, its commonly shortened and referred to as a fabric or a fabric domain.

The campus fabric can be summarized as having

  1. LISP based Control-Pane
  2. VXLAN based Data-Plane
  3. Integrated Cisco TrustSec (policy plane)

Let’s pause to define some terms within the Campus Fabric. Don’t glaze over on me! Just be aware of these terms, no need to know them inside and out for this overview.

Control-Plane Node = LISP Map-Server : is a node in the fabric responsible for resolving EIDs to RLOCs
Edge Node = LISP Tunnel Router (xTR) : responsible for encapsulating the packet at the edge of the network and authenticating endpoints.
Border Node = LISP Proxy Tunnel Router (PxTR) : responsible for de-encapsulating the packet or encapsulating the packet when entering or leaving the fabric. Any traffic entering or leaving the fabric goes through this node. You NEED at least one of these.
Intermediate Node = Non-LISP IP forwarder : Imagine a 3-tier architecture; Access-Distro-Core, the Distro would be your intermediate nodes.
Fabric Domain = FD = LISP Process
Virtual Network = VN = LISP Instance = VRF : Maintains a separate Routing and switching instance for each virtual network
Endpoint ID Group = EIG = Segment = SGT : Each user of device is assigned to a unique Endpoint ID Group
Host Pool = Dynamic EID = VLAN + IP Subnet : Provides the basic IP constructs including Anycast Gateway.

Screen Shot 2018-11-01 at 8.39.05 AM

LISP overview

Locator ID Separation Protocol – Now read that back sloooowly.. It’s self defining. LISP is separating IP(ID) from location(Locator).

LISP at it’s simplest form is nothing more than a mapping system but is a routing architecture, a control plane protocol and a data plane protocol. It separates Identity from a Location.

A devices IP (identity) is generally associated to a location of that device. If a device wants to roam to a new location the device needs a new IP (identity) for that location.

Screen Shot 2018-11-01 at 8.38.43 AM

From a design perspective you can see how this can be helpful. This is just like when you roam between cell towers with your cell phone. Your location changes but your cell phone number (identity) does not.

LISP will assign End-point Identifiers or EID to hosts and will take on the role of acting as the devices identity. I don’t want to confuse you, EIDs do not replace a devices IP. EIDs are there to help RLOC map a device to a location.

Screen Shot 2018-10-31 at 4.19.09 PM

Routing locators or RLOCs map End-point Identifiers (EID) to a current location. The control plane node is responsible for doing this. RLOCs should be viewed as the Control plane protocol for LISP.

LISP mapping system can be analogous to a DNS resolution where DNS queries answer the “WHO IS” question and LISP resolution answered the “WHERE IS” question.

Why do I care about LISP? Because the fabric overlay is LISP enabled!

VXLAN Data-Plane Overview

VXLAN Encapsulation is used to carry L2 information. This is necessary because if we were to run LISP only, we would not be able to carry L2 information. LISP payload only supports L3 information. So, to achieve L2 and L3 capabilities, we run VXLAN.

Screen Shot 2018-11-01 at 8.38.55 AM

What is Cisco TrustSec?

TrustSec (CTS) takes the complexity away from the static ACL and uses a tag based mechanism. So instead of creating enforcement on an IP you create enforcement around a tag which allows for mobility.

Lets wrap things up with a list of platforms that support campus fabric.

Fabric Edge Nodes

  • Catalyst 9300 – IOS-XE 16.6.3+
  • Catalyst 9400 – IOS-XE 16.6.3+
  • Catalyst 3K – IOS-XE 16.6.3+
  • Catalyst 4500 Sup8E+ – IOS-XE 3.9+

Fabric Border Nodes

  • Catalyst 9500 – IOS-XE 16.6.3+
  • Catalyst 3K
  • Catalyst 6800 Sup2T/6T – IOS 15.4SY+
  • ASR-1000-X/HX – IOS-XE 16.4+
  • ISR4K – IOS-XE 16.4+
  • Nexus 7700 w/ M3 cards – NX-OS 7.3.2+

Fabric Control Plane

  • Catalyst 9500
  • Catalyst 3K
  • Catalyst 6800 Sup2T/6T
  • ASR-1000-X/HX
  • ISR4K

Lab it up! You only need three switches to test this out.

You can use the command ‘fabric auto’ which will automatically generate the necessary LISP and VXLAN configurations on the device so that the device can join the fabric.

For example:

Edge(config)# fabric auto
Edge(config-fabric-auto)# domain default
Edge(config-fabric-auto)# control-plan auth-key key1
Edge(config-fabric-auto)# border

I hope that this served as a basic overview to campus fabric. It is the behind the scenes magic of intent based networking.


Converting Cisco IOS-XE Software from Bundle Mode to Install Mode

Recommended Releases for Cat9k

Today we’re are going to be converting a Cisco WS-C3850-24XS from a Bundle Running Mode to an Install Running Mode.

If you haven’t read my other post on operating modes for the Cat3k or 9Ks, look there first. Upgrading Cisco IOS-XE Software (Install Mode)

You can also review upgrade procedure for specific hardware.
Catalyst 9200 upgrade procedure or review Campus switching positioning with Catalyst 9Ks for a quick reference to determine what hardware is best suited for your campus.

I first want to show you the file(s) that each mode references. I’ll use the show version command to do this.


You can see from the previous output that the 3850 is running in BUNDLE mode. Secondly, the line that starts with ‘System image file is..” This line is the name and location of the booted Cisco IOS XE bundle file. Notice that this is a .bin extension.


Again using the show version command, in the previous output the 3650 is running in INSTALL mode. This time the line that starts with ‘System image file is..” is referencing the name and location of the provisioning file ‘packages.conf‘.

Let’s continue changing our Bundle running mode to Install running mode.

To do this, execute the command below in exec.

3850# software expand running to flash:


I am executing this on a stack so you can see that the operation is expanding the bundle (.bin) file to switch 1 and switch 2. This is essentially unpacking .pkg files from the running .bin file on the switch.

Notice that the switch attempts to create a packages.conf file but it already exists, so it creates a file called ‘running-packages.conf‘. This isn’t a big deal. If you want your file to be named packages.conf, just rename the original packages.conf to something else before you run the above command.

After this finishes, we can view the flash:/ to see our pkg files.


Here we see two .pkg versions, 03.07.04E.pkg and 03.07.05E.pkg. Which one is the most recent one? 03.07.05E.pkg is the most recent because that is the version we extracted from our current running cat3k_caa-universalk9.SPA.03.07.05.E152-3.bin file. Also, notice the running-packages.conf file.

Let’s change the boot system variable to reference our new .conf file.


Note: Check to see if you already have a boot variable defined. Change it so that on next boot you load your packages.conf file and not the .bin file. Check the boot var with the command show boot to confirm.

Save your running config to start up and reload the switch.

After the reload, we can check our running mode.


Lets clean up our flash directory.


Here is the flash directory after we cleaned it.