Mailing List Archive

How to pick JUNOS Version
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&id=KB21476&actp=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
Re: How to pick JUNOS Version [ In reply to ]
On Wed, 19 Aug 2020 at 17:47, Colton Conor <colton.conor@gmail.com> 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
Re: How to pick JUNOS Version [ In reply to ]
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<latest>) 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 <colton.conor@gmail.com> 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&id=KB21476&actp=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: How to pick JUNOS Version [ In reply to ]
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&id=KB21476&actp=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: How to pick JUNOS Version [ In reply to ]
Agree with Rx-S<latest> and with reasonably conservative approach,
<latest> 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<latest>) 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 <colton.conor@gmail.com>
> 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&id=KB21476&actp=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: How to pick JUNOS Version [ In reply to ]
On Wed, 19 Aug 2020 14:42:32 +0000
Colton Conor <colton.conor@gmail.com> 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:

<https://github.com/jtkristoff/junos/blob/master/upgrade.template.txt>

John
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: How to pick JUNOS Version [ In reply to ]
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 <colton.conor@gmail.com>
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&id=KB21476&actp=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: How to pick JUNOS Version [ In reply to ]
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 <beecher@beecher.cc> 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 <colton.conor@gmail.com>
>
> 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&id=KB21476&actp=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: How to pick JUNOS Version [ In reply to ]
On Thu, 20 Aug 2020 02:23:31 +0000
Luca Salvatore <lucasalvatore@gmail.com> wrote:

> Let’s be real... this is how to pick a new Junos version

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.

<http://2.bp.blogspot.com/_bZ7EhbBrv3Q/SX2Da35TlKI/AAAAAAAAAEA/tMVxs88v3G8/s1600-h/juniper-03.gif>

John
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: How to pick JUNOS Version [ In reply to ]
Once upon a time, John Kristoff <jtk@depaul.edu> 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 <cma@cmadams.net>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: How to pick JUNOS Version [ In reply to ]
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" <juniper-nsp-bounces@puck.nether.net em nome de beecher@beecher.cc> 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&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s&m=a6BNdZOtIAqYpPvwVFnIF4E-D-PQw3QGn-NmT5hFQag&s=vCQMfrWksdsBnD7JU0aeeHZARhmdT9KC6Caf59B_xgc&e=>
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&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s&m=a6BNdZOtIAqYpPvwVFnIF4E-D-PQw3QGn-NmT5hFQag&s=CQxemDO4grDS8J_BXAGPC3akSwvKhy2DBPt6JlKN3nI&e=
>
> 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&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s&m=a6BNdZOtIAqYpPvwVFnIF4E-D-PQw3QGn-NmT5hFQag&s=Iqvqv8RodZ2aLfF-aEkPbJ91Yia6VG08ywJkfB-UwYo&e=
>
_______________________________________________
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&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s&m=a6BNdZOtIAqYpPvwVFnIF4E-D-PQw3QGn-NmT5hFQag&s=Iqvqv8RodZ2aLfF-aEkPbJ91Yia6VG08ywJkfB-UwYo&e=

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: How to pick JUNOS Version [ In reply to ]
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: How to pick JUNOS Version [ In reply to ]
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: How to pick JUNOS Version [ In reply to ]
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: How to pick JUNOS Version [ In reply to ]
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<latest>) 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: How to pick JUNOS Version [ In reply to ]
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: How to pick JUNOS Version [ In reply to ]
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: How to pick JUNOS Version [ In reply to ]
-----Original Message-----
From: juniper-nsp <juniper-nsp-bounces@puck.nether.net> 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: How to pick JUNOS Version [ In reply to ]
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: How to pick JUNOS Version [ In reply to ]
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: How to pick JUNOS Version [ In reply to ]
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: How to pick JUNOS Version [ In reply to ]
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: How to pick JUNOS Version [ In reply to ]
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 <juniper-nsp-bounces@puck.nether.net> On Behalf Of aaron1@gvtc.com
Sent: Tuesday, September 1, 2020 3:17 PM
To: 'Roger Wiklund' <roger.wiklund@gmail.com>; 'Colton Conor' <colton.conor@gmail.com>
Cc: 'Juniper List' <juniper-nsp@puck.nether.net>
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: How to pick JUNOS Version [ In reply to ]
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 juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: How to pick JUNOS Version [ In reply to ]
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: aaron1@gvtc.com <aaron1@gvtc.com>
Sent: Tuesday, September 1, 2020 5:34 PM
To: Kody Vicknair <kvicknair@reservetele.com>; 'Roger Wiklund' <roger.wiklund@gmail.com>; 'Colton Conor' <colton.conor@gmail.com>
Cc: 'Juniper List' <juniper-nsp@puck.nether.net>
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.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 juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: How to pick JUNOS Version [ In reply to ]
1 - https://kb.juniper.net/InfoCenter/index?page=content&id=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 <kvicknair@reservetele.com>
Sent: Tuesday, September 1, 2020 7:52 PM
To: aaron1@gvtc.com; 'Roger Wiklund' <roger.wiklund@gmail.com>; 'Colton
Conor' <colton.conor@gmail.com>
Cc: 'Juniper List' <juniper-nsp@puck.nether.net>
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: aaron1@gvtc.com <aaron1@gvtc.com>
Sent: Tuesday, September 1, 2020 5:34 PM
To: Kody Vicknair <kvicknair@reservetele.com>; 'Roger Wiklund'
<roger.wiklund@gmail.com>; 'Colton Conor' <colton.conor@gmail.com>
Cc: 'Juniper List' <juniper-nsp@puck.nether.net>
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.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 juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: How to pick JUNOS Version [ In reply to ]
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: aaron1@gvtc.com <aaron1@gvtc.com>
Sent: Wednesday, September 2, 2020 1:22 AM
To: Kody Vicknair <kvicknair@reservetele.com>; 'Roger Wiklund' <roger.wiklund@gmail.com>; 'Colton Conor' <colton.conor@gmail.com>
Cc: 'Juniper List' <juniper-nsp@puck.nether.net>
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 <kvicknair@reservetele.com>
Sent: Tuesday, September 1, 2020 7:52 PM
To: aaron1@gvtc.com; 'Roger Wiklund' <roger.wiklund@gmail.com>; 'Colton Conor' <colton.conor@gmail.com>
Cc: 'Juniper List' <juniper-nsp@puck.nether.net>
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: aaron1@gvtc.com <aaron1@gvtc.com>
Sent: Tuesday, September 1, 2020 5:34 PM
To: Kody Vicknair <kvicknair@reservetele.com>; 'Roger Wiklund'
<roger.wiklund@gmail.com>; 'Colton Conor' <colton.conor@gmail.com>
Cc: 'Juniper List' <juniper-nsp@puck.nether.net>
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.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





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: How to pick JUNOS Version [ In reply to ]
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@puck.nether.net> On Behalf Of aaron1@gvtc.com
Sent: Wednesday, 2 September 2020 01:34
To: 'Kody Vicknair' <kvicknair@reservetele.com>; 'Roger Wiklund' <roger.wiklund@gmail.com>; 'Colton Conor' <colton.conor@gmail.com>
Cc: 'Juniper List' <juniper-nsp@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@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: How to pick JUNOS Version [ In reply to ]
On Wed, 2 Sep 2020 at 10:23, Andrew Alston
<Andrew.Alston@liquidtelecom.com> 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: How to pick JUNOS Version [ In reply to ]
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 <saku@ytti.fi>
Sent: Wednesday, 2 September 2020 10:37
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>
Cc: aaron1@gvtc.com; Kody Vicknair <kvicknair@reservetele.com>; Roger Wiklund <roger.wiklund@gmail.com>; Colton Conor <colton.conor@gmail.com>; Juniper List <juniper-nsp@puck.nether.net>
Subject: Re: [j-nsp] How to pick JUNOS Version

On Wed, 2 Sep 2020 at 10:23, Andrew Alston <Andrew.Alston@liquidtelecom.com> 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: How to pick JUNOS Version [ In reply to ]
Thanks KV, also, if you just wanted to clear that high cpu thing, you can do this...

show system processes extensive | except 0.0

* get the process ID of the fxpc hogging process...in this case it's 1820

me@acx5048> show system processes extensive | except 0.0
last pid: 7231; load averages: 0.89, 0.93, 0.91 up 516+22:09:03 23:07:23
144 processes: 5 running, 118 sleeping, 21 waiting

Mem: 625M Active, 296M Inact, 471M Wired, 425M Cache, 69M Buf, 32M Free
Swap:

PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND
1820 root 2 -51 -51 1185M 501M select ??? 96.97% fxpc

* NOTE, when you hit enter on the KILL command, cursor may continue to blink, and you might think it didn't take your input, but it did... pings will start to die

start shell user root
(enter root pwd)

kill -9 1820

-Aaron


-----Original Message-----
From: Kody Vicknair <kvicknair@reservetele.com>
Sent: Wednesday, September 2, 2020 2:08 AM
To: aaron1@gvtc.com; 'Roger Wiklund' <roger.wiklund@gmail.com>; 'Colton Conor' <colton.conor@gmail.com>
Cc: 'Juniper List' <juniper-nsp@puck.nether.net>
Subject: RE: [j-nsp] How to pick JUNOS Version

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: aaron1@gvtc.com <aaron1@gvtc.com>
Sent: Wednesday, September 2, 2020 1:22 AM
To: Kody Vicknair <kvicknair@reservetele.com>; 'Roger Wiklund' <roger.wiklund@gmail.com>; 'Colton Conor' <colton.conor@gmail.com>
Cc: 'Juniper List' <juniper-nsp@puck.nether.net>
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 <kvicknair@reservetele.com>
Sent: Tuesday, September 1, 2020 7:52 PM
To: aaron1@gvtc.com; 'Roger Wiklund' <roger.wiklund@gmail.com>; 'Colton Conor' <colton.conor@gmail.com>
Cc: 'Juniper List' <juniper-nsp@puck.nether.net>
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: aaron1@gvtc.com <aaron1@gvtc.com>
Sent: Tuesday, September 1, 2020 5:34 PM
To: Kody Vicknair <kvicknair@reservetele.com>; 'Roger Wiklund'
<roger.wiklund@gmail.com>; 'Colton Conor' <colton.conor@gmail.com>
Cc: 'Juniper List' <juniper-nsp@puck.nether.net>
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.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





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: How to pick JUNOS Version [ In reply to ]
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: How to pick JUNOS Version [ In reply to ]
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: How to pick JUNOS Version [ In reply to ]
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: How to pick JUNOS Version [ In reply to ]
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: How to pick JUNOS Version [ In reply to ]
> Saku Ytti
> Sent: Wednesday, September 2, 2020 8:37 AM
>
> On Wed, 2 Sep 2020 at 10:23, Andrew Alston
> <Andrew.Alston@liquidtelecom.com> 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 failure cases and bugs)


adam


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