[j-nsp] How to pick JUNOS Version

[Andrew Alston]

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 <juniper-nsp-bounces at puck.nether.net> On Behalf Of aaron1 at gvtc.com
Sent: Wednesday, 2 September 2020 01:34
To: 'Kody Vicknair' <kvicknair at reservetele.com>; 'Roger Wiklund' <roger.wiklund at gmail.com>; 'Colton Conor' <colton.conor at gmail.com>
Cc: 'Juniper List' <juniper-nsp at puck.nether.net>
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 at acx5048> show system information | grep Junos
Family: junos
Junos: 17.4R2-S11

name at acx5048> show route instance mgmt_junos detail
mgmt_junos:
Router ID: 0.0.0.0
Type: forwarding State: Active

-Aaron


_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp>