cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
133101
Views
65
Helpful
156
Comments
xthuijs
Cisco Employee
Cisco Employee



Introduction

This document provides an understanding of what Turboboot is and how to bring up a system running IOS-XR from scratch

There are two ways to upgrade the system:

  • One is to install add and activate the new XR software version. At a minimum this would require that mini.pie file
  • The second way is by performing a turboboot, fresh install, by booting the mini.vm file from rommon

This executable mini.vm file needs to be transferred via TFTP (on the RSP2) or can be loaded from the external USB port or TFTP (on the RSP440 and CRS-PRP). On the 9001 the USB ability is added in rommon 2.03 (5.1.1 release version).

No other media or protocols are possible to be used for a turboboot other then the ones specified above. Ex FTP is not allowed

File System overview

XR devices have multiple medias for storage and they all have their individual purpose.

 
VolumeRSP2RSP440TridentTyphoon
disk0:Embedded USBSSD (SATA)  
disk0a:Embedded USBSSD (SATA)  
disk1:Embedded USBSSD (SATA)  
disk1a:Embedded USBSSD (SATA)  
harddisk:Harddisk (SAS)Embedded USB  
harddiska:Harddisk (SAS)Embedded USB  
harddiskb:Harddisk (SAS)Embedded USB  
compactflash:Compactflash1External USB1  
lcdisk0:  Embedded USBEmbedded USB
lcdisk0a:  Embedded USBEmbedded USB
bootflash:NOR Flash NOR FlashNOR Flash
configflash:NOR Flash   
nvram:NVSRAMNVSRAM  
Kernel dumpHarddisk (SAS)SSD (SATA)TFTPbootflash:
 1. Removable   
     
Access (Mount) Points (in /dev)
VolumeRSP2RSP440TridentTyphoon
disk0:disk00t77hd0t77qsm to active rspqsm to active rsp
disk0a:disk00t78hd0t78qsm to active rspqsm to active rsp
disk1:disk10t77hd1t77qsm to active rspqsm to active rsp
disk1a:disk10t78hd1t78qsm to active rspqsm to active rsp
harddisk:hd0t79usb00t77qsm to active rspqsm to active rsp
harddiska:hd0t77usb00t78qsm to active rspqsm to active rsp
harddiskb:hd0t78usb00t11  
compactflash:disk20t6,11,121usb10t6,11,121  
lcdisk0:  lcdisk00t77lcdisk00t77
lcdisk0a:  lcdisk00t78lcdisk00t78
bootflash:fs0p1 fs0p1fs0p1
configflash:fs1p1   
nvram:nvramnvram  
Kernel dumphd0t80hd0t80 or hd1t802 fs0p2
 1. Any one2. Either one  
     
Usage
VolumeRSP2RSP440TridentTyphoon
disk0:IOS-XR Packages, ConfigsIOS-XR Packages, Configs  
disk0a:sysmgr_debugsysmgr_debug  
disk1:IOS-XR Packages (if Mirrored)IOS-XR Packages (if Mirrored)  
disk1a:wdsysmon_debugwdsysmon_debug  
harddisk:Crash files, logsCrash files, logs  
harddiska:NP logs, crash filesNP logs, crash files  
harddiskb:    
compactflash:File CopyFile Copy  
lcdisk0:  Kernel dump filesKernel dump files
lcdisk0a:    
bootflash:MBI Images   
configflash:OBFL   
nvram:ConfigsConfigs  
Kernel dumpRaw kernel dumpsRaw kernel dumps Raw kernel dumps
     
Filesystems
VolumeRSP2RSP440TridentTyphoon
disk0:QNX4QNX4  
disk0a:QNX4QNX4  
disk1:QNX4QNX4  
disk1a:QNX4QNX4  
harddisk:QNX4QNX4  
harddiska:QNX4QNX4  
harddiskb:QNX4FAT  
compactflash:FAT1FAT1,2  
lcdisk0:  QNX4QNX4
lcdisk0a:  QNX4QNX4
bootflash:FFSv3 FFSv3FFSv3
configflash:FFSv3   
nvram:CiscoCisco  
Kernel dumpRawRawFileRaw
 1. FAT F/S only2. Flash Media only  
     
