Re: [j-nsp] Old JunOS upgrade path
This is not applicable to MX80 (as platform was mentioned by topic starter). On 12-Mar-19 15:38, adamv0...@netconsultings.com wrote: Upgrading from 12.3 to 15.1 upgrades the FreeBSD version from 6.1 to 10.0. Upgrading from 12.3xxx to 15.1xxx reformats the file system. Only specific files and directories are preserved. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Old JunOS upgrade path
> Saku Ytti > Sent: Sunday, March 10, 2019 2:49 PM > > On Sun, Mar 10, 2019 at 4:30 PM Tom Beecher > wrote: > > > was when it was shut down. ( Hopefully. :) ) When you upgrade it, the > > process only modifies certain components. Any OS upgrade process like > > that > > This is not true, the upgrade is fresh install. It is not like you do upgrade on > your laptop FreeBSD or Linux. > > Equivalent on your laptop would be that you keep your config in directory > /config, have that in partition you don't touch then reinstall new FreeBSD on > your system partition and remount that /config partition. You just lost all the > programs you've installed outside base system and any other changes you've > done outside /config. > > Your laptop FreeBSD doesn't know what exists in the system what data has > been changed, what has been installed it can't just steamroll the installation > with new, so it'll reinstall new stuff on top of old one for the things it knows > about. Juniper doesn't have this problem, they know what is the state of the > system so they can just streamroll it and they do. > > Hmm looking at my old junos upgrade procedures form 12 to 15 I found the following statements: Upgrading from 12.3 to 15.1 upgrades the FreeBSD version from 6.1 to 10.0. Upgrading from 12.3xxx to 15.1xxx reformats the file system. Only specific files and directories are preserved. Only specific files and directories are preserved unless precautions are taken. Juniper document reference that states the above is: http://www.juniper.net/documentation/en_US/junos/topics/task/installation/ju nos-os-upgrading-kernel-freebsd10.html Since the JUNOS upgrade is from JUNOS with FreeBSD kernel version 6.1 to a JUNOS with FreeBSD kernel version 10.0, there is a requirement to upgrade to an intermediate JUNOS version (13.3 or 14.2) first. Table 1 in the following Juniper document reference quotes it: http://www.juniper.net/documentation/en_US/junos/topics/task/installation/ju nos-os-upgrading-kernel-freebsd10.html On the backup RE1, the configuration compatibility against the 15.1xxx software release cannot be performed due to upgrading from JUNOS software with FreeBSD 6.1 to a JUNOS software version with FreeBSD 10.0. Therefore skip the validation using the JUNOS CLI command "request system software add /var/tmp/junos-install-mx-x86-64-15.1tgz no-validate". Do not use the "reboot" option here as this is not supported for this type of software upgrade. In order to avoid PR(not externally available) we need to deactivate config related to console before doing upgrade to 15 So yeah there's a lot of stuff to pay attention to. I suggest you read the release notes, section Basic Procedure for Upgrading to Release to find more info and more documentation. Oh and always test the upgrade in lab -to avoid running into nasty PRs in production during the upgrade night. And best approach is to have pre-upgraded REs adam ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Old JunOS upgrade path
On Sun, Mar 10, 2019 at 4:30 PM Tom Beecher wrote: > was when it was shut down. ( Hopefully. :) ) When you upgrade it, the > process only modifies certain components. Any OS upgrade process like that This is not true, the upgrade is fresh install. It is not like you do upgrade on your laptop FreeBSD or Linux. Equivalent on your laptop would be that you keep your config in directory /config, have that in partition you don't touch then reinstall new FreeBSD on your system partition and remount that /config partition. You just lost all the programs you've installed outside base system and any other changes you've done outside /config. Your laptop FreeBSD doesn't know what exists in the system what data has been changed, what has been installed it can't just steamroll the installation with new, so it'll reinstall new stuff on top of old one for the things it knows about. Juniper doesn't have this problem, they know what is the state of the system so they can just streamroll it and they do. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Old JunOS upgrade path
This was, and still is, the most accurate answer in the thread. To expand on it further Cisco IOS images are standalone binary images. Each time the device is powered on, it loads the image it is configured too, and executes it. The entire operating system is encapsulated in this image file, and it's execution is completely independent of any image is has executed previously, or will in the future. You don't really 'upgrade' a Cisco IOS device ; you just tell it to load a different image. Junos is a complete operating systems. Just like your home computer, each time the device loads, it is loading the complete OS in the state that it was when it was shut down. ( Hopefully. :) ) When you upgrade it, the process only modifies certain components. Any OS upgrade process like that will have restrictions and dependencies that dictate where you can upgrade from based on where you are now. You always have an option to do a clean install of the version you want, but that is a complete removal and replacement of the entire OS. Cisco NX-OS is the same way. I've watched our datacenter guys have to do the exact same intermediate upgrade, X -> Y -> Z , if the version gap was large enough that X -> Z was not doable. Exact same reason as JunOS. On Fri, Mar 8, 2019 at 4:14 PM Gert Doering wrote: > Hi, > > On Fri, Mar 08, 2019 at 01:17:44PM -0700, Eldon Koyle wrote: > > Many (most?) network operating systems are an image file that the > > switch either writes over a partition (ie. block-level copy) or boots > > directly (ie. initrd/initramfs) with a separate partition for a config > > file. Junos is a full BSD operating system that installs packages to > > partitions on the device, runs upgrade scripts, etc. > > So? > > gert > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never > doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh > Mistress > > Gert Doering - Munich, Germany > g...@greenie.muc.de > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Old JunOS upgrade path
On 9/Mar/19 11:18, Saku Ytti wrote: > 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. You may be right. I have a dinner planned with some Juniper folk that seem to have clue. I'll definitely ask this question and see what lands. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Old JunOS upgrade path
Hi, On Sat, Mar 09, 2019 at 11:18:35AM +0200, Saku Ytti wrote: > 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 [..] This is actually a very good point. Thanks. Note to self: have console access in place for major jumps (or test specific config beforehand on identical-hardare lab device). gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Old JunOS upgrade path
Hi, On Sat, Mar 09, 2019 at 07:07:49AM +0200, Mark Tinka wrote: > With Junos being based on FreeBSD, you can see why this makes sense. Not really :-) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Old JunOS upgrade path
On Sat, Mar 9, 2019 at 7:11 AM Mark Tinka 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
Re: [j-nsp] Old JunOS upgrade path
On 8/Mar/19 23:12, Gert Doering wrote: > So? 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. You can upgrade to 10 if you are coming from any official versions of 7, 8 and 9. If you have anything earlier than that, you need to upgrade to 9 first. You can upgrade to 12 if you are coming from any official release of 11. For anything earlier than that, you need to upgrade to 11 first. And so on and so on, for the reasons that Ola has highlighted. With Junos being based on FreeBSD, you can see why this makes sense. Mark. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Old JunOS upgrade path
On 8/Mar/19 16:56, Pierre Emeriaud wrote: > > As others said, direct upgrade is somewhat unsupported and quite bold. > > We're currently upgrading mx480s from 13.3R5 to 17.2R2 with an > intermediate step on 15.1F5. As those are LNSes we have to activate > tomcat (`services subscriber-management`) while in 15.1, then continue > the upgrade. If memory serves, we rolled out our new backbone back in 2014 on 14. We totally skipped 15 and went straight to 16. We are now on 17. We usually do an upgrade once a year, in many cases moving to the next major release in the line. We didn't do this for 15 because we spent most of 2014 - 2016 in roll-out. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Old JunOS upgrade path
My point is only that they made a _lot_ of changes to the underlaying systems between 12/13/14 and 15 (as far as I understand it 15 is basically forked from 12, so changes done in 13 and 14 are not necessarily in 15). But they still changed a lot, especially the whole change from running as a os directly on the hw, to a virtualised environment on many platforms etc. started in 15. So that is why I would suggest going from whatever you have that is less than 15, to 15.1, and then going from there to whatever you want to go to that is higher than 15. These days, the major number is only representing the year (it always has, but today to an even greater extent). So the difference beween eg. 17.4 and 18.1 is not neccesarily more greater than the difference between 17.3 and 17.4. /Ola (T) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Old JunOS upgrade path
Lately, we have been upgrading lots of our ACX5048's from 15.1X54 (D51 and D61) to 17.3R3.10 -Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Old JunOS upgrade path
Hi, > On Fri, Mar 08, 2019 at 01:17:44PM -0700, Eldon Koyle wrote: >> Many (most?) network operating systems are an image file that the >> switch either writes over a partition (ie. block-level copy) or boots >> directly (ie. initrd/initramfs) with a separate partition for a config >> file. Junos is a full BSD operating system that installs packages to >> partitions on the device, runs upgrade scripts, etc. > > So? I didn't do an upgrade but I replaced an SRX last week. Went from an SRX210 with 12.1X to an SRX345 with 18.4R. Almost the whole configuration was copy The interface names were different, but that was about it. I see no reason why an upgrade wouldn't have worked: it's basically the same as copy an old config to a new OS release. Cheers, Sander signature.asc Description: Message signed with OpenPGP ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Old JunOS upgrade path
Hi, On Fri, Mar 08, 2019 at 01:17:44PM -0700, Eldon Koyle wrote: > Many (most?) network operating systems are an image file that the > switch either writes over a partition (ie. block-level copy) or boots > directly (ie. initrd/initramfs) with a separate partition for a config > file. Junos is a full BSD operating system that installs packages to > partitions on the device, runs upgrade scripts, etc. So? gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Old JunOS upgrade path
Many (most?) network operating systems are an image file that the switch either writes over a partition (ie. block-level copy) or boots directly (ie. initrd/initramfs) with a separate partition for a config file. Junos is a full BSD operating system that installs packages to partitions on the device, runs upgrade scripts, etc. -- Eldon On Fri, Mar 8, 2019 at 12:28 PM Gert Doering wrote: > > Hi, > > On Fri, Mar 08, 2019 at 10:38:16AM +0100, "Rolf Hanßen" wrote: > > usually they say not more than 2 major releases in one step (i.e. 13 -> 15 > > -> 17). > > So why is that? > > Genuinely curious, as I do not have much JunOS upgrade experience - and > my Cisco IOS experience so far has been "you can go from wherever you > are to wherever you want to go" - when going up, you can hit warnings > about "old config syntax", and when going down, you might lose config > bits that are "new" - but besides this, things generally work. > > gert > > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh Mistress > > Gert Doering - Munich, Germany g...@greenie.muc.de > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Old JunOS upgrade path
Hi, On Fri, Mar 08, 2019 at 10:38:16AM +0100, "Rolf Hanßen" wrote: > usually they say not more than 2 major releases in one step (i.e. 13 -> 15 > -> 17). So why is that? Genuinely curious, as I do not have much JunOS upgrade experience - and my Cisco IOS experience so far has been "you can go from wherever you are to wherever you want to go" - when going up, you can hit warnings about "old config syntax", and when going down, you might lose config bits that are "new" - but besides this, things generally work. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Old JunOS upgrade path
Le ven. 8 mars 2019 à 10:26, Robert Hass a écrit : > > Hi > Can I do direct upgrade of JunOS 13.2S to 17.4S ? > Platform is MX80 > Or should I go step by step: i.e: > 13.2 -> 14.1 > 14.1 -> 15.1 > 15.1 -> 16.1 > 16.1 -> 17.1 > 17.1 -> 17.4 As others said, direct upgrade is somewhat unsupported and quite bold. We're currently upgrading mx480s from 13.3R5 to 17.2R2 with an intermediate step on 15.1F5. As those are LNSes we have to activate tomcat (`services subscriber-management`) while in 15.1, then continue the upgrade. For downgrades besides deleting the subscriber-management configuration we disable GRES and commit sync, and it goes smoothly. HTH, pierre ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Old JunOS upgrade path
I can only offer that if you want to go 13.x direct to 17.x: - you ought to do a lab test as this is not officially endorsed. - I know downgrading from 17.x to 15.1 has been problematic in our lab, requiring USB stick recovery. - I know that upgrading from 15.1 to 17.4 is fine. Avoiding lab time/risk, what Ola suggests is the simplest most pragmatic approach if you have a small number of boxes. If you have many, 13.x direct to 17.x is a more attractive option if you can prove in the lab, to your satisfaction, that it works for you. Niall Donaghy Senior Network Engineer GÉANT T: +44 (0)1223 371393 M: +44 (0) 7557770303 Skype: niall.donaghy-dante PGP Key ID: 0x77680027 nic-hdl: NGD-RIPE Please note my work days are Tuesday through Friday. Networks • Services • People Learn more at www.geant.org GÉANT Vereniging (Association) is registered with the Chamber of Commerce in Amsterdam with registration number 40535155 and operates in the UK as a branch of GÉANT Vereniging. Registered office: Hoekenrode 3, 1102BR Amsterdam, The Netherlands. UK branch address: City House, 126-130 Hills Road, Cambridge CB2 1PQ, UK. -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Ola Thoresen Sent: 08 March 2019 09:41 To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Old JunOS upgrade path Not that I am in any way authoritative... And I think Juniper has official guidelines, but these might be a bit conservative. Depending on your config and feature sets. But I would at least suggest doing a few steps. 13.2 to 15.1 should be ok - skipping 14. 15.1 to 17.1 (and probably even 17.4) should also be ok, skipping 16. But do a backup, and verify in each step. The biggest changes are from < 15 to 15+ /Ola (T) On 08.03.2019 10:23, Robert Hass wrote: > Hi > Can I do direct upgrade of JunOS 13.2S to 17.4S ? > Platform is MX80 > Or should I go step by step: i.e: > 13.2 -> 14.1 > 14.1 -> 15.1 > 15.1 -> 16.1 > 16.1 -> 17.1 > 17.1 -> 17.4 > > Rob > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Old JunOS upgrade path
Not that I am in any way authoritative... And I think Juniper has official guidelines, but these might be a bit conservative. Depending on your config and feature sets. But I would at least suggest doing a few steps. 13.2 to 15.1 should be ok - skipping 14. 15.1 to 17.1 (and probably even 17.4) should also be ok, skipping 16. But do a backup, and verify in each step. The biggest changes are from < 15 to 15+ /Ola (T) On 08.03.2019 10:23, Robert Hass wrote: Hi Can I do direct upgrade of JunOS 13.2S to 17.4S ? Platform is MX80 Or should I go step by step: i.e: 13.2 -> 14.1 14.1 -> 15.1 15.1 -> 16.1 16.1 -> 17.1 17.1 -> 17.4 Rob ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Old JunOS upgrade path
Hi, usually they say not more than 2 major releases in one step (i.e. 13 -> 15 -> 17). kind regards Rolf > Hi > Can I do direct upgrade of JunOS 13.2S to 17.4S ? > Platform is MX80 > Or should I go step by step: i.e: > 13.2 -> 14.1 > 14.1 -> 15.1 > 15.1 -> 16.1 > 16.1 -> 17.1 > 17.1 -> 17.4 > > Rob > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Old JunOS upgrade path
Hi Can I do direct upgrade of JunOS 13.2S to 17.4S ? Platform is MX80 Or should I go step by step: i.e: 13.2 -> 14.1 14.1 -> 15.1 15.1 -> 16.1 16.1 -> 17.1 17.1 -> 17.4 Rob ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp