Hi Erik, The process is well documented in the following file (ASR9K-x64-docs-6.3.2.tar) . Its in the image download section. But as of i know you need a bridge SMU from 6.3.1 to 6.3.2 . Not sure 6.3.1 bridge SMU (CSCvf01652) publically available better reach out account team or open a case. This smu has two component one for Admin and other for XR. Unless you apply both it doesn't allow to upgrade. Good luck with upgrade :).
Best Regards, Gobinath. On Fri, Apr 13, 2018 at 10:35 PM, <adamv0...@netconsultings.com> wrote: > > Tom Hill > > Sent: Friday, April 13, 2018 1:46 PM > > > > On 12/04/18 18:06, Gert Doering wrote: > > > yum update > > > > > > ... now *that* would be nice... > > > > I thought you could do that... > > > > https://www.cisco.com/c/dam/assets/global/DK/seminarer/pdfs/XR60.pdf > > (pgs. 30 & 31) > > > Page 26 of the same doc: > IOS XR packages are installed with "install update/upgrade". > Install commands are a wrapper around YUM to provide multiarch > support. > -so there's your yum update > > But from the initial discussions on this from a few years back I thought > I'd > be able to spin up container on new version and then just switch to new one > in an instance, or failback quickly if needed, preferably 0 packet loss in > the process (maybe I'm mistaken ncs6k with asr9k). > Makes me wonder what's going on under the hood on asr9ks ncs5ks actually > -i.e. how does the picture look like at each LC (I guess we'll need to wait > till this "modular" architecture arrives to LCs as well?) > In this sense, to me the router chassis is like a small DC with compute > nodes (in form of RPs and LCs) all connected via Ethernet network -it would > be nice to have control over which containers and what versions run on each > compute node. > And regarding the 0 packet loss, > I'm wondering whether the NPU microcode version is independent of the (I > guess Admin Plane) version (or whether it's still monolithic) > > Also wondering when we'll be able to take RPs out of the chassis that is > spin up the Control container(s) (and third party containers) on COTS HW > and > let these talk to LCs. > As unfortunately these chassis-based systems can become full with just > couple of LCs in them just because the RP can't cope with the high number > of > VRFs, prefixes and BGP sessions. > > adam > > netconsultings.com > ::carrier-class solutions for the telecommunications industry:: > > _______________________________________________ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/