So - been giving kinda a fair bit of thought to the original question about how one picks their junos version.
I think - for me it comes down to a whole range of variables - and a lot of them relate to resources among other things. 1. Don't upgrade if you don't need to - if there is absolutely nothing you need in the new code - and no serious fixes - don't fix what aint broke That's rule number #1 Then - it gets a little more difficult - well in our case anyway - we do it this like: 1. Join the beta program - and every beta that comes out - the first thing we do is run the production configs through it in the lab - make damn sure everything we have CURRENTLY is working - if it aint - file the bug reports and try and get it fixed before release 2. Start looking at the new features - decide what may be useful - if anything - and start testing to that to death - again preferably before release so that the fixes can be in when it is released 3. If there are no new features that we see that are of interest - skip the release - though we tend to be pretty early adopters of a lot of tech - so we upgrade pretty frequently. The con of the approach we take - is that it requires resources - both time and human resource. The advantage of it is - we know exactly where the trip points are going into each release - we know what we can live with and what we can't. I've also found that it develops your skills immensely - because when you're working with stuff pre-release its not like you can go running to jtac - ideally you wanna be able to get to the point where you can identify the bug - and go as low level as possible so when you submit your reports you can point to the exact case and say - this is where there is a problem. The net result of this is that you learn one hell of a lot about the devices and the protocols in this process. I realize that what I've said above is almost certainly not applicable to most companies - but it is how we approach things - get it early - test it to death in the lab - and then decide if its worth deploying. I'd also say - the more people who go out there and test early - the better advantage for everyone else - because the fact is an operator is going to always find things and see things that a vendor probably won't - purely because of diversity of the networks and how much stuff the operators are likely to throw at the box. Anyway - that's the kinda approach we like to take. Thanks Andrew From: juniper-nsp <[email protected]> On Behalf Of [email protected] Sent: Wednesday, 2 September 2020 01:34 To: 'Kody Vicknair' <[email protected]>; 'Roger Wiklund' <[email protected]>; 'Colton Conor' <[email protected]> Cc: 'Juniper List' <[email protected]> Subject: Re: [j-nsp] How to pick JUNOS Version Thanks Kody, 2 questions sir... I recently began moving towards that same version (17.4R2-S11) as I was hitting PR1419761 high cpu. 1 - did you upgrade straight from 15.1x54D51 to 17.4R2-S11 , or did you take an intermediate step? Asking since JTAC recently told me that this was too far of a jump and I should go through 17.1 on my way to 17.4 15.1X54--------17.1----------17.4 2 - do you use that mgmt_junos route instance? I would've expected to see em0 or fxp0 in there or something like that, but I don't. name@acx5048> show system information | grep Junos Family: junos Junos: 17.4R2-S11 name@acx5048> show route instance mgmt_junos detail mgmt_junos: Router ID: 0.0.0.0 Type: forwarding State: Active -Aaron _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp> _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
