Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

ASR9000/XR: The concept of a SMU and managing them

 

Introduction

A SMU is a software maintenance update, or simply put a patch, that can be loaded on the XR device you are running. The concept of a SMU applies to all XR devices, although this article focuses on the ASR9000 primarily.

When the system is running into a SW deficiency (a.k.a. a bug) Cisco can provide a patch for that particular problem in order for you to keep running your base release, but get free of the problem at hand. This is a substantial difference over the classic IOS that has no capability to apply a single fix in a single component on top of the base release run.

 

 

How do SMU’s work?

A SMU is a patch that is provided on a per release and per component basis and is specific to the platform. This means that when you are provided a SMU that it can’t be transported onto different hardware (eg a SMU delivered for CRS can’t be applied to ASR9K) and is also particular to the release that you are running. For instance a SMU provided on XR release 4.2.1 can’t be applied to a system running XR 4.2.3.

SMU’s are “PIE” files (package installation envelope) similar as the functionality of feature PIE’s such as MGBL, MPLS  and multicast and they are installed in a similar fashion.

The 3 operation steps to apply a smu are:

  • Addition of the smu to the filesystem
  • Activation of the smu onto the system
  • Committing the smu change so it is persistent across reloads

 

Example smu installation and application

In this example we’re going to install a dummy bogus OSPF smu that is a process restart.

 

Step 1: Addition of the smu to the file system

  • •a)    Either I can have the smu on a tftp file server and pull the smu in via that method
  • •b)    The SMU can be available on the harddisk or somewhere locally on the system from where I can add it to the file system repository

RP/0/RSP0/CPU0:A9K-TOP#admin install add tftp://3.0.0.1/xthuijs/asr9k-p-4.0.3.CSCea12345.pie

Wed Dec 19 12:05:38.639 EDT

Install operation 82 '(admin) install add /tftp://3.0.0.1/xthuijs/asr9k-p-4.0.3.CSCea12345.pie' started by user 'root'

RP/0/RSP0/CPU0:Dec 19 12:05:38.820 : instdir[206]: %INSTALL-INSTMGR-6-INSTALL_OPERATION_STARTED : Install operation 82 '

(admin) install add /tftp://3.0.0.1/xthuijs/asr9k-p-4.0.3.CSCea12345.pie' svia CLI at 12:05:38 EDT Wed Dec 19 2012.

tarted by user 'root'

The install operation will continue asynchronously.

 

Couple of notes to that:

  • •a)    Make sure that the file is available on the ftp server and has proper read permissions for the tftp operation.
  • •b)    You can use FTP also.
  • •c)    Make sure you are either in admin mode, or prefix the command with the admin keyword.

Now that the SMU is loaded on the system, after you see this message:

 

RP/0/RSP0/CPU0:A9K-TOP#Info:     The following package is now available to be activated:

Info:

Info:         disk0:asr9k-p-4.0.3.CSCea12345-1.0.0

Info:

Info:     The package can be activated across the entire router.

Info:

RP/0/RSP0/CPU0:Dec 19 12:05:54.469 : instdir[206]: %INSTALL-INSTMGR-6-INSTALL_OPERATION_COMPLETED_SUCCESSFULLY : Install  operation 82 completed successfully

Install operation 82 completed successfully at 12:05:54 EDT Wed Dec 19 2012.

 

You can verify the ability to activate this smu via the command “admin show install inactive

 

RP/0/RSP0/CPU0:A9K-TOP#admin show install inactive

Wed Dec 19 12:08:58.125 EDT

Secure Domain Router: Owner

 

  Node 0/RSP0/CPU0 [RP] [SDR: Owner]

    Boot Device: disk0:

    Inactive Packages:

      disk0:asr9k-p-4.0.3.CSCtr31747-1.0.0

      disk0:asr9k-mini-p-4.0.1

      disk0:asr9k-k9sec-p-4.0.3

      disk0:asr9k-mpls-p-4.0.1

      disk0:asr9k-p-4.0.3.CSCea12345-1.0.0

 

Note that the directory lists now disk0. For as9k that is always where the package are stored that are to be activated and running.

Effectively the “install add” operation moves the file from the source directory onto disk0, but it is not yet running in the load path. That is what the next step will take care of.

 

Step 2: Activating the package.

 

If you don’t know the precise package, you can always use this command:

 

RP/0/RSP0/CPU0:A9K-TOP#admin install activate ?

  disk0:asr9k-cpp-4.0.1                       Package to activate

  disk0:asr9k-cpp-4.0.3.CSCtr31747-1.0.0      Package to activate

  disk0:asr9k-k9sec-p-4.0.3                   Package to activate

  disk0:asr9k-mini-p-4.0.1                    Package to activate

  disk0:asr9k-mpls-p-4.0.1                    Package to activate

  disk0:asr9k-p-4.0.3.CSCea12345-1.0.0        Package to activate

  disk0:asr9k-p-4.0.3.CSCtr31747-1.0.0        Package to activate

  disk0:iosxr-diags-4.0.1                     Package to activate

  disk0:iosxr-fwding-4.0.3.CSCtr31747-1.0.0   Package to activate

  disk0:iosxr-routing-4.0.3.CSCea12345-1.0.0  Package to activate

 

One thing to highlight is the line in RED is the SMU that we just added. But now there is also the green line appearing.

Basically this means that the SMU we uploaded apparently is going to patch something in the “routing” component of the system, which is what OSPF falls under, since this is an OSPF demo smu.

 

RP/0/RSP0/CPU0:A9K-TOP#admin install activate disk0:asr9k-p-4.0.3.CSCea12345-1.0.0

Wed Dec 19 12:14:03.083 EDT

Install operation 83 '(admin) install activate disk0:asr9k-p-4.0.3.CSCea12345-1.0.0' started by user 'root' via CLI at

RP/0/RSP0/CPU0:Dec 19 12:14:03.288 : instdir[206]: %INSTALL-INSTMGR-6-INSTALL_OPERATION_STARTED : Install operation 83 '

(admin) install activate disk0:asr9k-p-4.0.3.CSCea12345-1.0.0' started by u12:14:03 EDT Wed Dec 19 2012.

ser 'root'

Info:     Install Method: Parallel Process Restart

The install operation will continue asynchronously.

RP/0/RSP0/CPU0:A9K-TOP#

 

After that completes, similar messages as the below appear:

 

LC/0/0/CPU0:Dec 19 12:14:38.365 : sysmgr[87]: %OS-SYSMGR-7-INSTALL_NOTIFICATION : notification of

software installation received

LC/0/3/CPU0:Dec 19 12:14:38.370 : sysmgr[87]: %OS-SYSMGR-7-INSTALL_NOTIFICATION : notification of software installation

received

LC/0/0/CPU0:Dec 19 12:14:38.381 : sysmgr[87]: %OS-SYSMGR-7-INSTALL_FINISHED : software installation is finished

LC/0/3/CPU0:Dec 19 12:14:38.385 : sysmgr[87]: %OS-SYSMGR-7-INSTALL_FINISHED : software installation is finished

LC/0/6/CPU0:Dec 19 12:14:38.529 : sysmgr[90]: %OS-SYSMGR-7-INSTALL_NOTIFICATION : notification of software installation

received

LC/0/6/CPU0:Dec 19 12:14:38.546 : sysmgr[90]: %OS-SYSMGR-7-INSTALL_FINISHED : software installation is finished

RP/0/RSP0/CPU0:Dec 19 12:14:53.145 : sysmgr[95]: %OS-SYSMGR-7-INSTALL_NOTIFICATION : notification of software installati

on received

RP/0/RSP0/CPU0:Dec 19 12:14:53.184 : sysmgr[95]: %OS-SYSMGR-7-INSTALL_FINISHED : software installation is finished

Info:     The changes made to software configurations will not be persistent across system reloads. Use the command

Info:     '(admin) install commit' to make changes persistent.

Info:     Please verify that the system is consistent following the software change using the following commands:

Info:         show system verify

Info:         install verify packages

RP/0/RSP0/CPU0:Dec 19 12:15:04.165 : instdir[206]: %INSTALL-INSTMGR-4-ACTIVE_SOFTWARE_COMMITTED_INFO : The currently act

ive software is not committed. If the system reboots then the committed software will be used. Use 'install commit' to c

ommit the active software.

RP/0/RSP0/CPU0:Dec 19 12:15:04.166 : instdir[206]: %INSTALL-INSTMGR-6-INSTALL_OPERATION_COMPLETED_SUCCESSFULLY : Install

operation 83 completed successfully

Install operation 83 completed successfully at 12:15:04 EDT Wed Dec 19 2012.

 

Take note of the green and red lines highlighted. The RED line we’ll discuss in step 3.

Now the SMU is active. And this change happened inline, the system continued to function as normal and eventhough OSPF was kicked, the neighbors were not lost:

 

RP/0/RSP0/CPU0:A9K-TOP#show ospf ne

Wed Dec 19 12:16:29.892 EDT

 

* Indicates MADJ interface

 

Neighbors for OSPF CORE

 

Neighbor ID     Pri   State           Dead Time   Address         Interface

2.2.2.2         1     FULL/DR         00:00:36    200.200.1.2     Bundle-Ether200

    Neighbor is up for 7w1d

 

We should be able to see the effects of this demo smu now:

 

RP/0/RSP0/CPU0:A9K-TOP#show ospf

Wed Dec 19 12:17:09.059 EDT

 

 

DEMO SMU: If you see this line the SMU was installed correctly

 

Routing Process "ospf 111" with ID 12.12.1.2

