CRS 4.0.4 to 4.2.3 Upgrade

Question

Dear all,
I have to upgrade a couple of CRS nodes from 4.0.4 to 4.2.3.
These nodes are in production, and I will carry out this upgrade in a maintenance window, however even so I am forced to minimise downtime.
Is there any way I can do this by upgrading one RP at the time ? I have a single node running 4.2.3 already, can this be used to clone a single RP S/W, which is then moved to another chassis...leading to a faster upgrade ?
I am expecting that only downtime will be when S/W is pushed to LCs.
The Cisco guides are straightforward and I have used them before for similar tasks, but for newly rolled out nodes, and never needed a quick fix until now.
TIA
/Samir

Answer 1

Hi Samir,
this approach will not reduce the upgrade time significantly.
First, there is probably some misconception in the approach when you say "push the software" to the line cards. In CRS and ASR9K systems, the image is not simply loaded from the RP to the LC, we have a complete file system locally (in a storage device local to the line cards) and software is booted from it.
Your approach of "baking" a PRP from another router (I suppose you plan to insert it in the RP1 slot of another router or to do it in the lab), when you will want to upgrade your router, you'll have to:
- eject the remaining PRP present in RP0 slot, the whole router stops at that moment
- insert the upgraded PRP in RP0 slot, the RP0 boots up and all line cards, fabric cards and other components (fan controllers, etc) boot an realize they are not running the proper image, they will require the RP to provide the MBI and start loading this minimum boot image, then they will start to construct the file system for each "node" (installing all the packages, SMUs, etc). This operation will take quite a long time and all the line cards and fabric cards will reload again to boot on the proper file structure.
In your case, if you use the "normal" install add/activate approach, it will offer several avantages:
- the impact on traffic will be only when the reload is triggered by the install activate phase (all the install add phase is impact less) 
- you can rollback to the previous software version
- it's a fully tested and supported approach
- finally, using a production router to bake (or clone if you prefer) a PRP implies that two boxes on your network will work with only one RP at some point, and it doesn't seem to be a very wise thing to do.
HTH,
N.