Re: [j-nsp] How to pick JUNOS Version

[adamv0025]

> Saku Ytti
> Sent: Wednesday, September 2, 2020 8:37 AM
> 
> On Wed, 2 Sep 2020 at 10:23, Andrew Alston
>  wrote:
> 
> >   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
> 
> How do people measure this? Vendors spend tens or hundreds millions
> annually on testing, and still deliver absolute trash NOS, to every
vendor, and
> there is no change that I can observe +20 years in quality. Basic things
are
> broken, and everyone finds new fundamental bugs all the time.
> 
> I think NOS are shit, because shit NOS is a good business case and good
NOS
> is a bad business case, I know it sounds outrageous, but let me explain.
> Vendor revenue is support contract, not HW sales. And a lot of us don't
need
> help on configuring or troubleshooting, a lot of us have access to
community
> which outperforms TAC on how to get that box working. But none of us has
> access to the code, we can't commit and push a fix. If the NOS would work,
> like Windows, Macos or Linux that you rarely find bugs, a lot of us would
opt
> out from support contracts, and would just buy spare HW, destroying the
> vendor's business case.
> 
> I don't think vendors sit in scary skull towers and plans for shit NOS, I
think it's
> emergent behaviour from how the market is modelled.
> And there are ways I think the market could change, but I'm already
> venturing too far from the question to explore that topic.
> 
> 
> 
> Now when it comes to testing, many claim it is important and it matters.
I'm
> not convinced. And I don't think people are looking at this in any
formality,
> it's more like religion, and its utility is to improve comfort-to-deploy
in the
> organisation, it doesn't do much towards probability-of- success in my
mind.
> I've worked for companies who test not at all, companies who boot it in
the
> lab and companies who had a team doing just testing, and I can't say I've
> seen different amounts of TAC cases on software issues.
> 
> People who invest lot on testing, and are not comfortable with idea that
> value is just 'comfort-to-deploy' (that may be sufficiently important
value), I
> recommend looking at TAC cases you had which actually did cause customer
> outage, then try to evaluate 'was this reasonable to catch in the lab',
try to be
> honest.
> The problem I see, whole NOS quality is shit, it's not so shit that it's
always
> broken, the problems that manifest require usually more than one
condition,
> then if you start to do back-of-the-envelope math on testing everything
with
> every permutations, you will notice no amount of money can fix the fact
that
> you're limited by heat-death-of-universe on the wall clock. So now you're
> venturing into an area where you gotta choose, what to test and what not
to
> test, and you don't have nearly enough outages and faults to apply
statistical
> analysis on it, so you're actually just guessing.
> It's religion, which has some utility, but not the utility we think it
has.
> 
> 
> Note I'm not saying testing wholesale is useless, I'm more saying it has
an
> exponentially or worse diminishing return. I would say push 1 packet
through
> all your products in the lab, and you're done, you're as far as you're
> reasonably gonna get.
> And start thinking in terms 'the NOS is shit and I exercise no power over
it',
> what actions work in that world? Staging pop with real but outage
insensitive
> subscriptions?
> 
> 
Food for thoughts indeed,
With regards to the infinite amount of failure cases and inability to test
for all of these,
Actually the name of the game is "what is the minimum number of features you
can get away with while realizing all your business cases".  
so while the search space is infinite I'd say the graph starts with a big
and narrow peak followed by an infinitely long tail (x axes = number of all
possible failure cases, y axes= probability) 

Also testing can also be divided into functional, performance and scaling
testing.
So you take your minimum number of features you can get away with and
perform
(I advise to perform these as multidimensional testing -all features
combined) 

Functional testing
-to see if the features actually work as intended and work when combined 
-this is where you'll find some bugs and can adjust your feature-set
accordingly  (yes the search space still equals to infinity albeit smaller
infinity than complete search space containing all features)

Performance testing
-only related to HW/HW-related features
-to figure out your pps/bps rate head room -weird stuff happens if you cross
certain thresholds (this shields you from potential known and unknow failure
cases and bugs)

Scaling testing
-related to HW and SW resources of the box
-to figure out your features scale and derive your  head room -weird stuff
happens if you cross certain thresholds (this shields you from potential
known and unknow 

Re: [j-nsp] How to pick JUNOS Version

[Mark Tinka]

On 2/Sep/20 09:37, Saku Ytti wrote:

> How do people measure this? Vendors spend tens or hundreds millions
> annually on testing, and still deliver absolute trash NOS, to every
> vendor, and there is no change that I can observe +20 years in
> quality. Basic things are broken, and everyone finds new fundamental
> bugs all the time.
>
> I think NOS are shit, because shit NOS is a good business case and
> good NOS is a bad business case, I know it sounds outrageous, but let
> me explain. Vendor revenue is support contract, not HW sales. And a
> lot of us don't need help on configuring or troubleshooting, a lot of
> us have access to community which outperforms TAC on how to get that
> box working. But none of us has access to the code, we can't commit
> and push a fix. If the NOS would work, like Windows, Macos or Linux
> that you rarely find bugs, a lot of us would opt out from support
> contracts, and would just buy spare HW, destroying the vendor's
> business case.
>
> I don't think vendors sit in scary skull towers and plans for shit
> NOS, I think it's emergent behaviour from how the market is modelled.
> And there are ways I think the market could change, but I'm already
> venturing too far from the question to explore that topic.
>
>
>
> Now when it comes to testing, many claim it is important and it
> matters. I'm not convinced. And I don't think people are looking at
> this in any formality, it's more like religion, and its utility is to
> improve comfort-to-deploy in the organisation, it doesn't do much
> towards probability-of- success in my mind. I've worked for companies
> who test not at all, companies who boot it in the lab and companies
> who had a team doing just testing, and I can't say I've seen different
> amounts of TAC cases on software issues.
>
> People who invest lot on testing, and are not comfortable with idea
> that value is just 'comfort-to-deploy' (that may be sufficiently
> important value), I recommend looking at TAC cases you had which
> actually did cause customer outage, then try to evaluate 'was this
> reasonable to catch in the lab', try to be honest.
> The problem I see, whole NOS quality is shit, it's not so shit that
> it's always broken, the problems that manifest require usually more
> than one condition, then if you start to do back-of-the-envelope math
> on testing everything with every permutations, you will notice no
> amount of money can fix the fact that you're limited by
> heat-death-of-universe on the wall clock. So now you're venturing into
> an area where you gotta choose, what to test and what not to test, and
> you don't have nearly enough outages and faults to apply statistical
> analysis on it, so you're actually just guessing.
> It's religion, which has some utility, but not the utility we think it has.
>
>
> Note I'm not saying testing wholesale is useless, I'm more saying it
> has an exponentially or worse diminishing return. I would say push 1
> packet through all your products in the lab, and you're done, you're
> as far as you're reasonably gonna get.
> And start thinking in terms 'the NOS is shit and I exercise no power
> over it', what actions work in that world? Staging pop with real but
> outage insensitive subscriptions?

100% agreed with everything Saku said here.

As we age, we need to pick our battles, since what's real and important,
begins to reveal itself.

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[Jeffrey Haas via juniper-nsp]

--- Begin Message ---


> On Sep 2, 2020, at 3:37 AM, Saku Ytti  wrote:
> 
> I don't think vendors sit in scary skull towers and plans for shit
> NOS, I think it's emergent behaviour from how the market is modelled.
> And there are ways I think the market could change, but I'm already
> venturing too far from the question to explore that topic.

Speaking somewhat meta, it's an emergent property of the structure of the 
organization.  That's been true for my entire career, and not simply my current 
employer.

That said, scary skull towers would be quite a nice upgrade vs. our somewhat 
bland corporate presentation materials.

-- Jeff

--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[aaron1]

Thanks ytti

We still test drive a used car before purchasing, even though, the real test 
will be how it perform all day long up and down the highway...day after day.

Yeah I don't test at scale for pps, and load of any and every protocol.  Geez, 
that's a lot of testing.  I think IXIA and Spirent and others make test 
platforms to load up your box.  I don't do that currently, but have been at 
places that did.  The real test is out in the wild in the environment you put 
it in... and, as we know, with time, things change, and load changes, and 
results change.

I hear you though about your frustration with vendors putting out code that 
have issues.

-Aaron


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[aaron1]

Agreed.  I like your philosophy about network software upgrades. if you
don't absolutely need to, then don't.  I don't like to change my network if
it's running along just fine.

 

Another reason for upgrades is that a vendor is no longer going to work with
you because of EoS code.  I've had that happen to me, where the TAC won't
talk to you about something since your code is End of Support.

 

-Aaron

 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[Andrew Alston]

Saku,

I think for us - the testing we do is to validate against our own 
configurations and our own designs.  This is not done hand in hand with the 
vendor - it is done against what we use every day as a starting point - to give 
us some indication of where the trip points potentially are.

And you are 100% correct - the vendors spend huge amounts testing - but it is 
impossible for any vendor to test every scenario of every operator out there - 
which is why I advocate for operators to test against their specific needs - 
those tests can - and do - show up things occasionally that can be rectified.

That testing as I said - we do in our own labs - against our own templates - 
and our own methodologies - and its worked pretty well for us so far.

Andrew


-Original Message-
From: Saku Ytti  
Sent: Wednesday, 2 September 2020 10:37
To: Andrew Alston 
Cc: aar...@gvtc.com; Kody Vicknair ; Roger Wiklund 
; Colton Conor ; Juniper List 

Subject: Re: [j-nsp] How to pick JUNOS Version

On Wed, 2 Sep 2020 at 10:23, Andrew Alston  
wrote:

>   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

How do people measure this? Vendors spend tens or hundreds millions annually on 
testing, and still deliver absolute trash NOS, to every vendor, and there is no 
change that I can observe +20 years in quality. Basic things are broken, and 
everyone finds new fundamental bugs all the time.

I think NOS are shit, because shit NOS is a good business case and good NOS is 
a bad business case, I know it sounds outrageous, but let me explain. Vendor 
revenue is support contract, not HW sales. And a lot of us don't need help on 
configuring or troubleshooting, a lot of us have access to community which 
outperforms TAC on how to get that box working. But none of us has access to 
the code, we can't commit and push a fix. If the NOS would work, like Windows, 
Macos or Linux that you rarely find bugs, a lot of us would opt out from 
support contracts, and would just buy spare HW, destroying the vendor's 
business case.

I don't think vendors sit in scary skull towers and plans for shit NOS, I think 
it's emergent behaviour from how the market is modelled.
And there are ways I think the market could change, but I'm already venturing 
too far from the question to explore that topic.



Now when it comes to testing, many claim it is important and it matters. I'm 
not convinced. And I don't think people are looking at this in any formality, 
it's more like religion, and its utility is to improve comfort-to-deploy in the 
organisation, it doesn't do much towards probability-of- success in my mind. 
I've worked for companies who test not at all, companies who boot it in the lab 
and companies who had a team doing just testing, and I can't say I've seen 
different amounts of TAC cases on software issues.

People who invest lot on testing, and are not comfortable with idea that value 
is just 'comfort-to-deploy' (that may be sufficiently important value), I 
recommend looking at TAC cases you had which actually did cause customer 
outage, then try to evaluate 'was this reasonable to catch in the lab', try to 
be honest.
The problem I see, whole NOS quality is shit, it's not so shit that it's always 
broken, the problems that manifest require usually more than one condition, 
then if you start to do back-of-the-envelope math on testing everything with 
every permutations, you will notice no amount of money can fix the fact that 
you're limited by heat-death-of-universe on the wall clock. So now you're 
venturing into an area where you gotta choose, what to test and what not to 
test, and you don't have nearly enough outages and faults to apply statistical 
analysis on it, so you're actually just guessing.
It's religion, which has some utility, but not the utility we think it has.


Note I'm not saying testing wholesale is useless, I'm more saying it has an 
exponentially or worse diminishing return. I would say push 1 packet through 
all your products in the lab, and you're done, you're as far as you're 
reasonably gonna get.
And start thinking in terms 'the NOS is shit and I exercise no power over it', 
what actions work in that world? Staging pop with real but outage insensitive 
subscriptions?



--
  ++ytti

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[Saku Ytti]

On Wed, 2 Sep 2020 at 10:23, Andrew Alston
 wrote:

>   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

How do people measure this? Vendors spend tens or hundreds millions
annually on testing, and still deliver absolute trash NOS, to every
vendor, and there is no change that I can observe +20 years in
quality. Basic things are broken, and everyone finds new fundamental
bugs all the time.

I think NOS are shit, because shit NOS is a good business case and
good NOS is a bad business case, I know it sounds outrageous, but let
me explain. Vendor revenue is support contract, not HW sales. And a
lot of us don't need help on configuring or troubleshooting, a lot of
us have access to community which outperforms TAC on how to get that
box working. But none of us has access to the code, we can't commit
and push a fix. If the NOS would work, like Windows, Macos or Linux
that you rarely find bugs, a lot of us would opt out from support
contracts, and would just buy spare HW, destroying the vendor's
business case.

I don't think vendors sit in scary skull towers and plans for shit
NOS, I think it's emergent behaviour from how the market is modelled.
And there are ways I think the market could change, but I'm already
venturing too far from the question to explore that topic.



Now when it comes to testing, many claim it is important and it
matters. I'm not convinced. And I don't think people are looking at
this in any formality, it's more like religion, and its utility is to
improve comfort-to-deploy in the organisation, it doesn't do much
towards probability-of- success in my mind. I've worked for companies
who test not at all, companies who boot it in the lab and companies
who had a team doing just testing, and I can't say I've seen different
amounts of TAC cases on software issues.

People who invest lot on testing, and are not comfortable with idea
that value is just 'comfort-to-deploy' (that may be sufficiently
important value), I recommend looking at TAC cases you had which
actually did cause customer outage, then try to evaluate 'was this
reasonable to catch in the lab', try to be honest.
The problem I see, whole NOS quality is shit, it's not so shit that
it's always broken, the problems that manifest require usually more
than one condition, then if you start to do back-of-the-envelope math
on testing everything with every permutations, you will notice no
amount of money can fix the fact that you're limited by
heat-death-of-universe on the wall clock. So now you're venturing into
an area where you gotta choose, what to test and what not to test, and
you don't have nearly enough outages and faults to apply statistical
analysis on it, so you're actually just guessing.
It's religion, which has some utility, but not the utility we think it has.


Note I'm not saying testing wholesale is useless, I'm more saying it
has an exponentially or worse diminishing return. I would say push 1
packet through all your products in the lab, and you're done, you're
as far as you're reasonably gonna get.
And start thinking in terms 'the NOS is shit and I exercise no power
over it', what actions work in that world? Staging pop with real but
outage insensitive subscriptions?



-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [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  On Behalf Of 
aar...@gvtc.com
Sent: Wednesday, 2 September 2020 01:34
To: 'Kody Vicknair' ; 'Roger Wiklund' 
; 'Colton Conor' 
Cc: 'Juniper List' 
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.1X5417.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 juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp<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] How to pick JUNOS Version

[Kody Vicknair]

Aaron,

1. yes, I've seen this kb, but when I had someone I trust look at the diff, + 
the nature of the changes they were suggesting, I just wasn't comfortable 
making those changes. I personally avoided this at all cost. In my case, 
installs took about ~7 minutes per acx in a maintenance window and a majority 
of the routers are local, so it wasn't a big deal.

2. Not that I'm aware. I was including the caveat because for some reason 
during initial config we used vme.0 interfaces instead of em0.0 and I ran into 
issues with it not working properly in a lab setting and vme.0 was the gotcha 
for me.

By the way, I was seeing the same PR1419761 issues you are seeing, those have 
been resolved since upgrading.

-kv


-Original Message-
From: aar...@gvtc.com  
Sent: Wednesday, September 2, 2020 1:22 AM
To: Kody Vicknair ; 'Roger Wiklund' 
; 'Colton Conor' 
Cc: 'Juniper List' 
Subject: RE: [j-nsp] How to pick JUNOS Version

*External Email: Use Caution*

1 - 
https://link.edgepilot.com/s/6890e15f/hA34W4NyWUumQulQkNIdtw?u=https://kb.juniper.net/InfoCenter/index?page=content%26id=KB33988
(pretty sure that avoids the usb craziness, if memory serves me right, I think 
Juniper created that KB from my lab 5048 test back in March 2019. Now I'm 
wondering if I tried to go to like 15.x.D61 or something prior to trying to go 
to 17.3 if that would've helped)

2 - Virtual Chassis on an ACX5048?  Can you do that?

-Aaron

-Original Message-
From: Kody Vicknair 
Sent: Tuesday, September 1, 2020 7:52 PM
To: aar...@gvtc.com; 'Roger Wiklund' ; 'Colton Conor' 

Cc: 'Juniper List' 
Subject: RE: [j-nsp] How to pick JUNOS Version

1. I did a direct USB recovery format boot from 17.4r2-S11, and afterwards 
recovered configs from FTP. The reason for this was because 15.1x54D51 screws 
up your /tmp directory and you wont have enough free space no matter what you 
try. - at least, this was the case for my installs

2. One caveat of mgmt_junos routing-instance is you wont be able to utilize vme 
interfaces (so if you have a virtual chassis, it still won't work), to get 
around this I did the following:

set system management-instance
rename interfaces vme.0 to em0.0
set routing-instances mgmt_junos description "OOB Mgmt Instance"
set routing-instances mgmt_junos routing-options static route 0.0.0.0/0 
next-hop x.x.x.x set snmp interface em0.0 set snmp routing-instance-access set 
system ntp server x.x.x.x  routing-instance mgmt_junos set system ntp server 
x.x.x.x  routing-instance mgmt_junos

and deleted the static route for management out of the default inet.0 table

Goodluck!

-KV


-Original Message-
From: aar...@gvtc.com 
Sent: Tuesday, September 1, 2020 5:34 PM
To: Kody Vicknair ; 'Roger Wiklund'
; 'Colton Conor' 
Cc: 'Juniper List' 
Subject: RE: [j-nsp] How to pick JUNOS Version

*External Email: Use Caution*

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.1X5417.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: forwardingState: Active

-Aaron





Links contained in this email have been replaced. If you click on a link in the 
email above, the link will be analyzed for known threats. If a known threat is 
found, you will not be able to proceed to the destination. If suspicious 
content is detected, you will see a warning.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[aaron1]

1 - https://kb.juniper.net/InfoCenter/index?page=content=KB33988
(pretty sure that avoids the usb craziness, if memory serves me right, I
think Juniper created that KB from my lab 5048 test back in March 2019. Now
I'm wondering if I tried to go to like 15.x.D61 or something prior to trying
to go to 17.3 if that would've helped)

2 - Virtual Chassis on an ACX5048?  Can you do that?

-Aaron

-Original Message-
From: Kody Vicknair  
Sent: Tuesday, September 1, 2020 7:52 PM
To: aar...@gvtc.com; 'Roger Wiklund' ; 'Colton
Conor' 
Cc: 'Juniper List' 
Subject: RE: [j-nsp] How to pick JUNOS Version

1. I did a direct USB recovery format boot from 17.4r2-S11, and afterwards
recovered configs from FTP. The reason for this was because 15.1x54D51
screws up your /tmp directory and you wont have enough free space no matter
what you try. - at least, this was the case for my installs

2. One caveat of mgmt_junos routing-instance is you wont be able to utilize
vme interfaces (so if you have a virtual chassis, it still won't work), to
get around this I did the following:

set system management-instance
rename interfaces vme.0 to em0.0
set routing-instances mgmt_junos description "OOB Mgmt Instance"
set routing-instances mgmt_junos routing-options static route 0.0.0.0/0
next-hop x.x.x.x set snmp interface em0.0 set snmp routing-instance-access
set system ntp server x.x.x.x  routing-instance mgmt_junos set system ntp
server x.x.x.x  routing-instance mgmt_junos

and deleted the static route for management out of the default inet.0 table

Goodluck!

-KV


-Original Message-
From: aar...@gvtc.com 
Sent: Tuesday, September 1, 2020 5:34 PM
To: Kody Vicknair ; 'Roger Wiklund'
; 'Colton Conor' 
Cc: 'Juniper List' 
Subject: RE: [j-nsp] How to pick JUNOS Version

*External Email: Use Caution*

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.1X5417.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: forwardingState: Active

-Aaron



___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[Kody Vicknair]

1. I did a direct USB recovery format boot from 17.4r2-S11, and afterwards 
recovered configs from FTP. The reason for this was because 15.1x54D51 screws 
up your /tmp directory and you wont have enough free space no matter what you 
try. - at least, this was the case for my installs

2. One caveat of mgmt_junos routing-instance is you wont be able to utilize vme 
interfaces (so if you have a virtual chassis, it still won't work), to get 
around this I did the following:

set system management-instance
rename interfaces vme.0 to em0.0
set routing-instances mgmt_junos description "OOB Mgmt Instance"
set routing-instances mgmt_junos routing-options static route 0.0.0.0/0 
next-hop x.x.x.x
set snmp interface em0.0
set snmp routing-instance-access
set system ntp server x.x.x.x  routing-instance mgmt_junos
set system ntp server x.x.x.x  routing-instance mgmt_junos

and deleted the static route for management out of the default inet.0 table

Goodluck!

-KV


-Original Message-
From: aar...@gvtc.com  
Sent: Tuesday, September 1, 2020 5:34 PM
To: Kody Vicknair ; 'Roger Wiklund' 
; 'Colton Conor' 
Cc: 'Juniper List' 
Subject: RE: [j-nsp] How to pick JUNOS Version

*External Email: Use Caution*

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.1X5417.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: forwardingState: Active

-Aaron


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[aaron1]

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.1X5417.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: forwardingState: Active

-Aaron


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[Kody Vicknair]

Recently upgraded all my edges from 15.1x54D51 to 17.4R2-S11. 

The upgrade was forced by strange transit ARP packet digestion in vpls 
instances... 
Thoroughly tested in my lab prior to deployment. 

It is finally nice to gain a dedicated oob mgmt routing-instance How long 
have we been requesting this?

-KV


-Original Message-
From: juniper-nsp  On Behalf Of 
aar...@gvtc.com
Sent: Tuesday, September 1, 2020 3:17 PM
To: 'Roger Wiklund' ; 'Colton Conor' 

Cc: 'Juniper List' 
Subject: Re: [j-nsp] How to pick JUNOS Version

*External Email: Use Caution*

Amen to that.  I recall a few years back, going with 15.1X54-D51.7 for the
ACX5048 and having complete outage on irb's in L3VPN's with no dhcp relay (ip 
helper) capability.  ...and being baffled as I recall that the D51 version was 
on the JTAC recommended list.  (D61 fixed it) So yeah, I agree with Roger, do 
your testing and verification of your things you need to make work in your 
network environment prior to rolling it out if at all possible.

-Aaron


___
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] How to pick JUNOS Version

[aaron1]

Amen to that.  I recall a few years back, going with 15.1X54-D51.7 for the
ACX5048 and having complete outage on irb's in L3VPN's with no dhcp relay
(ip helper) capability.  ...and being baffled as I recall that the D51
version was on the JTAC recommended list.  (D61 fixed it) So yeah, I agree
with Roger, do your testing and verification of your things you need to make
work in your network environment prior to rolling it out if at all possible.

-Aaron 


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[Mark Tinka]

On 21/Aug/20 00:54, Giuliano C. Medalha wrote:

> ACX710 was officially launched this week.
>
> We are very excited about this new product. Working hard to have the right 
> features for our market, especially H-QOS and FAT-PW quickly.
>
> In addition to this box has great cost benefit.
>
> They are in the right way.  Finally.

Not quite.

The lack of AC support on this box is a real travesty. Then again, I
understand why, so...

I also wouldn't count my chickens yet as it's a Jericho 2 box. So plenty
of testing before you sign the contract.

Mark.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[Mark Tinka]

On 21/Aug/20 00:54, Giuliano C. Medalha wrote:

> ACX710 was officially launched this week.
>
> We are very excited about this new product. Working hard to have the right 
> features for our market, especially H-QOS and FAT-PW quickly.
>
> In addition to this box has great cost benefit.
>
> They are in the right way.  Finally.

Not quite.

The lack of AC support on this box is a real travesty. Then again, I
understand why, so...

I also wouldn't count my chickens yet as it's a Jericho 2 box. So plenty
of testing before you sign on contract.

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[Giuliano C. Medalha]

Good evening everyone

We have had some good experiences with the QFX5120-32C as a P router with MPLS 
( 32 x 100G ) . It is running well on several clients in the last few days.

We had some problems with the initial code, mainly in network convergence and 
null traffic in already formed tunnels, but this has already been solved in 
19.4R2-S1.

The 19.4R3 will be released on 08/27/2020  ( forecast ) and should encompass 
all these corrections and become a very stable release for this specific 
function.

JUNIPER engineering (MX, PTX and QFX) has helped us a lot with the development 
of new features and bug fixes.

ACX710 was officially launched this week.

We are very excited about this new product. Working hard to have the right 
features for our market, especially H-QOS and FAT-PW quickly.

In addition to this box has great cost benefit.

They are in the right way.  Finally.

Att

Giuliano


WZTECH is registered trademark of WZTECH NETWORKS.
Copyright © 2018 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informações deste e-mail e o conteúdo dos eventuais documentos anexos são 
confidenciais e para conhecimento exclusivo do destinatário. Se o leitor desta 
mensagem não for o seu destinatário, fica desde já notificado de que não poderá 
divulgar, distribuir ou, sob qualquer forma, dar conhecimento a terceiros das 
informações e do conteúdo dos documentos anexos. Neste caso, favor comunicar 
imediatamente o remetente, respondendo este e-mail ou telefonando ao mesmo, e 
em seguida apague-o.

CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are 
solely for the intended recipient and may contain confidential or privileged 
information. If you are not the intended recipient, any review, transmission, 
dissemination or other use of this information is prohibited. If you have 
received this communication in error, please notify the sender immediately and 
delete the material from any computer, including any copies.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[Nelson, Brian]

-Original Message-
From: juniper-nsp  On Behalf Of Mark Tinka
Sent: Thursday, August 20, 2020 11:38 AM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] How to pick JUNOS Version
it will be a reminder of what happened when Juniper went from JUNOS 8, and a 
bit of 9, to Junos 10 and where we are today :-).

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/juniper-nsp

I see the reminder everyday of those past growing pains in the pains of 
16,17,18.
Same Stuff, Different Day 

Brian Nelson
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[Mark Tinka]

On 20/Aug/20 15:33, Alexandre Guimaraes wrote:

> The best answer ever!
>
> Go to Vegas, in a Cassino, play some roulette.  Wait for a number between 10 
> and 20, if black, normal Junos, if red, SR Junos...  if you lose all money 
> before get a code similar a release, follow Tom Beecher schemas.
>
> IT'S A LOTTERY to pick a junos release. 

Like on the PTX1000's we are getting, we'll go straight to Junos 20
because... why not?

If we hit issues along the way, we'll review.

If we don't, happy days.

It does help that these are core boxes, so...

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[Mark Tinka]

On 19/Aug/20 18:03, John Kristoff wrote:

> I'm not sure it is worth the time invested, but I'm probably a rare
> breed that reads through release notes and tries to determine what I'm
> in for or what I may have to change for an install or upgrade.  It is
> very time consuming, but has been helpful a few times for things I
> would have otherwise been unprepared for.  Here is an old of example of
> the sort of thing I've done:

I do it less these days since I have minions, but yes, this is a tried &
tested part of network operations.

Since we are deploying PTX1000's soon, that's the first time I've read
(Junos 20) release notes to that degree since Junos 14 back in 2014 :-).

Mark.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[Mark Tinka]

On 19/Aug/20 17:12, Roger Wiklund wrote:

> I'm not sure how long Arista can keep the single binary approach as they
> expand their portfolio
> and feature set. For example it makes very little sense to have full BNG
> code on EX access switches, imge would be huge.

We've seen this play before. It's a matter of time.


> As for JTAC recommended release, it's a very generic recommendation not
> taking specific use cases into consideration (Except for EVPN-VXLAN CRB/ERB)
> Typically Juniper considers R3 releases to be mainstream adoptable (reality
> is more like R3-S) but you will sleep better if you do proper
> testing and to avoid regression bugs etc.
>
> You can always ask your friendly SE for some guidance.

I've generally only chosen specific code because it has a new feature I
want, and then I stick with it until I can't any longer, typically due
to it not having extended support.

The other reason to choose code is because, well, you have no choice,
e.g., they release an MPC20E line card that mandates the use of Junos
43. Take it or leave it.

If I'm happy with the features I have, I won't look at other code unless
it introduces a new feature I need, or it receives no more love from
Juniper.

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[Mark Tinka]

On 19/Aug/20 17:00, Saku Ytti wrote:

> For the longest time Juniper pretended they had a single Junos,
> because they didn't have a large enough portfolio to justify anything
> else. Of course at very early of that marketing pitch the single image
> already included multiple images for different targets.
> Anyone could do this, anyone could ship fat tgz which contains
> everything, at some point it becomes less than sensible.
>
> ANET is already pretending there is a single image, due to transition
> to 64b and over time entropy increases for them too.

Completely agreed.

The vendors can't sustain a single market portfolio any longer. Either
they fork, or they acquire some company and still fork.

Times are hard.

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[Mark Tinka]

On 19/Aug/20 16:42, Colton Conor wrote:

> Just wondering if JUNOS will ever go to a unified code model like Arista
> does? The amount of PR's and bug issues in JUNOS seems overwhelming. Is
> this standard across vendors? I am impressed that Juniper takes the times
> to keep track of all these issues, but I am unimpressed that there are this
> many bugs.

It's only going to get worse.

Personally, I don't mind a little bit of forking. I don't want bugs due
to BNG features because it's all one Junos.

Arista's portfolio is still simplistic because the main target market is
data centre switching. Wait when their code gets up to scratch re:
IP/MPLS, and it will be a reminder of what happened when Juniper went
from JUNOS 8, and a bit of 9, to Junos 10 and where we are today :-).

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[Christian Scholz via juniper-nsp]

--- Begin Message ---
If you face issues, you have JTAC, ATAC, and Engineering - and also a local SE.
I would never wait and "hope" that a fix will be out there because it has been 
reported, "by someone else."
Observe, Pinpoint, Report and if needed Escalate - works very good with Juniper 
and they help you; unlike other vendors who "build bridges" and tell you to 
deploy your software while Saturn is in line with Mars and while offering a 
goat as a token of appreciation at the same time 
If there is a nasty issue that is not fixed in any release, Engineering 
provides "Special Customer Releases" to have a fix for your particular 
environment and issue to help you.
Therefore if you report the Bug, you might not have a fix tomorrow, but in the 
next 2-3 months.
And if it takes longer, there's an "escalate this case" button that works very 
well - I never had to wait longer than six weeks for a particular fix after it 
had been confirmed. Your local SE can also assist you if you have trouble.


Back to the topic:
If you start fresh, follow the "JTAC versions to consider" (as stated earlier, 
it's no longer called recommended for various reasons) and ask your local SE - 
that's the "official" way. 
In 9/10 Cases, this is an excellent version to start with if you have no idea 
where to start at all.
If you need a specific feature that's not yet in the "version to consider," or 
there's a bug in this version affecting you, your local SE can tell you what to 
do and what version to try.
This way, you get a working version or the correct pointers on what to do to 
get the right version.

Tom's approach is also an excellent idea - the important part is that you test 
everything for your environment yourself before deploying it to prod. Most of 
the time, "shit hits the fan" because folks don't check appropriately for 
themselves or have no testing environment at all because "it's expensive."
In my personal opinion, it's not the vendor's responsibility to test every 
customer topology in existence with every tiny feature.
It's your job at the end of the day to make sure that you deploy code that 
works. 
The vendor can assist you as best as possible, but it's simply not possible for 
them to test EVERY scenario out there.
Again: Observe, Pinpoint, Report.

Yes - there are often multiple bugs involved, and yes it can be a "Minesweeper 
Game" to find the one that has "everything" fixed (however, such thing does not 
exist per definition because humans are not perfect) - but it's not as 
complicated as with other vendors with 27.000 Releases and Sub-Releases out 
there that have to be "qualified" in order to get support 

Just my 2ct

-- Christian






-Ursprüngliche Nachricht-
Von: juniper-nsp  Im Auftrag von Alexandre 
Guimaraes
Gesendet: Donnerstag, 20. August 2020 15:34
An: Tom Beecher ; Colton Conor 
Cc: Juniper List 
Betreff: Re: [j-nsp] How to pick JUNOS Version

The best answer ever!

Go to Vegas, in a Cassino, play some roulette.  Wait for a number between 10 
and 20, if black, normal Junos, if red, SR Junos...  if you lose all money 
before get a code similar a release, follow Tom Beecher schemas.

IT'S A LOTTERY to pick a junos release. 

One of my case
I have deployed some QFX5120 32C and 48Y units a year ago, exactly Aug/2019, 
until today, those units are offline and waiting a code that’s fix 
RSVP/ISIS/MPLS signalization until there, wasted money, etc



Em 19/08/2020 13:32, "juniper-nsp em nome de Tom Beecher" 
 escreveu:

Start with the highest code version supported on the hardware that has all
the features you need.
Subtract 2 from the major revision number.
Pick a .3 version of that major revision.
Work towards current from there depending on test results, security needs,
etc.

On Wed, Aug 19, 2020 at 10:47 AM Colton Conor 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__colton.conor-40gmail.com=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s=a6BNdZOtIAqYpPvwVFnIF4E-D-PQw3QGn-NmT5hFQag=vCQMfrWksdsBnD7JU0aeeHZARhmdT9KC6Caf59B_xgc=>
wrote:

> How do you plan which JUNOS version to deploy on your network? Do you 
stick
> to the KB21476 - JTAC Recommended Junos Software Versions or go a 
different
> route? Some of the JTAC recommended code seems to be very dated, but that
> is probably by design for stability.
>
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__kb.juniper.net_InfoCenter_index-3Fpage-3Dcontent-26id-3DKB21476-26actp-3DMETADATA=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s=a6BNdZOtIAqYpPvwVFnIF4E-D-PQw3QGn-NmT5hFQag=CQxemDO4grDS8J_BXAGPC3akSwvKhy2DBPt6JlKN3nI=
>
> Just wondering if JUNOS will ever go to a unified code model

Re: [j-nsp] How to pick JUNOS Version

[Alexandre Guimaraes]

The best answer ever!

Go to Vegas, in a Cassino, play some roulette.  Wait for a number between 10 
and 20, if black, normal Junos, if red, SR Junos...  if you lose all money 
before get a code similar a release, follow Tom Beecher schemas.

IT'S A LOTTERY to pick a junos release. 

One of my case
I have deployed some QFX5120 32C and 48Y units a year ago, exactly Aug/2019, 
until today, those units are offline and waiting a code that’s fix 
RSVP/ISIS/MPLS signalization until there, wasted money, etc



Em 19/08/2020 13:32, "juniper-nsp em nome de Tom Beecher" 
 escreveu:

Start with the highest code version supported on the hardware that has all
the features you need.
Subtract 2 from the major revision number.
Pick a .3 version of that major revision.
Work towards current from there depending on test results, security needs,
etc.

On Wed, Aug 19, 2020 at 10:47 AM Colton Conor 

wrote:

> How do you plan which JUNOS version to deploy on your network? Do you 
stick
> to the KB21476 - JTAC Recommended Junos Software Versions or go a 
different
> route? Some of the JTAC recommended code seems to be very dated, but that
> is probably by design for stability.
>
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__kb.juniper.net_InfoCenter_index-3Fpage-3Dcontent-26id-3DKB21476-26actp-3DMETADATA=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s=a6BNdZOtIAqYpPvwVFnIF4E-D-PQw3QGn-NmT5hFQag=CQxemDO4grDS8J_BXAGPC3akSwvKhy2DBPt6JlKN3nI=
>
> Just wondering if JUNOS will ever go to a unified code model like Arista
> does? The amount of PR's and bug issues in JUNOS seems overwhelming. Is
> this standard across vendors? I am impressed that Juniper takes the times
> to keep track of all these issues, but I am unimpressed that there are 
this
> many bugs.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s=a6BNdZOtIAqYpPvwVFnIF4E-D-PQw3QGn-NmT5hFQag=Iqvqv8RodZ2aLfF-aEkPbJ91Yia6VG08ywJkfB-UwYo=
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net

https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s=a6BNdZOtIAqYpPvwVFnIF4E-D-PQw3QGn-NmT5hFQag=Iqvqv8RodZ2aLfF-aEkPbJ91Yia6VG08ywJkfB-UwYo=

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[Chris Adams]

Once upon a time, John Kristoff  said:
> I bet there is a generation of people on this list that never saw the
> cartoons Juniper ran in it's early days.  There were probably some that
> weren't a dig at Cisco, but this was pretty representative as I recall.

I think I still have my deck of Juniper playing cards somewhere.
-- 
Chris Adams 
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[Luca Salvatore]

Let’s be real... this is how to pick a new Junos version
https://fuckingjuniper.com/dice.gif

On Wed, Aug 19, 2020 at 12:32 PM Tom Beecher  wrote:

> Start with the highest code version supported on the hardware that has all
>
> the features you need.
>
> Subtract 2 from the major revision number.
>
> Pick a .3 version of that major revision.
>
> Work towards current from there depending on test results, security needs,
>
> etc.
>
>
>
> On Wed, Aug 19, 2020 at 10:47 AM Colton Conor 
>
> wrote:
>
>
>
> > How do you plan which JUNOS version to deploy on your network? Do you
> stick
>
> > to the KB21476 - JTAC Recommended Junos Software Versions or go a
> different
>
> > route? Some of the JTAC recommended code seems to be very dated, but that
>
> > is probably by design for stability.
>
> >
>
> >
> https://kb.juniper.net/InfoCenter/index?page=content=KB21476=METADATA
>
> >
>
> > Just wondering if JUNOS will ever go to a unified code model like Arista
>
> > does? The amount of PR's and bug issues in JUNOS seems overwhelming. Is
>
> > this standard across vendors? I am impressed that Juniper takes the times
>
> > to keep track of all these issues, but I am unimpressed that there are
> this
>
> > many bugs.
>
> > ___
>
> > 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] How to pick JUNOS Version