Approximate Parition Size (minimum)
VolumeRSP2RSP440TridentTyphoon
disk0:1.6GB11.0GB  
disk0a:0.4GB2.2GB  
disk1:1.6GB11.0GB  
disk1a:0.4GB2.2GB  
harddisk:35GB3.1/6.2GB  
harddiska:8GB0.4/0.8GB  
harddiskb:8GB0.4/0.8GB  
compactflash:1GB1-32GB  
lcdisk0:  1.6GB1.6GB
lcdisk0a:  0.4GB0.4GB
bootflash:44MB 56MB56MB
configflash:28MB   
nvram:220K500K  
Kernel dump21GB500MB x 2 24MB
 

Note that unlike many IOS devices, nvram is NOT used for the configuration storage. Configurations are stored in a database on the boot disk (often disk0). Typically only rommon variables and license info are stored in nvram.

Summary steps for using turboboot

Because a  turboboot can erase configuration, SSH keys, and other items such as  licenses the following should be done to check and backup any files

1. Run a cfs check in admin & non-admin mode

2. Copy active licenses and SNMP files to tftp server

3. Copy running config to a tftp-server or laptop

4. Capture "show ipv4 int brief" output to a text file

5. Capture "show ipv6 int brief | i Up/Up" output to a text file

6.  Offline. Edit the saved RSP config - add "no shutdown" for all physical  interfaces that are up/up from the above IPv4 & IPv6 interface  captures and save cfg changes. Note that it is not necessary to “no  shut” sub-interfaces, only the main physical interface.

7. Connect a laptop console cable to the RSP in RSP0 slot and enable a log file to monitor and capture the RSP bootup logs.

8 . Turn the power supplies on to power up the asr9k system. (approx. 7-12 minutes)

9.  After the LED's indicate IOS-XR on the LC's, and ACTV or STBY on the  RSP’s, log in via the console of the RSP that is ACTV and run some  preliminary checks to check system stability.

NOTE: The default root-system username and password on the RSP440 are root/root

(if root/root does not work also try cisco/cisco, or admin/admin or viking/viking)

 

10. Verify the ASR9K IOS XR version

11. Run a cfs check in admin & non-admin mode

12. (Optional) Install add & commit any missing SW packages (pies) or required SMU’s

13. Upgrade FPD in admin mode

14. Reload any nodes that had FPD upgrades

15.  Configure the Mgmt ethernet interface with an IP address to reach tftp  server & load and commit the saved RSP config from tftp server or  laptop

a) or log into the console and cut & paste a saved cfg from laptop

b) or copy saved cfg from laptop to usb, then insert usb into RSP440 and copy and commit cfg

c) copy licenses and snmp files back to the RSP’s

16. (Optional) create and generate new crypto keys if required.

Steps to Turboboot

 

As mentioned Turbobooting means that you load the "VM" (virtual machine) XR base OS image.

Turboboot is started from Rommon and is essentially the same as putting a disk with the desired OS in your laptop, reboot the machine to boot from CDROM, and installing the base OS.

Before the Turboboot process starts, you can instruct the system to wipe all files from the system and start clean or install the image to be turbobooted along side with any existing releases currently found on the disk. (see Set the Turboboot variables on the RSP)

Turbobooting may be required if you want to sweep clean your system, or we also had some issues in XR4.2.0 with the RSP2 whereby the upgrade pie could not be loaded. A turboboot was required in that case also.

Some or all of these procedures below are needed.

The command "set" gives you an overview of all the rommon environment variables currently set to their values.

Clear the ROM Monitor environmental variables on all RSPs

unset BOOT
unset TFTP_FILE
sync

the command *unset* clears the variable value from rommon.

the command *sync *saves or writes the newly set and unset variables to persistent memory so they are saved cross reloads and power cycles.

Clear disk mirroring variables

unset BOOT_DEV_SEQ_OPER
unset MIRROR_ENABLE
sync

By default, the two internal USB partitions (disk0 and disk1) are mirrored to each other, if you break the mirror, turboboot will only affect the disk

that you are turbobooting target to and not the other one (nice if you want to fall back).

Disable the CPU watchdog

priv
diswd <- Disable the CPU watchdog

If you omit this step and the TFTP download for the turboboot mini-vm image takes longer than 30 minutes due to network delays etc, then the RSP might reset and you'll have to start over. Disabling this watchdog makes sure the system is not going to reload during the transfer of the image in rommon.

Define the network and IP settings on the mgmt interface

