- 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:
(OS)—Kernel, file system, memory management, and other OS utilities
manager, system database, checkpoint services, configuration management
components—rack management, fabric management
routing protocols (such as BGP, ISIS)
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
Figure 1. Granular routing
The RPMs that are
currently available in the granular module format are - mpls-te-rsvp, bgp
This chapter also
This image shows the overall workflow
for Flexible Packaging.
Figure 2. Flexible Packaging Workflow
The format of an RPM
name - of the platform
the software supports
version - the version of
release - the number of
times this version of the software has been delivered
- the node's processor architecture
Consider this example:
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.
(Digit from left)
compatible API(s) change(s)
compatible change occurs to a public API
an RPM is
built without any API change
a new SMU is
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.