[Tom Beecher]

Start with the highest code version supported on the hardware that has all
the features you need.
Subtract 2 from the major revision number.
Pick a .3 version of that major revision.
Work towards current from there depending on test results, security needs,
etc.

On Wed, Aug 19, 2020 at 10:47 AM Colton Conor 
wrote:

> How do you plan which JUNOS version to deploy on your network? Do you stick
> to the KB21476 - JTAC Recommended Junos Software Versions or go a different
> route? Some of the JTAC recommended code seems to be very dated, but that
> is probably by design for stability.
>
> https://kb.juniper.net/InfoCenter/index?page=content=KB21476=METADATA
>
> Just wondering if JUNOS will ever go to a unified code model like Arista
> does? The amount of PR's and bug issues in JUNOS seems overwhelming. Is
> this standard across vendors? I am impressed that Juniper takes the times
> to keep track of all these issues, but I am unimpressed that there are this
> many bugs.
> ___
> 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] How to pick JUNOS Version

[John Kristoff]

On Wed, 19 Aug 2020 14:42:32 +
Colton Conor  wrote:

> How do you plan which JUNOS version to deploy on your network? Do you stick
> to the KB21476 - JTAC Recommended Junos Software Versions or go a different
> route?

I've occasionally got some good advice from bigger operators who often
have significantly more testing and deployment experience than I,
Although their concerns are often incongruent to mine, since we are apt
to rely on a very different set of interfaces, services, and features.
Just hearing something like "do not use version X because Y, or we're on
version Z" can be helpful.  Maybe just ask on this list what version
people are using or have had problems with before deciding?  Not very
scientific, but seems like a fair use of the list.