NSR (Non-stop routing) is Disabled

Supports only single TOS(TOS0) routes

Supports opaque LSA

Router is not originating router-LSAs with maximum metric

 

 

Looking at the green line I say our exercise succeeded.

 

Step 3: Committing the changes

If the chassis were to reload right now, the SMU will be lost from the running software. Which means that the green line or our fix will disappear. To make the change or application of this SMU persistent across reloads, you need to commit the smu via this command:

 

 

admin install commit

 

 

 

When are SMU’s created?

In theory, every software issue can be converted into a SMU. However we apply a set of “rules” to what can be put in a SMU.

For starters, features or CLI changes are not eligible for a SMU. To leverage a new functionality, it is advised to upgrade to a new release.

Cosmetic issues we generally don’t smu either.

Only mission critical issues are to be SMU’d that will not allow you as a user to operate the device under “normal” circumstances.

On occasion when we uncover a critical issue we might create a SMU on a (set of) release(s), such as when a PSIRT is in order.

If you have an issue that appears to be a software bug and you have a TAC case open and there is a known DDTS associated with the issue, then it is eligible for a SMU. Work with your TAC engineer to see if this particular issue can be put into a SMU and what the timelines are for delivery.

Sometimes it may make sense to consider a sw maintenance upgrade rather than filing an individual SMU request. Your TAC or Advanced Services representative will be able to advice you on the best course of action.

Note that SMU delivery and commitment comes from Cisco engineering. Make sure that your support representative communicates the commitment as set by the Cisco engineering group.

 

SMU categories

SMU’s are categorized as follows:

 

  • Recommended or Mandatory
    • Critical fixes that are highly/strongly recommended in order to maintain proper functionality of the device
    • These are located on CCO
  • Optional
    • Fixes that are “good to have” but are not required in order to maintain stability.
    • These are located on File Exchange

 

Furthermore these SMU’s have a particular “restart type”.

  • Process restart/Hitless
  • Reload

 

We try to make SMU’s of a process restart kind similar in the example you have seen above which effectively means that the component this SMU touches is restarted in an inline fashion not affecting the operation of the device.

However sometimes SMU’s touch such key base components deep in the OS requiring a reload of the device. Examples of that are changes in the MBI (boot image), kernel or Network Processor ucode.

 

Sometimes it can be the case that a particular SMU would require too many processes to restart and while this theoretically should be possible, for safety reasons if the fan out of process restarts exceeds 10, we make the SMU a reload to maintain system stability.

 

Where do I find SMU’s

There are 2 key repositories where SMU’s are located. That is either on CCO found in the section of

 

CCO location

 

untitled.JPG

 

 

File Exchange*

https://upload.cisco.com/cgi-bin/swc/fileexg/main.cgi?CONTYPES=IOS-XR

 

Note that SMU’s on file exchang require special permission and you may need to access for access to download a specific SMU from that location.

 

*File exchange may disappear in the near future to be “superseded” by a new software delivery platform. We’ll update documentation here as that gets more shape and form.

 

Concept of an engineering SMU

Sometimes a TAC engineer in association with a development engineer may provide you what is called an engineering SMU for a fix verification to be run temporarily.

An ENG-SMU is really like any other regular SMU however it is build from a private workspace. This means that if you have other SMU’s running in the same component, these changes may be negated. Subsequently future SMU’s in the same component may not inherit the changes that you have in this particular eng smu and will be negated when a new smu in this component is run.

For that reason Cisco can NOT allow you to run eng-smu’s in a production environment for a prolonged period of time.

Also the availability of the eng smu should not give you the commitment that a production smu is in order. These eng smu’s are only and solely for the fix verification to make sure that the intended changes do fix the problem.

We try to minimize the need for such events as much as possible, however if Cisco TAC or Development is not able to reproduce a problem, this may be a potential solution to verify the fix in a real scenario and make sure there is no collateral.

 

SMU delivery timelines

Once Cisco TAC has provided you the official confirmation that a SMU will be provided it can take some time before the final SMU will be posted or when you get it in your hand.

A SMU will undergo various stages before it is released and they are the following:

 

  • •1.    SMU requested (eg by TAC engineer)
  • •2.    SMU accepted (after review by various managers to make sure the request makes sense, timelines are being set for delivery)
  • •3.    SMU assigned to a development engineer (generally the DE who fixed the original DDTS/defect)
  • •4.    SMU undergoes Unit Testing by development engineer
  • •5.    SMU undergoes Dev Testing by the component testing group (testing at the component level, eg BGP or OSPF)
  • •6.    System Integration testing by the platform team (eg ASR9K or CRS)
  • •7.    SMU released to CCO or File Exchange

 

Only until after step 2 you can have the confirmation that a SMU will be provided.

The timelines from 1 to 7 can range between 6 to 8 weeks.

