On Sat, Mar 9, 2019 at 7:11 AM Mark Tinka <mark.ti...@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