On Sat, Mar 9, 2019 at 7:11 AM Mark Tinka <mark.tinka@seacom.mu> wrote:
> Just as with FreeBSD (if you've used it before), you can upgrade to 11
> if you are coming from 9.3 and any official version of 10. For anything
> earlier than that, you'd need to upgrade to 10 first.
I don't think this is it. Junos is lot more immutable installation
than your laptop Linux or FreeBSD. On your laptop the FreeBSD upgrade
just puts new files on top of old ones retaining vast majority of the
state, even running state until you reboot to new kernel.
On Junos the upgrades are mostly fresh install with partition or two
for mutable data, like config etc which are kept in place. Which also
means any config change you do _AFTER_ issuing 'request vmhost softare
add' are gone, as that installation process stores the mutable data
preparing next boot for fresh install. So you can't capitalise on
Classic IOS style 'i'll stage new image on all boxes and get some free
upgrades due to crash, power outage etc', which I've used in the past
for 0 cost upgrades for thousands of devices, when there was no urgent
need to upgrade and I hope we can get back to it some day.
So Gert's question 'y tho?' is very much valid, and the most obvious
reasons is because Juniper doesn't want to increase the product cost
to cover lab testing from any-to-any, as it would mean ever increase
money and time cost to release. By setting some fixed rules, they have
fixed amount of work to test the upgrade. I doubt Cisco has actually
formally supported any-to-any on classic IOS either.
That's still unsatisfactory answer, because if it's fresh install,
shouldn't it just work, like people pointed out classic IOS goes
anywhere to anywhere. There are few reasons why it might not work
a) The install at OLD version fails to install the NEW version,
nothing bad happens, you just can't install the NEW on. Practical
example:
- this recently happened in many platforms like qfx5k and ptx1k,
because OLD release reported itself as systctl 'hw.product.model'
which happens to be 'pvi-model' for all. The NEW version installer
asks will only proceed if the platform is correct model and
'pvi-model' is not listed as correct model, so installer will give up.
The problem is, the OLD version should have reported itself as sysctl
'hw.product.pvi_model' and it would have just worked or the NEW
version should have accepted upgrades from platforms called
'pvi-model', but then upgrade would have proceeded on PTX1k with QFX5k
image . So here you must go from OLD version to ANOTHER version where
it doesn't do the verification and then from ANOTHER version to NEW
version where ANOTHER version correctly claims to be
'hw.product.pvi_model'.
b) The installation is success, but platform doesn't come up configured right:
- Because IOS accepts config unatomically line-by-line, you can
give it arbitrarily bad config, and it'll eat what it can, making it
robust between version changes. This is not true for Junos, it's easy
to come up with config which just causes commit to barf, so when the
new version is coming up it comes up unconfigured. This is the most
typical reason why upgrade doesnt work, and you're gonna be mostly
fine you just need console connection to address the config issue and
with cursory understanding you'll fix it in a minute.
I'm sure there are other reasons, but just pointing out couple I know
I've ran into. But personally I would always try direct upgrade from
any-to-any and USUALLY it will just work and MOST times when it does
not work, you can address it with small config change before upgrade,
greatly reducing your upgrade time compared to approved upgrade path.
--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