IP_ADDRESS=ip_address
IP_SUBNET_MASK=mask
DEFAULT_GATEWAY=ip_address

Set TFTP environment variables

TFTP_RETRY_COUNT=4

sets the number of retries to contact the tftp server

TFTP_TIMEOUT=6000

sets the TFTP timeout for the transfer, you may need to set this larger to prevent abort during xfer if there are network delays

TFTP_CHECKSUM=1

whether checksum on the transfer is needed, this is adviceable in case the image gets corrupted during transfer.

TFTP_SERVER=server_ip_addr

the server address can also be specified in the boot statement, or fixed in the rommon variable.

TFTP_MGMT_INTF=0

which of the 2 mgmt interfaces you want to use, either 0 or 1 with 0 being the default.

TFTP_BLKSIZE=1400

Setting a larger TFTP block size is recommended to pack larger packets and transfer the VM image quicker. Note that for CRS this variable is TFTP_BLOCK_SIZE.

Set the Turboboot variable on the RSP

TURBOBOOT=on, {boot-device},[format | clean],[nodisablebreak]

on tells us to install add and install activate the packages when we boot from the VM image.

boot-device is which device we want to use to install the OS, typically disk0

format tells us to replace the OS completely except for the admin configuration

clean tells us to replace the OS completely, but other files such as the admin or exec configuration are saved

nodisablebreak allows us to terminate the turboboot via a break signal. The default is to ignore breaks

Example:

TURBOBOOT=on,disk0,format
sync

This will instruct the system to do a turboboot with disk0 as the selected boot device and to use the format option. The format key is optional.

Currently today we only support targeted install to disk0 but this will change likely in XR4.3.1 whereby you can use disk1 as install target.

NOTE: a recent tac case showed that the command for turboboot failed on the ASR9001.

Supposedly this was made to work by omitting the colon after disk0:

Suggesting to try the disk0 (without colon) if the command with colon fails.

 

ASR9K/CRS-PRP Additional Information

 

In CRS the format option works with FAT16 but not FAT32 or QNX4 so a new variable must also be used.

In ASR9K the format and clean options do work but in order to erase the exec configuration, admin configuration, and every other file this additional variable must be used.

 

For these scenarios the following must be set.

TURBOBOOT=on,disk0

MEDIA_FORMAT=disk0:,QNX4

 

Note: If the format or clean options are set in turboboot or confreg 0x2142 is set when also having the MEDIA_FORMAT variable set then when prompted for a new username/password we will be unable to write this to the disk. To fix this go back to rommon and properly set the variables.

 

Boot the remote mini.vm file

(Works only with the VM image, not the TAR file or mini.pie)

rommon> boot tftp://server/directory/filename

During the boot process the image is copied first on to the memory(RAM) and is installed from memory(RAM). Once it is insalled from memory, it will copy the image back on to disk0: and reload the device. Wait till you get the message "SYSTEM CONFIGURATION COMPLETED"

Output of show install active when in memory,

RP/0/RSP0/CPU0:ios#sh install active
<SNIP>
Active Packages:
mem:asr9k-mini-p-4.2.0

Output of show install active after image copied on to disk0:,

RP/0/RSP0/CPU0:ios#sh install active
<SNIP>
Active Packages:
disk0:asr9k-mini-p-4.2.0

The system will also self unset the TURBOBOOT rommon variable.

Restore disk mirroring

To restore disk mirroring, use the mirror command in the global configuration mode. For more information on the mirror command, see the "Boot Commands on Cisco IOS XR Software" module in Cisco ASR 9000 Series Aggregation Services Router System Management Command Reference.

How to boot from the external USB port

The RSP-440 (and 9001 with rommon 2.03) can boot from the USB front panel port. Instead of using "boot tftp:// or boot disk0:/" you need to use a different command, mediaboot.

The command is:

rommon> mediaboot usb:\release_mini.vm

In later revisions of the rommon, the mediaboot has been superseded to boot usb:/<file>

so make sure you try them both.

 

NOTE:

Some newer rommon versions on the 9001 want to use the boot usb:/ directive. (see Q&A/comment section below this article).

It is also seen in rommon versions post 2.04 that the usb is referred to as disk1 in which case you can use: boot disk1:/...

To find out the mapping of the usb disk use the rommon "dev" command to see all filesystem devices.

 

