[j-nsp] upgrading M120 directly from 8.5 to 9.3

[Richard A Steenbergen]

On Mon, Jan 11, 2010 at 02:59:48PM -0500, Chuck Anderson wrote:
> Juniper recommends not upgrading more than 3 releases, but 8.5 to 9.3 
> would be a 4-release upgrade (9.0 - 9.1 - 9.2 - 9.3).  Has anyone done 
> this with success?  It seems strange to me that Juniper wouldn't test 
> and support an upgrade from one E-EOL release to another without 
> having to jump through a non-E-EOL release, and in fact a release that 
> has actually reached EOL.
> 
> 8.5 reaches EOL on 2011-05-15
> 9.2 has reached EOL as of 2009-11-15

Realistically, there is no reason you shouldn't be able to do an upgrade
across a lot more releases than that (though I'm told you can't go from
7.x->10.x because the 7.x validation code doesn't like two digit version
numbers :P). There are two ways you can upgrade JUNOS, a jbundle image 
and a jinstall image. The jbundle image does an in-place upgrade, 
swapping out all of the mdimg files for new versions, and then 
requesting that you reboot into the new images. A jinstall image is the 
jbundle image plus an installation image similar to what you'd find on a 
clear install image. This image copies the old config into memory, does 
a complete newfs and clean install on the dest drives, and reloads the 
old config. The jinstall process takes longer since it has to do two 
reboots, a newfs, and a bunch of other extra stuff, but it almost always 
gets everything.

The only time you should really see problems with a jbundle are when 
there are major changes in the underlying OS. For example, JUNOS 5.0 
switched from a FreeBSD 2.2.6 to a FreeBSD 4 based kernel, which changed 
the device names for ide drives from "wd" to "at". Another not quite as 
major overhaul was done in 8.5, so when you go between 8.4 and 8.5 you 
need to do a jinstall. The biggest problems I've had with version 
incompatibilities are with "uncommon" features like commit scripts, 
interacting with portions of the config. For example, I had a lot of 
grief with the rename of logical-routers to logical-systems + commit 
scripts when crossing 9.3. Our solution was to blank out the config of 
the (backup) RE in question, do the upgrade, and rebuild everything from 
a clear slate.

$10 says they just don't want to devote the QA cycles to testing every
possible combination of every version. Given that QA clearly has better
things to be doing with their time, I guess I don't mind that much. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)