Hi,N,

    we have different customers, one customer run two 2+4 , which version is 3.8.4, run PRP, we want to update main version to 4.3.2 whis is cisco suggest.

    the traffic load is very high on each multi shelf, upgrade CRS-1 multi shelf ios is a important job, how can i avoid down time when i upgrade.

   another customer has a 2+2, it is RP, version is 3.6.x, we want to upgrade 4.3.2 also,but i think it is diffcult, but this multi shelf is not very very important as above, it is also important. maybe permit down time.

   is there any detail upgrade procedure for multi shelf crs-1?

   thank you!

Tom

Hi Tom,

Since you are already running a PRP with 3.8.4, the golden disk option is no longer available (no removable / replaceable volumes in the PRP, it was an RP/RP-B thing).

If you are starting from a system with RP-B, then it's probably a good time to upgrade to PRP and therefore, a good upgrade option would be to prepare the PRPs with the target version in lab and "simply" swap them during the maintenance window.

But if it's not the case, you have only two options.

1- PIE upgrade. From 3.8.4 to 4.3.2, we don't officially support upgrade from two distant versions. It's not that it will not work, it is more that we can not test all the upgrade combinations with more than two major releases so we can not guarantee it's supported. In these cases, we usually recommend to upgrade to an intermediate version. Starting from 3.6 is even worse.

The PIE upgrade is long but most of it (preparation of the file system structure, ...) is performed without any service impact. Once everything is ready and prepared in all cards of all chassis, then the system is reloaded (and you have service impact of course).

2- turboboot upgrade.

This approach is probably the best (or less bad) option.

You need to upgrade rommon before shutting down the system (using the .bin files and the hidden CLI commands) then you will change the config-register to 0x0 and reload location all.

All your chassis will be stuck in rommon mode, no service anymore. You'll have to turboboot the 0/RP0 which will take 20 to 30min. Once done, the first chassis will reload, all line cards will be upgraded automatically. You will need to upgrade FPGA after all the line cards get back to life (and reload them again). In parallel, you will be able to change config register on all RPs (to 0x2).  They will get the new version (4.3.2) from the DSC (the 0/RP0). And again, once the other chassis are reloaded, you'll need to upgrade FPGA on their cards.

I know it may sound complex, but in term of impact duration / maintenance window, that's certainly the best option rather than using several intermediate versions.

I suggest you contact the Cisco Advanced Services team, they performed this kind of operations regularly and are very well versed with all the subtleties (ask your cisco rep).

Kind regards,

Nicolas.

//If you are starting from a system with RP-B, then it's probably a good time
to upgrade to PRP and therefore, a good upgrade option would be to prepare
the PRPs with the target version in lab and "simply" swap them during the
maintenance window.

HI Nicolas,

     you mean my RP/RP-B chassis should upgrade to PRP, and using method by your said to prepare a spare PRP, and upgrade it in lab , then simply replace PRP of 0/rp0.

    can I use RP/RP-B to do this upgrade procedure.

    thank you!

Tom

Hi Tom,

yes, the same principles can be used if you get enough RP-Bs and have a lab to pre-stage them. You will need to be cautious playing with the serial numbers for the LCCs and FCCs but aside from that, it perfectly possible indeed.

When you will shut down the MC, swap the RPs and make sure the config is ok. All linecards / fabric cards will be upgraded automatically to the targeted version.

Again, you'll have to upgrade the FGPAs/ROMMONs too for line cards and fabric cards (and reload one more time each card individually).

Best regards,

N.

Hi Tom,

let me try to answers these points one by one (to the best of my rusty knowledge ;)):

     1、for turboboot:what is the hidden command for upgrading rom monitor, I once updated rom monitor B to 2.7 according cisco document, It was successful.

Actually the "hidden command" is in the IOS XR CLI, not at the ROMMON level.

The idea here is to upgrade the linecard / RP / fabriccard to a different rommon version than the one embedded in the FPD package of the current version.

You can DL the binaries here:

http://software.cisco.com/download/release.html?mdfid=279506646&flowid=1929&softwareid=280867576&release=2.09&relind=AVAILABLE&rellifecycle=&reltype=latest

Take a look at the section "ROMMON Upgrade Instructions" from http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-0/migration/guide/ugbook/tbupgapp.pdf

(you'll have to upload the .bin files in the disk0 root directory and use the hidden commands "upgrade rommon b all disk0" in admin mode. When I say hidden, it means it's not auto-completed by the parser).

2、for turboboot: is this correct procedure: I config all chassis RP register to 0x0, and reload all, and once finish upgrading 0/RP0--->change 0/RP0 registor to 0x2(automatically)---->reconfig multi-shelf config---->load backup config(priviledge and admin mode config)---load backup license--->reload 0/RP0--->upgrade FPGA(DSC)---->then config all other RP's register to 0x2--->reload all RP on multi shelf-->then auto sychronization system software and config--->upgrade FPGA on other RP of multi shelf.

     is this a correct sequence for upgrading crs-1-multi shelf?

That sounds good but if my memory doesn't fail me, the MC config is in admin mode and this config is not lost with turboboot (even with the format option). I suggest to consider the worst case, like you did.

Also, remember that's a part of the MC config appears in the rommon mode (when you type "set", you'll see info on the LCC/FCC serial numbers).

    3、for turboot: I lost all config when using turboboot, how can i reconfig multishelf config . such as oim,LCC,FCC chassis connection config? after that does i need load backup config and license?

Aside the config lost with rommon (same comment above), you are perfectly right and indeed I didn't mention the licenses but I think you are totally right there too.

    4、for goldendisk:no removable / replaceable volumes in the PRP. I don't know what exactly mean of removeble/replaceable volumes.

What I meant here is that RP-B had a PCMCIA volume (disk0:) that can be removed from the RP board and replaced by another one pre-staged in lab. It's not possible anyway in the PRP since disk0: is now a partition of the SSD volume which can not be extracted from the RP board.

Regarding the config lost or not on turboboot, let me ask around and get back to you :)

Thanks,

NF.

Hi NF,

    Thank you!

    1、If use spare RP/PRP replaced method, from your advice, I think I should reconfig LCC.FCC serial number in rommon , and reconfig OIM,FCC multichassis connection in admin config mode(I can restore config from backup config), I think procedure like this:

      update spare RP/PRP in lab using turboboot method-->config all RP register to 0x0--->reload all RP/FCC SG--->replace 0/RP0 with new RP/PRP--->reconfig LCC/FCC serial number in NEW RP/PRP rom monitore-->boot--->reconfig LCC/FCC multichassis connection in admin mode(or restore license and restore backup config)--->reconfig register to 0xF---->reconfig left RP/SG register number to 0xF and reload --->sychronization config and software from dsc RP0.

    but i don't know how to config FCC/LCC serial number in DSC RP0 rom monitor and how to config multi chassis connection in admin mode.

2、for turboboot update method , you said the multi chassis config in DSC 0/rp0 rom monitor and in config admin mode can't lost , I don't need to woryy about config lost when upgrade using turboboot method?

    sorry for the late , i am busy on working.

  Thank you again!

Tom

Hi Tom,

1- I never performed such a migration but the plan sounds right indeed.

2- Got confirmation that the admin config is not lost when turbobooting. So, the OIM and serial numbers are preserved and the system will boot properly after the turboboot upgrade.

Kind regards,

N.