The majority delay we experience in step 6. This is integration level testing whereby the SMU is not only subject to the particular issue it fixes, but also it is tested in a multi dimensional test scenario to make sure there is no collateral into other components.

 

 

SMU Supersedes and Prerequisites

One important concept to understand about SMU’s is that they are committed to a software lineup particular to that release.

This means that if we have a SMU “x” that fixes lets say LSA flooding in OSPF. SMU “x” will basically contain the new ospf process and libraries for instance. Now when we have a SMU “y”, that fixes a crash in OSPF due to the reception of a malformed hello and if “y” was delivered AFTER “x”, basically “y” contains the fixes for both issue “x” and issue “y”

 

Coming back to the eng-smu discussion earlier. If you were to be given an eng-smu for “y”, the changes from “x” wouldn’t be there. Subsequently, if there would be a SMU “z”, also in OSPF, then “z” may not contain the changes of “y” if these changes were not committed to the SMU lineup. So Loading “z” would negate the changes applied by “y”.

 

Supersede

This story also immediately shows the concept of a SMU “supersede”.

What a supersede means is that if there are 2 SMU’s in the same overlapping component, there is no need to run them both at the same time. In this example above. SMU “y”, while committed to the lineup, takes inherently the changes from “x” already. So by running “y” you don’t need the smu for “x” anymore.

If you are already running it, you can remove it to save some space. If you want the changes from both X and Y, just running “Y” is good enough.

 

Partial supersede

In some cases a SMU includes 2 components at the same time. For instance in the example whereby SMU “x” contains a change in OSPF and let’s say some library.

If SMU “y” is another OSPF change as in the example above, but has no lib changes, we say that SMU “y”  is a partial supersede over x. That is, there are some overlapping components but NOT ALL of them.

 

It supersedes the changes of X, but Y itself doesn’t include the lib changes hence in this case they will need to be run together.

The way the SMU is built by Cisco SW tools will include that dependency, so while you are installing “y”, it will mention to you that “x” is needed as well.

 

Prerequisite

In this example above we can also state that “y” has a prerequisite of smu “x”. That means in order to run “y” we need “x” as well.

 

How I can keep track of that all

Generally our SW delivery team removes SMU’s from CCO and file exchange that are fully superseded, so you won’t be as confused. But that inherently means that if you were looking for “x”, how do you know that now you need to install “y” to get whatever you need?

Well we recognize that difficulty and right now there is no other way then asking your AS to TAC rep what you need to do if you want the changes for “x” and you don’t find “x” anywhere. But read on as we have some software tools for you to use to simplify all this in terms of SMU management.

 

Combo SMU’s and SMU packs

A combo SMU or pack is a collection of individual DDTS’s included in what we call an “umbrella” DDTS.

This DDTS is a new number which is basically an aggregation of a set of DDTS’s under that umbrella number.

This simplifies the SW delivery model because now you don’t have to install individual SMU’s to get fixes for individual issues, but rather instead there is a single file to download and install to patch evyerhting up.

 

The terminology of combo, umbrella and pack are used interchangeably but in the end they all refer to the same thing.

 

The ASR9000 team is making use of SMU packs heavily for what we call platform specific fixes.

 

  • A platform specific (PD) fix is an issue pertaining to the platform solely, like ASR9000 Network Processor ucode.
  • A platform independent (PI) fix is something that spreads across all XR platforms, for instance a BGP memory leak

Starting XR 4.2 the ASR9000 team has provided SMU packs for platform specific fixes that we consider to be mission critical. The packs or what Microsoft would call service packs are collection of fixes that you will want to pick up in order to maintain stability on the base release you are running.

 

SMU Pack Q&A

 

•    How are critical bugs which fall between C-SMUs handled?

-    We make an assessment based on the impact, severity and workaround if present, if needed we deliver an individual SMU between SMUs packs

 

•    Does the C-SMU supersede all other previous PD SMUs?

-    The C-SMU will supersede the previous C-SMU as well as any other SMUs that are released and are a reload type, or have sort of dependency to be included in the C-SMU

 

•    Will this policy cover all SMUs?

-    This policy if for Platform Dependent (PD) fixes at this point. That is PRM and ucode fixes

 

•    Will there still be individual SMUs released?

-    Yes we will still release individual none reload PI or PD SMUs, the C-SMU process is for PD reload SMUs

 

•    What is the benefit of the SMU Packs and why are we doing that?

-    To provide maintenance updates specific to asr9k

-    With timed delivery

-    To simplify it for the customer and reduce the complexity of maintaining SMU supersedes and pre-requisites

 

•    I have a DDTS that I want for my customer, can get this get in the SMU pack?

-    It depends. General SMU guidelines apply. If the fix is critical enough it can get included

 

•    What happens if I have a last minute DDTS/SMU requirement?

-    Once we enter Dev Test phase we will NOT make an exception to integrate it and you will need to wait until the next smu pack.

 

•    My customer is not happy with the SMU Pack as he claims he now has to test for more fixes because the pack includes more fixes

-    That is a misperception. Every PRM/UCODE smu will pick up changes from a preceeding one, so “clean” smu’s with only the one fix don’t really

exist. In fact this pack methodology makes it easier to understand what the customer is going to get. Comprehensive test coverage is always needed

 

•    Why are the packs reload?

-    Because they contain driver, prm and ucode changes which inherently require a reload. Later on moving forward we will get more ISSU like behavior for ucode changes.

 

•    Do SMU packs affect general timelines?

-    Not really. Before you had to wait already anyway 6-8 weeks for a SMU delivery. Now it is the same way effectively.

 

•    How many DDTS’s are integrated in a PACK?

-    There is no defined number of fixes in there, but we try to keep it limited.

 

•    Are SMU packs the new maintenance releases?

-    If you want to call it like that, sure. SMU packs is our way to provide added stability of critical fixes to the release in question without having the need to upgrade to new minor releases. This policy remains in effect for as long as needed.

 

•    How many packs per release?

-    Depends on the need, expect 2 to 3 packs.

 

 

SMU management

 

We understand that as part of the above story it is pretty hard to keep up with what is recommended, what smu’s are available, which ones you need to run, installing them and keeping track of all those dependencies.

Fortunately we have some good news.

As part of the ASR9000 Craft Tool (ACT), we have a SMU manager capability that is getting more and more enhanced as we move forward, but will help in managing these SMU’s for you on your devices.

 

ACT is free for download from CCO. You need version 1.5 to have the SMU mgmt capability.

 

ACT is a java applet based tool that helps you managing the ASR9000 from an operational standpoint, and now also the software of it.

 

ACT Smu manager

ACT requires the MGBL pie active on the device under mgmt so that the XML capability is running.

It requires a telnet or SSH connection from the device where ACT is running to the ASR9000.

 

After you have installed ACT and you are ready to launch, the application a window similar as the below will appear.

Click on

  • Packages tab from the top tab selector
  • The “SMU MANAGER” capability with the button on the bottom right.

 

Slide2.JPG

 

 

The next thing you need to do is to specify the location of where the SMU’s will be located on your local repository.

This needs to be a tftp server that is accessible by the station that you run the ACT app on as well as the ASR9000’s that you want to manage the package of.

 

At the same time, you will need to provide the META FILE location.

This meta file will be made available for download on a per release basis that knows everything about all SMU’s for that release and their dependencies.

This META file is the brain of the ACT smu management, so it is important that this file is current.

 

Today, the ACT can’t download SMU’s or META files automatically from CCO, but that is something we are working on, so right now you will need to pull in these files manually. For sure the META file.

Based on the SMU’s you want to run, you may need to pull them in, but ACT will guide you through it.

Slide3.JPG

 

 

 

Picture showing the directory path dialog as to where the SMU’s can be found on your local repository.

Right now, we only support TFTP, but there are plans also to support SFTP and FTP.

Slide4.JPG

 

 

You may not have the need to run all SMU’s that the META file knows about because certain features are not being used for instance. Also depending on the functionality of the device and where it sits in your network, a SMU may not be applicable to that device. For instance you have an L2VPN design and you run STP. You may want to run an STP related SMU on your edge/customer facing devices, but not necessarily on your core devices.

 

The Custom Meta file option provides you an ability to pre-select certain SMU’s and save these custom sets to a file.

 

Select the

  • Custom Meta file option from the botton right
  • Select the SMU’s you want in that subset file
  • Click SAVE
  • Provide a filename and save your custom meta file.

Slide5.JPG

 

 

 

You can then run a compliance report against a device under management to see if the system is running the set of SMU’s that you want it to run based on the specified custom meta file.

Slide6.JPG

 

 

When you are about to select SMU’s for a custom meta file or to be applied to the device under management

there are a few things that are interesting from the SMU selection page.

 

The scroll down list either displays ALL smu’s available, or a subset if a custom META file was specified.

  • When the SMU row is listed in white, the SMU is available in the local repository (your TFTP server) and is ready for install
  • If it is RED the SMU is known to the meta file, but the file is not found on your TFTP server.
  • If it is YELLOW the smu is running on the machine, but it is not committed (see above for ramifications)
  • If it is BLUE, it is on the system, but not running

This page shown is very important as it also shows you the SMU impact, whether it is recommended or not

and what the implications are of installing it, whether it is a hitless SMU or a reload requirement.

Slide7.JPG

 

 

 

When you select a particular SMU to be installed onto the system, you can click the “install add” option, which basically pushes the file from your local repository (TFTP server) to the ASR9000 being managed.

If the tool detects that there is a dependency (eg pre-requisite requirement) the tool will identify that and alert you of that necessity and provide you the option to “fix” that dependency by applying the pre-req smu automatically if it is available on your local repository.

Slide8.JPG

 

 

When you double click a row in the smu selection page, the “internal” smu details are being presented to you.

The dependencies as well as some other details in terms of component it touches are being detailed out.

This is merely for information and you can ignore pretty much this page, but it is nice to know in case you like to track the SMU internals.

You can see that everything with a DDTS number is hyperlinked. Which allows you to open the bug toolkit which will report the DDTS details, headline, release notes and workarounds applicable.

Also it shows you the integrated in versions.

Slide9.JPG

 

 

 

The bug tool kit spawned when clicking on the hyperlink of the DDTS:

Slide10.JPG

 

 

 

 

 

 

 

N/A.

 

Xander Thuijs    CCIE #6775

Principal Engineer, ERBU

ASR9000

Comments
New Member

This is a nice recopilation of all information we need to keep the platforms healthy.

BTW, I have one particular SMU that states:

"Restart Type: dependent"

Do you know what does it mean?

saludos!

SMU Name: asr9k-p-4.0.1.CSCua63591.pie

Cisco Employee

Thanks Pablo!

Ah great question, I noticed I forgot to include that in the write up. Here is the summary:

Restart Type - Install Restart type of this SMU, one of:

  1. reboot: The system should be rebooted. When       there is any modification required in the kernel, the system has to be       reloaded. Eg. 'restart-type' =>'reboot'.
  2. dependent: The processes included in this        component need to be restarted as well as all other processes which are        using DLLs exported by this component (importing APIs of this). To be        used if a component exports CLI, restartable processes and DLLs. To        determine the list of dependent processes, install manager will look at       all  the packages in the active loadpath and find out if any of them are        importing DLL(s) exported by the package to be installed. It basically means that one or more processes might get restarted (depending on who is using the DLL that changed for instance). IOS-XR allows a process restart SMU up to the restart of 50 processes. If there are more then that during installation, although the smu type is non reload, it may require a reboot. This to maintain system stability. XR43 has enhacnements that allow more process restarts and also reduce the number of reload smu's when NP ucode for instance is used.
  3. process: The processes included in this        component needs to be restarted. Should be used only if all the files        exported are CLI or processes that are restartable.
  4. none: Nothing needs to be restarted after       upgrading this component

regards

xander

New Member

Thanks a lot for your comment it was useful.

Based of what you described above, do we need to reload the box anyway if the Restart Type is "dependent" in order to maintain system stability?

What is your recomendation in case we need to install 10 diferents SMU's for instance where 5 of them requieres reboot and some others don't require reboot. Can I install and active all of them in just one operation having just 1 reboot?.

Thank you.

Pablo.

New Member

Hallo,

Where can we retrieve this Meta file it is referring too?

Regards

Noel

New Member

Hi Xander,

                  I would like to share my doubt with you. In XR, is there any command available for selecting the algorithm(for saving and encrypting keys) whenever the user execute commit commands.

Cisco Employee

Rakesh, you mean for passwords of users or radius keys?

If that is the case you can enter them in plain text and they will get a "7" type of (reversable) encryption.

User passwords can be entered as clear and saved as "secret" which will be irreversable.

ps. this question has not much relation to SMU's as to what this article is about. You may get more response and input if you open new questions via the "XR OS and platforms" forum.

cheers!

xander

New Member

Hi Xander,

Very nice reading!!! It helps a lot in the SMU management “nightmare”. Particularly with 4.2.3 and >60 PX and >40 P SMUs released so far…

Still I have some questions:

1. If a SMU is superseded by a new one, the only reason to remove it is to save space? If I don't care about the disk space it is safe to keep it?

2. Why do I have to install SMUs related to features/functionalities I don’t use? For example, to install asr9k-px-4.2.3.CSCud49605 I have to install a SMU related to NV-EDGE (asr9k-px-4.2.3.CSCue14377)...

Thanks.

Cheers,

Pedro

Cisco Employee

Hi Pedro, glad to read it helped!

1) yeah saving space is one reason, you could keep it around, it doesnt do any harm, except for that admin show install active looks a little cluttered with smu's you're effectively not running anymore. Another reason to leave them, temporarily, is to have a rollbackpoint.

2) generally you dont need to run smu's for features you're not using, however sometimes a smu may supersede one that you want to be running. in this case the smu in question (partially) supersedes CSCud37351 which is pack2.

Or a smu that you want to be installing builds forward on a previous smu like the one in question and if it is only a partial supersede the original smu (in question) becomes pre-req. Eventhough functions from the pre-req smu may never be called/used if you are not running the feature.

regards

xander

New Member

Hi Xander,

Thanks for your reply.

Another question, what if I have a SMU that is superseded by one SMU but a pre-requisite for another one? How should I proceed?

Thanks.

Cheers,

Pedro

Cisco Employee

Hi Pedro, that is called a partial supersede and that means that you need them both then.

xander

New Member

Hi Xander,

In "ASR9000 IOS XR 4.2.3 General Release Recommendation" there are a lot of "Recommeded" SMUs for P an PX. As far as I know "recommended SMUs" are the ones Cisco wants every costumers to install, is that right?

Another question, do I have to install a Recommended SMU even if I don’t use the HW or the SW feature? Examples:

asr9k-p-4.2.3.CSCuc20553.tar - CPP_CP_SVR restart on SIP-700, Recommended SMU.

asr9k-p-4.2.3.CSCug38659.tar - DHCP Umbrella DDTS for 4.2.3, Recommended SMU.

I don’t have SIP-700 and don’t use DHCP, should I install these SMUs?

Thanks!

Cheers,

Pedro

Cisco Employee

Hi Pedro,

yeah the term recommended is a bit tricky. we used to call it mandatory but that was also not received well.

so when it says recommended smu, you kind of really want to pick it up if you're running that technology.

If you dont run that technology, you could technically live without it, but always evaluate the headline of the DDTS and its release notes for the details. Although we're putting a lot of effort into making the headline as precise as possible, I dont want you to miss a smu because it says eg Cows and Pigs, while it means all animals.

Also if the DDTS/SMU is really applicable to that technology or area only, you still may need it (at some point) when another SMU you do need is building forward on top of it (aka Partial Supersede).

Cisco Software Manager (CSM) can help you identify that pre-req requirement very easily.

IF you click your desired smu and select install or download, it will tell you which other pre-requisites you potentially need.

regards

xander

New Member

Hi Xander,

ASR XR4.2.3 recommended SMU bundle consists of about 90 SMUs, we are installing a new ASR9K with XR4.2.3 and would like to apply all recommended SMUs (after scrubbing if about 50 applies to our environment).

Is there any SMU limit when we use "install add command"? or can i apply all at once using wildcards as some SMUs are dependedent on others.

Any concern for disk space etc?

Thanks,

Zakir

Cisco Employee

hi Zakir,

yeah there is a limit as to the number of chars a cli line in XR can take, so you may need to do it via the install add source <loc> smu1 smu2 etc.

disk space for RSP440 is not an issue, for rsp2 you will want to run the repart func to reclaim the 300M reserved space.

also leverage the CSM (software manager to install and manage smu;s).

you need to install add them manually, the activate can use wildcards.

cheers

xander

New Member

Hi Xander,

I've finished my analysis and have about 25 SMUs to install. Due to the limitation of characters in the CLI, I'm planning to add a TAR with all the PIEs, and after that use the install ID from the add operation to do the activation. Is that supported? Any drawback?

Thanks!

Cheers,

Pedro

Cisco Employee

Hi PEdro,

that would do the trick. the only drawback of doing the tar approach is that you have to make a smu bundle yourself before uploading, but that shouldn't be that much an of an issue either.

cheers

xander

New Member

Hi Xander,

Quick question, the install impact of a SMU is the same for the active and deactive action, correct? For example, a reload SMU, will reload the box either for the activation and for the deactivation, right?

Thanks for all your help.

Cheers,

Pedro

Cisco Employee

hey pedro, that is correct! a reload smu will cause reload on deact also...

but generally there is no need to uninstall the reboot smu and incur that reload.

at some point it may get superseded and then you can remove it to save the space of the smu.

xander

New Member

Hi Xander,

That is the case that I'm considering (when SMUs are superseded). However, I still have to deactivate them. They won't become inactive automatically, right?

Thanks!

Cheers,

Pedro

Cisco Employee

hi pedro, after they are superseded their code is no longer used so it is just there for rollback purposes in case you rollback the superseded smu and consuming some disk space that is it.

you oculd leave them just for that rollback purpose as it is not causing any harm.

I believe, but not sure in 43 with the install enhancements, if ti is FULLY superseded then the install cleanup commands cna remove it without a reload.

regards

xander

New Member

Hi Xander,

My problem is that I have 4.2.3 + 30 SMUs installed, and just have around 300 Mb free in disk0:. I need to save some space before moving to the repartition.

Thanks.

Cheers,

Pedro

Cisco Employee

If you have an RSP2 and have not yet ran the "repart -d" to reclaim the 300M then you can do that at any time, there is no need to free up space before running that command.

There may be some other items that can be removed first, because it is a waste to reload to remove unneeded smu's.

If you have about 700M free it should be good enough to move to the next release.

xander

New Member

Hi, Xander:

 

Is there a scenario (any non-reload SMU) where you don't have to separate NV cluster racks to apply an SMU? I mean, just do your regular "install add/activate" in active rack.

 

Thanks,

c.

Cisco Employee