I'm not sure it is worth the time invested, but I'm probably a rare
breed that reads through release notes and tries to determine what I'm
in for or what I may have to change for an install or upgrade.  It is
very time consuming, but has been helpful a few times for things I
would have otherwise been unprepared for.  Here is an old of example of
the sort of thing I've done:

  

John
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[Andrey Kostin]

Agree with Rx-S and with reasonably conservative approach, 
 should be >= 3. In S1, S2 you will probably get PR fixes 
affecting multiple previous releases but for a new R-specific PRs it 
takes time to be discovered and fixes implemented, which usually takes 
not less than 6 months. Also you may take into consideration that last 
releases in a train usually have longer support period.


Kind regards,
Andrey

Roger Wiklund писал 2020-08-19 11:12:
I'm not sure how long Arista can keep the single binary approach as 
they

expand their portfolio
and feature set. For example it makes very little sense to have full 
BNG

code on EX access switches, imge would be huge.

As for JTAC recommended release, it's a very generic recommendation not
taking specific use cases into consideration (Except for EVPN-VXLAN 
CRB/ERB)
Typically Juniper considers R3 releases to be mainstream adoptable 
(reality

is more like R3-S) but you will sleep better if you do proper
testing and to avoid regression bugs etc.

You can always ask your friendly SE for some guidance.