On the CRS-PRP use boot disk2:hfr-mini-px.vm<image>

CRS does not use the mediaboot command.

How to update the FPD's

FPD upgrade for all ASR9K devices using FPD.

a) Enter admin mode via the admin command, and capture the output of the current firmware versions using CLI show hw-module fpd location all. save this output to a text file. Notice any LC that has a “yes” in the Upg/Dng?  column. This indicates the FPD should be upgraded or downgraded to match the current FPD version.

b) From admin mode upgrade FPD using the CLI: upgrade hw-module fpd location r/s/m

or if all locations require FPD upgrade (suggested) use CLI:* upgrade hw-module fpd location all *

Disk Space occupied for each image

Simplest way is to use the ksh df utility.

Install a release and packages and run df:

# df /disk0:

/dev/disk00t77           3813344    733477   3079867      20%  /dev/disk0:/   

Divide the highlighted number by 2000. That gives the approximate size in MB. 366MB in this case.

Repeat for any other releases we should be interested in.

If you do an upgrade, gather the df output before and after upgrade and compute the difference in df output.

Related Information

Xander Thuijs, CCIE #6775

Principal Engineer ASR9000

Sam Milstead,

Customer Support Engineer TAC XR

Comments
mcox-cisco
Level 1
Level 1

Sorry to bump such an old post, but I've been searching high and low for some guidance and this is the closest thing I've found. I am going from 4.3.4 to 4.3.1. While the activation worked fine and the router is running the 4.3.1 now, my question is about the hw-module upgrade process. I get the below message for all 3 of the ASR9K-MOD160-TR rommon agents: 

LC/0/0/CPU0:Nov 17 15:57:33.516 : rommon_fpd_agent[314]: Cannot downgrade rommon on location 0/0/CPU0 from 2.00 to 1.29. Downgrade is prevented to avoid current or future hardware/software incompatibilies. Please contact your Cisco technical representative for further information.

 

On bootup, it provides this message:

LC/0/0/CPU0:Nov 18 06:56:39.913 : rommon_fpd_agent[314]: %PLATFORM-UPGRADE_FPD-4-UP_REV : rommon instance 0 is severely up-rev (V2.00), downgrade to (V1.29). Use the upgrade hw-module fpd" CLI in admin mode.

 

Here's the full hw-module fpd output:

#show hw-mod fpd loc all
Tue Nov 18 06:59:06.003 UTC

===================================== ==========================================
                                      Existing Field Programmable Devices
                                      ==========================================
                                        HW                       Current SW Upg/
Location     Card Type                Version Type Subtype Inst   Version   Dng?
============ ======================== ======= ==== ======= ==== =========== ====
0/RSP0/CPU0  A9K-RSP440-TR              1.0   lc   cbc     0      16.115    No 
                                              lc   fpga1   0       0.10     No 
                                              lc   fpga3   0       4.09     No 
                                              lc   fpga2   0       1.06     No 
                                              lc   rommon  0       0.71     No 
--------------------------------------------------------------------------------
0/RSP0/CPU0  ASR-9010-FAN-V2            1.0   lc   cbc     2      29.11     No 
--------------------------------------------------------------------------------
0/RSP0/CPU0  ASR-9010-FAN-V2            1.0   lc   cbc     3      29.11     No 
--------------------------------------------------------------------------------
0/RSP0/CPU0  A9K-BPID2-10-SLOT          1.0   lc   cbc     6       7.104    No 
--------------------------------------------------------------------------------
0/RSP1/CPU0  A9K-RSP440-TR              1.0   lc   cbc     0      16.115    No 
                                              lc   fpga1   0       0.10     No 
                                              lc   fpga3   0       4.09     No 
                                              lc   fpga2   0       1.06     No 
                                              lc   rommon  0       0.71     No 
--------------------------------------------------------------------------------
0/0/CPU0     A9K-MOD160-TR              1.0   lc   cbc     0      20.118    No 
                                              lc   fpga2   0       1.04     No 
                                              lc   fpga4   0       1.05     No 
                                              lc   rommon  0       2.00     Yes
