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.