/Roger


On Wed, Aug 19, 2020 at 4:46 PM Colton Conor  
wrote:


How do you plan which JUNOS version to deploy on your network? Do you 
stick
to the KB21476 - JTAC Recommended Junos Software Versions or go a 
different
route? Some of the JTAC recommended code seems to be very dated, but 
that

is probably by design for stability.

https://kb.juniper.net/InfoCenter/index?page=content=KB21476=METADATA

Just wondering if JUNOS will ever go to a unified code model like 
Arista
does? The amount of PR's and bug issues in JUNOS seems overwhelming. 
Is
this standard across vendors? I am impressed that Juniper takes the 
times
to keep track of all these issues, but I am unimpressed that there are 
this

many bugs.
___
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] How to pick JUNOS Version

[Tobias Heister]

Hi,

On 19.08.2020 16:42, Colton Conor wrote:

How do you plan which JUNOS version to deploy on your network? Do you stick
to the KB21476 - JTAC Recommended Junos Software Versions or go a different
route? Some of the JTAC recommended code seems to be very dated, but that
is probably by design for stability.
https://kb.juniper.net/InfoCenter/index?page=content=KB21476=METADATA


just for the record (some of you will already know) ... there is no longer a 
recommended release.
The Article was renamed: "Suggested Releases to Consider and Evaluate"