was a little surprised to see the cluster separation for a process restart smu, so I had to check with our cluster expert (Sam M.) and he confirmed also that for a proc restart smu it is just apply and go ahead.

even for a reload smu it is the same.

other then that if you like to reduce the downtime, the cluster separation for a reload smu or sw upgrade is advised to minimize the downtime.

 

cheers

xander

Sam: thanks for the confirmation!!

New Member

Thanks very much, Xander+Sam. That is very good news, because of the CSS/Abraxas field notice.

New Member

Hello Xander,

I'm going to apply number of SMUs to 5.1.3.

There is a reload SMU asr9k-px-5.1.3.CSCuq02868 which is listed as pre-requisite for another reload SMU asr9k-px-5.1.3.CSCuv94061.

Should I reboot after asr9k-px-5.1.3.CSCuq02868 before activating asr9k-px-5.1.3.CSCuv94061 or I can activate both simultaneously and suffer only single reload?

Question relates not just to this SMUs, but all similar cases with one reload SMU having another reload SMu as a pre-requisite.

Regards,

George

Cisco Employee

hi george,

you can apply them in one go. I would recommend using CSM to package your desired smu's together, which also figures out the pre-req pack and bundles it for you and can apply it to the device also, makes it a lot easier to manage.

cheers!

xander

New Member

Hello Xander, 

I have installed ACT craft tool for 9904 and looks like it is working good without the shelf view. I am ok with that. But I need to know how to get the SMU meta file for SMU manager. 

I have downloaded some SMUs but not sure how to get the SMU meta file. Any help will be great.

Cisco Employee

hi foysol, we have obsoleted ACT, as there is no new development on that going on.

the functionality of it will be as is, so you can still play around with it. for managing smu's you'd want to download cisco software manager CSM.

that app will pull the meta file by itself and is also to pull the smu's directly to you(r server).

cheers!

xander

New Member

Thanks for your reply. Looks like last couple of days to get the ACT working did not add much value :)

Regarding CSM, I have some questions. 

1. I downloaded CSM 3.2. Would you please confirm that this will support 9904?

2. The link describes the windows installation process but I could not able to located .cmd file when I unzip csm 3.2.

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/smu/csmuser.html

3. What tcp/udp ports we need to open if there is a firewall in the path. 

Cisco Employee

Hi Xander,

Have a query based on the recent observaion with respect to the SMU's and Upgrade

Step (1) Test Lab Router was running 5.2.4 packages + SMU's( 17SMU's) from which upgrade is carried out to 5.3.4 Packages + SMU's using a tar file. No issue was observed during the upgrade. Note is that there were many 5.3.4 inactive packages before upgraded from 5.2.4 to 5.3.4 as previous many times the upgrade has been performed. Inactive packages of 5.3.4 were not removed

Step (2) Same test Lab router running 5.2.4 Packages + SMU's (16 SMU's) from which upgrade is carried out to 5.3.4 packages = SMU's using the same tar file. The install activation failed with the message saying a "X" SMU is required for "Y" SMU to be installed. Note is that all the inactive packages were cleared before the install add/activation unlike.

We were trying to analyse why during test Step(1) the install activation was not failing. The two differences between Step (1) and Step (2) are

a. Step (2) had One less SMU in 5.2.4 compared to Step (1) before the upgrade.

b. During Step (2) when router was running with 5.2.4 there wer eno inactive packages of 5.3.4.

Could you please help in understanding which of these two would have triggered the failure.

Cisco Employee

yikes, this is very vague right :)

it could be that the missing smu in the 16 vs 17 is that "y" being asked for...

it would help to know what the install list is and what x and y were so I can make a better recommendation as to what has heppened here.

so question "back" is, what is the smu delta between item 1 and 2.

cheers!

xander

Cisco Employee

Hi Xander,

Figured out the reason.

During Step (1), we had installed an Eng SMU for a fix in 5.3.4 during earlier upgrades and the SMU was in the inactive list which we did not clear. We installed a tar ball for the latest upgrade of 5.2.4 to 5.3.4 during which we had taken the production SMU for the same fix. Unfortunately the Eng SMU and the Production SMU had the same name. The Eng SMU never enforced the Pre-requisite and because of the same name of the Prod SMU was not taking into effect to enforce the pre-requisite.

Once we cleared the inactive packages and tried install add/activating the tar ball, we could see the pre-requisite is enforced.

Thanks for your help

Cisco Employee

hi visb,

nice going, thanks for the closure on this. it is a bit interesting that the eng smu has the same version as the production smu. even if that is the case, the pre-req should have been satisfied.

one thing to note is indeed that if there is a smu on the disk, but inactive, an addition or overwrite of that same version smu will fail as it thinks it is present already. it depends a bit on the way the eng smu is built.

anyways water under the bridge now :)

cheers

xander

12534
Views
10
Helpful
34
Comments