--------------------------------------------------------------------------------
0/0/0        A9K-MPA-20X1GE             1.102 spa  fpga3   0       0.08     No 
--------------------------------------------------------------------------------
0/0/1        A9K-MPA-8X10GE             1.102 spa  fpga8   1       0.07     No 
--------------------------------------------------------------------------------
0/1/CPU0     A9K-MOD160-TR              1.0   lc   cbc     0      20.118    No 
                                              lc   fpga2   0       1.04     No 
                                              lc   fpga4   0       1.05     No 
                                              lc   rommon  0       2.00     Yes
--------------------------------------------------------------------------------
0/1/0        A9K-MPA-8X10GE             1.102 spa  fpga8   0       0.07     No 
--------------------------------------------------------------------------------
0/1/1        A9K-MPA-8X10GE             1.102 spa  fpga8   1       0.07     No 
--------------------------------------------------------------------------------
0/2/CPU0     A9K-MOD160-TR              1.0   lc   cbc     0      20.118    No 
                                              lc   fpga2   0       1.04     No 
                                              lc   fpga4   0       1.05     No 
                                              lc   rommon  0       2.00     Yes
--------------------------------------------------------------------------------
0/2/0        A9K-MPA-8X10GE             1.102 spa  fpga8   0       0.07     No 
--------------------------------------------------------------------------------
0/2/1        A9K-MPA-8X10GE             1.102 spa  fpga8   1       0.07     No 
--------------------------------------------------------------------------------
NOTES:
1.  One or more FPD needs an upgrade or a downgrade.  This can be accomplished
    using the "admin> upgrade hw-module fpd <fpd> location <loc>" CLI.

Suggestions? Thanks.

Michael

xthuijs
Cisco Employee
Cisco Employee

hi michael, there is generally no need to downgrade FPD's, as everything is backwards compatible. The rommon in particular is really insignificant as it is only use as a bootstrap to get the device/module going at initial power up, after the XR MBI is loaded or being fetched, it is out of the picture already.

If you want to force the upgrade you could do the command

upgrade hw-module fpd rommon loc 0/x/cpu0 force

but I would not recommend it.

the force is disabled for some FPGA's (like the CPLD) as downrev'ing it damages it.

On a related note, I would recommend 434 well over 431.

cheers

xander

smilstea
Cisco Employee
Cisco Employee

Hi Michael,

 

In some cases we prevent downgrading an FPD as it may cause an issue with the card or the card booting. It is almost always better to have an up-revved FPD than not, as they are backwards compatible so no need to worry about this message.

 

Thanks,

Sam

mcox-cisco
Level 1
Level 1

Well, this is for a large financial client that has to go through their rigorous certification process before a new code is utilized in production, so it's going to be 4.3.1 for now.

 

So, just "leave it be" and tell the customer to disregard the messages seen on bootup (and in the log) and when 'show hw-module fpd location all' is run? Is there anything "official" I can point them to beyond this conversation to support this as the best practice here? 

 

Should I leave it upgraded for everything or just the items that won't downgrade. In other words, should all module agents be upgraded to the 4.3.4 fpd while running 4.3.1?

Thanks.

Michael

xthuijs
Cisco Employee
Cisco Employee

hi michael,

I see, just felt I needed to pass on the recommendation of 434 :)

the fpd rev need to be at or above par from the release chosen.

So in your case, it is the least important FPD that wants to be downgraded, so you can indeed easily tell them to ignore it.

If they need some official answer, in case this discussion is not cutting it, then connect with the account team from Cisco and have them reach out to me so I can provide that wording as necessary.

regards

xander

Chris Lester
Level 1
Level 1

Xander,

Hi.

Good document, but have an issue.

 

When i perfom the boot tftp using the asr9k-mini-p.vm-4.x.x file (which was included in the tar) the file is downloaded to the device and starts to boot.

Even shows the new version. RSP0 reports MBI (Starting execution of MBI).  The console if you hit return states : This (D)RP Node is not ready or active for login /configuration.

Eventually it crashes out. Crash : Lite:respawn 'eth_server' diabled, exit_code 3584,INIT_MAX_SPAWN reached Process: init.

Tried this on RSP1. Same result. End up back at rommon>.

 

Any ideas ?

 

Thanks.

Chris.

atif_hafeez
Level 1
Level 1

Hi Xander,

 

For ASR9922:

Can  you please explain how line cards are powered up on cold boot? Is there a sequence?

What if there is no enough power to boot up all the line cards? Will it boot at least the cards that it can support with available power?

What will happen if the platform loses power and it is left with no enough power to maintain all the line cards?

 