For any real recommendation you would have to buy a service which analyzes you 
configs and cross checks PRs.

But in reality nothing much has changed, even before the rename the 
recommendation was not very strong anyway, just a general guideline.

--
Kind Regards
Tobias Heister
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to pick JUNOS Version

[Roger Wiklund]

I'm not sure how long Arista can keep the single binary approach as they
expand their portfolio
and feature set. For example it makes very little sense to have full BNG
code on EX access switches, imge would be huge.

As for JTAC recommended release, it's a very generic recommendation not
taking specific use cases into consideration (Except for EVPN-VXLAN CRB/ERB)
Typically Juniper considers R3 releases to be mainstream adoptable (reality
is more like R3-S) but you will sleep better if you do proper
testing and to avoid regression bugs etc.

You can always ask your friendly SE for some guidance.

/Roger


On Wed, Aug 19, 2020 at 4:46 PM Colton Conor  wrote:

> How do you plan which JUNOS version to deploy on your network? Do you stick
> to the KB21476 - JTAC Recommended Junos Software Versions or go a different
> route? Some of the JTAC recommended code seems to be very dated, but that
> is probably by design for stability.
>
> https://kb.juniper.net/InfoCenter/index?page=content=KB21476=METADATA
>
> Just wondering if JUNOS will ever go to a unified code model like Arista
> does? The amount of PR's and bug issues in JUNOS seems overwhelming. Is
> this standard across vendors? I am impressed that Juniper takes the times
> to keep track of all these issues, but I am unimpressed that there are this
> many bugs.
> ___
> 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] How to pick JUNOS Version

[Saku Ytti]

On Wed, 19 Aug 2020 at 17:47, Colton Conor  wrote:

> Just wondering if JUNOS will ever go to a unified code model like Arista
> does? The amount of PR's and bug issues in JUNOS seems overwhelming. Is

For the longest time Juniper pretended they had a single Junos,
because they didn't have a large enough portfolio to justify anything
else. Of course at very early of that marketing pitch the single image
already included multiple images for different targets.
Anyone could do this, anyone could ship fat tgz which contains
everything, at some point it becomes less than sensible.

ANET is already pretending there is a single image, due to transition
to 64b and over time entropy increases for them too.

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp