IOS XE 17.2.1r: Single again and Ready to Mingle!

[Sumant Mali]

A decade of close engagement with IOS XE Routing platforms has got me once again thinking passionately. It’s about the Enterprise Routing Platforms, about the legendary IOS XE Software!

A lot of us who are fortunate to have the treasured confrontation with the beauty of centralized forwarding, distributed control hardware and modular software architecture on IOS XE platforms love them for so many reasons. 

Three years ago, when Cisco acquired Viptela, the integration led to the birth of IOS XE SD-WAN software image. The IOS XE software binary was parted into two image types, ‘universalk9’ for traditional IOS XE use-case and ‘ucmk9’ for IOS XE SD-WAN use-case.

Here is the good news! On 14^th April 2020 Cisco released IOS XE 17.2.1r, a single ‘universalk9’ image for IOS XE Enterprise Routing Platforms for IOS XE and IOS XE SD-WAN use-cases. 

The IOS XE software image is ‘Single again and Ready to Mingle!’ 

What exactly is changing with 17.2.1r?

IOS XE Release 17.2 onwards, there will be a single software image of type ‘universalk9’. This single image can be used to deploy both IOS XE and IOS XE SD-WAN use-cases on supported platforms. The ‘ucmk9’ image will no longer be available.

• Autonomous mode: The single image offers Cisco IOS XE functionality through ‘Autonomous’ mode operation. It is the default mode of boot for single image.
• Controller mode: Cisco IOS XE SD-WAN functionality can be accessed via ‘Controller’ mode enablement. The controller mode needs to be enabled.  

Wow! This is a big transformation from software instrumentation point of view. And it comes with added simplicity, ease of use and various device onboarding methods. Let us dive into image upgrade scenarios.

Greenfield Single Image Upgrade Scenario:

A greenfield image upgrade is a fresh installation using IOS XE 17.2 onward software.

• For IOS XE deployment: The device boots into autonomous mode as default mode using single image. Then it can be provisioned using PnP workflows or manually using CLI configuration or bootstrap configuration.
• For IOS XE SD-WAN deployment: The device 1^st boot in autonomous mode. Then it has to be provisioned into controller mode using PnP, bootstrap or manual CLI option. Once the controller mode enabled, the device boots 2^nd time to get provisioned into controller mode.

Brownfield Single Image Upgrade Scenario:

A pre-deployed device will experience a seamless upgrade to IOS XE 17.2 onward software. Zero configuration loss is expected. The Single Image understands the operational mode during boot up sequence and directly boots into the relevant mode.

• For IOS XE deployment: The device directly boots into autonomous mode and provisions existing configuration from the startup-config in NVRAM.
• For IOS XE SD-WAN deployment: The device directly boots into controller mode to provision the existing configuration as per config database.

IOS XE Release 17.2 streamlines PnP workflows across ‘autonomous’ and ‘controller’ mode use-cases. It is supercool to boot the device into the desired mode of operation using PnP and bootstrap workflows.

PnP Day-0 Provisioning using Single Image:

The Plug and Play portal orchestrate devices in the Smart/Virtual accounts for proper controller profiles. Newly ordered device details get automatically populated into related Smart/Virtual Account.

• The network admin then attaches each device with its controller profile in PnP portal.
• IOS XE SD-WAN controller profile -> organization name, vBond details.
• IOS XE controller profile -> DNAC/NSO/ZTP PnP Server details.

Once this is done, we are ready to provision the new devices in desired mode using IOS XE 17.2 onward software. Follow the blue and orange paths along with the numbers in below flow chart, depicting phases in the process.Autonomous Mode PnP Provisioning: blue path

• Device boots up in in autonomous mode with single image. The PnP agent on the device initiates and reaches out to devicehelper.cisco.com.
• PnP Connect portal will do device Serial Number look up to find associated ‘controller profile’.
• Once found, device will be redirected to associated DNAC, NSO, ZTP (via DHCP options) and the ‘autonomous’ mode configuration provisioning can happen.

Controller Mode PnP Provisioning: orange path

• Device goes through first 3 phases of autonomous mode transitions.
• After serial number look up in PnP portal, the device gets redirected to vBond as per SD-WAN controller profile.
• Single image auto-triggers the mode change to controller mode. After reboot the PnP agent in controller mode again reaches out to devicehelper.cisco.com, gets redirected to vBond and further provisioning happens for the SD-WAN use-case.

If the device does not have any controller profile attached in PnP portal, the PnP agent on device will continue to stay in ‘autonomous’ mode. And keep looking for PnP redirection or manual provisioning.

Bootstrap Onboarding with Single Image:

Yes, the legacy method of device onboarding with bootstrap configuration are also available in both the modes. As soon as the device boots up, it will check for availability of specific ‘.cfg’ bootstrap file in device bootflash, usb path and boots into desired mode. The table below lists the options.

The virtual platforms like CSR1000v, ISR1000v and OTP authenticated devices like ASR1002-X will use ciscosdwan_cloud_init.cfg file containing OTP but no UUID for validation. The bootstrap provisioning is seamless for autonomous as well as controller mode provisioning.

