Flexible Packaging - Easy Routine Upgrades and Maintenance

Flexible packaging is an enhancement that modularizes the Cisco IOS XR operating system as RPM packages. Redhat Packet Manager (RPM) based delivery of packages enable easier and faster system updates.

The base software is leaner, containing only required mandatory packages. Other optional packages are separated and made available as individually installable RPM packages. Users have the flexibility to select and install the services they want, by choosing relevant optional RPMs.

Flexible packaging also supports automatic dependency management, where, while the user is updating an RPM, the system identifies all relevant dependent packages and updates them. The system uses standard LINUX tools to manage dependency during upgrades.

The base software is the minimum mandatory package (with utilities), required for the basic functioning of the NCS 1002. This is also called the mini.iso. This base package contains:

  • Operating system (OS)—Kernel, file system, memory management, and other OS utilities

  • Base components—Interface manager, system database, checkpoint services, configuration management utilities

  • Infrastructure components—rack management, fabric management

  • Routing protocols—mandatory routing protocols (such as BGP, ISIS)

  • Forwarding components—FIB, ARP, QoS, ACL

  • Line card drivers

Mandatory RPMs (such as, BGP) which are a part of the base software, cannot be removed and can only be upgraded. Optional RPMs such as, EIGRP can be added, upgraded and removed as required.

Figure 1. Granular routing modules



The RPMs that are currently available in the granular module format are - mpls-te-rsvp, bgp (upgrade only), .

This chapter also discusses:

Workflow for Flexible Packaging

This image shows the overall workflow for Flexible Packaging.

Figure 2. Flexible Packaging Workflow



Packaging Filename Format

The format of an RPM is: name-version-release.architecture.rpm where,

  • name - of the platform the software supports

  • version - the version of the software

  • release - the number of times this version of the software has been delivered

  • architecture - the node's processor architecture

Consider this example: -mpls-1.2.0.0-r622.x86_64.rpm

Software Maintenance Upgrades (SMUs) are delivered as RPMs. RPMs have a four-digit version number. The first three digits represent major, minor, and build numbers respectively. The fourth digit is incremented with each SMU release.

This table lists the reasons when each digit of the version gets incremented.

Version (Digit from left)

Indicates

Incremented When

First

Major

non-backward compatible API(s) change(s)

Second

Minor

a backward compatible change occurs to a public API

Third

Build

an RPM is built without any API change

Fourth

SMU Release

a new SMU is released

Defect ID

SMUs are identified with a defect-ID. In this example, note that, for the first SMU release of the package, the fourth digit starts at 1 and for the second SMU release of the package, the fourth digit is incremented to 2.