Best regards!

xthuijs
Cisco Employee
Cisco Employee

hi atif,

when the system comes online, the fans and R(S)P's (and fabric cards on 9912/9922) are booted always first. Then depending on the available power according to the power budgeting of each card cards are enabled started with slot 0 first and in sequence, until the power budget is reached.

In case of you are running at "max", that is the available budget is say 9kW and the system "needs" 8kW. Assuming an AC model here, so with 9kW available, that is 3 modules installed.

The quotes around "needs" is here that the budgetting assumes a particular temperature profile etc and is the quoted max draw of that card on paper.

The actual draw may be much less (and check show env pow for the actual instant reads of amps/wattage drawn).

Now lets say that a module breaks, so suddenly there is only 6kW available. If the actual draw of the system is at or below 6 it continues to operate. If the chassis were to reload in this case, some cards will not boot because now there is on paper only 6kW available while with the installed config it needs 8kW as per example.

If the system needs more power at this moment then either one of the 2 things will happen:

- the power module breaker trips because of more draw then it supports

- the chassis will shut down completely

- the chassis will reload due to the power drop and upon that some cards at boot will not enable due to the lack of budget power.

this is also documneted in cisco live session ID 2904 from orlando 2013 and sanfran 2014.

cheers!

xander

atif_hafeez
Level 1
Level 1

Hi Xander,

 

Thank you for your feedback. 

 

I checked these documents on Cisco live but couldn't find the details especially for the case where the system loses power and left with no enough power to keep its hardware components running.

 

Can you please elaborate the cases related to chassis shut down vs chassis reload due to the power drop? Are there any thresholds set for these actions to be carried out? 

Is there a mechanism to shut down the power supplies in order to protect them from damage in case of circuit breaker wrong planning or malfunction. This is important to understand to evaluate if we can test such scenarios in our lab.

 

Best regards!

xthuijs
Cisco Employee
Cisco Employee

valid questions but has little to do with the turboboot nature that this document is trying to expand on.

But there is a good discussion going on here:

https://supportforums.cisco.com/discussion/12388966/asr-9k-power-outage-behavior

may want to follow that?

if the breaker wont trip a module may burn through but more likely the RSP will detect voltage loss on its sensors and initiate a reload. after that reload the budget is lowert then needed so some carsd will not boot.

xander

dhpatki
Cisco Employee
Cisco Employee

Hi Xander .. I don't see disk0a: on the ASR9001 that I have. I have the new image to be booted in disk0a:, but I can't see disk0a: from rommon. Currently it is running 5.3.0.

 

All I see is the following

rommon B6 > dev
Devices in device table:
        id  name
bootflash:  bootflash                  
configflash:  configflash   

 

However, bootflash: hardly has any space for the new image.

 

RP/0/RSP0/CPU0:ios#dir bootflash:
Wed Mar 25 17:04:41.086 UTC

Directory of bootflash:

16449560    drwx  48          Tue Nov 11 20:18:41 2014  disk0
19464215    -rw-  0           Tue Nov 11 20:20:55 2014  mbi_image

44695552 bytes total (22865660 bytes free)
RP/0/RSP0/CPU0:ios#dir bootflash:disk0
Wed Mar 25 17:05:13.124 UTC

Directory of bootflash:/disk0

5373954     drwx  40          Wed Nov 12 23:32:49 2014  asr9k-os-mbi-5.3.99

44695552 bytes total (22865660 bytes free)

 

xthuijs
Cisco Employee
Cisco Employee

rommon only has access to bootflash, nvram and if you are on the right fpd rev for rommon it can also see the usb port.

you will need to use a .vm image to turboboot and install the image from memory (turboboot) onto the target disk0.

 

cheers

xander

Hi Xander,

For ASR9922 I don't find the turbo boot image to download from CCO for 4.3.4

Is the turbo boot image only for certain images? I do see the option to download for 5.1.3

Many thanks,

smilstea
Cisco Employee
Cisco Employee

The mini.vm file is in every release, in later releases (5.1.x) we began having multiple tar files, in 4.3.x it is still the old way of having everything package in one tar.

 

Thanks,

Sam

xthuijs
Cisco Employee
Cisco Employee

yeah in 434 it is still part of the big 2G tar file.

we made that change in 51 to split it out. to reduce the file size of the tars a bit.

xander

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Quick Links