Are you excited for 17.2.1r single image release? The need of downloading certain image for individual use-case is going away. One image per platform and network administrators will be able to use it for desired use-case with simplified onboarding via PnP, manual or bootstrap ways. On a side note, High Compliance Customers will be able to certify one IOS XE image for multiple use-cases and use it as needed. More the flexibility, superior the provisioning orchestration! 

Conclusion:

The legendary IOS XE software is putting a strong foot ahead with Single Image software instrumentation. It offers ease of operations, flexible device onboarding and simplicity in software image management.

The Single Image is indeed ready to mingle with traditional IOS XE as well as IOS XE SD-WAN use-cases. It is all set to lead the software defined networking era, highly programmable and The Network. Intuitive.

Learn more about Single Image, PnP here: Install/Upgrade, SD-WAN PnP, Bootstrap Provisioning.  

[Leo Laohoo]

How can I tell if the version (not the filename) being mentioned in Cisco publication, for example Bug IDs, is a ROMMON version or an autonomous/controller firmware?

[Sumant Mali]

Yes Leo, good point. This time the switching and wireless IOS XE releases were done couple of weeks before the routing IOS XE release was posted. This 'r' is only to identify it is routing specific 17.2.1 version.

[Leo Laohoo]

---

@Sumant Mali wrote:

This 'r' is only to identify it is routing specific 17.2.1 version.

---

I'm just asking.  

Since the new "r" stands for "routing", it can also mean "ROMMON image".  How can the public differentiate if the file is the new merged IOS file or a ROMMON image? 

[Sumant Mali]

Hi Leo,

The Rommon images usually will have .pkg file when it comes as a separate entity. The IOS XE software image files are usually .bin files for the specific release. This should be one quick identification. 

e.g. 

asr1000-rommon.169_5r_SPA.pkg  -- > Rommon image

asr1000rpx86-universalk9.16.09.05.SPA.bin --> RP2/RP3 software image

Hope this helps.

Sumant

[Leo Laohoo]

Ok, let me approach this from a different angle. 
Have a look at the files for, say, an ISR 4400: 

isr4400-universalk9.17.02.01r.SPA.bin

Above is the new "unified" routing firmware for an ISR 4400.

isr4400_rommon_1612_2r_SPA.pkg

Above is the ROMMON for the ISR 4400.  

Now have a look at CSCvr18589.  

To an un-trained eye, versions 16.9.1r, 16.12.1r, 16.12.2r looks like "unified" routing firmware. 

Since I have long considered the information found in the Bug IDs to be notoriously inaccurate, the point I am trying to get to is this:  How are future information/documentation going to differentiate that X.Y.Zr actually means a "unified" routing image and not a ROMMON file (or vice versa)?  

[Sumant Mali]

Hi Leo, 

"

isr4400-universalk9.17.02.01r.SPA.bin

Above infact is a IOS XE Software image for ISR4400 platforms. 

As I hinted in my previous response, the '.pkg' vs '.bin' should be a simple hint on identifying a rommon/firmware vs release software image respectively.

As you also notice in CSCvr18589, the usual way of representing any rommon release version is 16.9(1r), 16.12(1r) and so on. Where the digit associated with 'r' character is put in round brackets. 

There are multiple such ways to identify the two. 

But I do agree, as you said, it can get missed for an untrained eye. :) cheers.

[helloguys]

I'm running 17.2.1r on CRS 1000v.  I generated bootstrap file from vManager and put it on bootflash: with file name ciscosdwan_cloud_init.cfg.  Rebooted the router.  But the router is still in autonomous mode instead of controller mode.  I also tried with file name ciscosdwan.cfg.  No luck.

What did I do wrong?  Thanks!

[Sumant Mali]

For bootstrap to work, we need to make sure there is no existing configuration in IOS XE or IOS XE SD-WAN use-case point of view. That will make the software think that device is pre-provisioned. Can you please make sure on that front? CSR1000v should boot using ciscosdwan_cloud_init.cfg file as well.

[Leo Laohoo]

Hi @Sumant Mali, 

Is Amsterdam-17.3.1 a "single software release" or a "non SD WAN" version?

[Sumant Mali]

@Leo Laohoo , sorry missed to respond earlier. 

Yes all releases for IOS XE Routing platforms post 17.2 will be single image software. 17.3.1a is single image software. 

[Leo Laohoo]

---

@Sumant Mali wrote:

Yes all releases for IOS XE Routing platforms post 17.2 will be single image software. 17.3.1a is single image software. 

---

So why is 17.3.1 release not called 17.3.1r? 

So why is 17.2.2 release not called 17.2.2r? 

NOTE:  Someone needs to pull this board off because things are getting very "laughable".  

[Sumant Mali]

hi Leo, inline below:

So why is 17.3.1 release not called 17.3.1r? 

So why is 17.2.2 release not called 17.2.2r? 

>> 17.2.1r was called with 'r' tag there for 'Routing' specific release only as one time exceptional tag for that occurrence only. Let me tell you the background info on that: at 17.2.1 release posting time, the routing specific IOS XE release was delayed and IOS XE switching, wireless platform release code was posted earlier. While building routing specific release for posting, we needed to give a different label, that is where the 'r' tag character was used. It does not mean all future routing release will have this character tag as mandatory. This has been practice to use small letter character tags also in form of 'a', 'b' ... and so on. Hope this helps.