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

[j-nsp] How to pick JUNOS Version

[Colton Conor]

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

Re: [j-nsp] qfx5100 help with Q in Q

[Olivier Benghozi]

Hi,
I posted some working config last week in this ML (working for EX4600 and 
therefore QFX5100 – but on 18.4R3).

> Le 19 août 2020 à 14:40, John Brown  a écrit :
> 
> Switch A is running 18.1R3.3
> Switch B is running 18.3R2.7
> Both are qfx5100-48s-6q.
> 
> [...]
> 
> I am trying to QinQ traffic between Switch A and B.
> 
> [...]
> 
> I've tried "All-in-one Bundling" and several other configs and have
> looked at docs on Juniper site.

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

[j-nsp] qfx5100 help with Q in Q

[John Brown]

Hi I've been trying to get what I think should be pretty simple config
working between two QFX's
Switch A is running 18.1R3.3
Switch B is running 18.3R2.7
Both are qfx5100-48s-6q.

Switch A
Customer 1   xe-0/0/1
Customer 2   xe-0/0/2
Switch B
 Customer 1 xe-0/0/46
 Customer 2 xe-0/0/45

Switch A port xe-0/0/0 is connected to Switch B xe-0/0/47

I am trying to QinQ traffic between Switch A and B.
Customer 1 on Switch A wishes to send untagged traffic and maybe
tagged traffic in the future
to its Customer 1 port on Switch B

Customer 2 on Switch A wishes to send untagged traffic and maybe
tagged traffic in the future
to its Customer 2 port on Switch B

I've tried "All-in-one Bundling" and several other configs and have
looked at docs on Juniper site.
If anyone has a sample config that would be great.  Pointers appreciated.

Thank you

-- 
Respectfully,

John Brown, CISSP
Managing Member, CityLink Telecommunications NM, LLC
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] IPv4 BFD flaps on MX204

[Mark Tinka]

On 19/Aug/20 10:37, Antti Ristimäki wrote:

> Hi,
>
> In fact inline IPv6 BFD is supported for other than link-local addresses 
> starting from 18.1 IIRC. This doesn't help for IS-IS or OSPFv3, though, as 
> those use link-local addresses for adjacencies.
>
> We do have IPv6 BFD enabled for IS-IS but with very relaxed timers compared 
> to IPv4. Haven't seen any issues for a couple of years.

If your timers are not aggressive, then you should be fine, as that will
account for any CPU spikes that de-prioritize BFDv6 packets.

We are running 150ms @ 3X and 250ms @ 5X. So we saw issues on BFDv6.

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

Re: [j-nsp] SNMP OIDs for Yellow/Red Alarm on MX204

[Joerg Staedele]

Hi Guys.

I still can't understand why Juniper is not integrating a "mapping" for the 
alarm-OIDs. I know, there's no craftd on the MX204 but in the CLI it also shows 
yellow/red alarms so the info is already available ...

Kind regards
 Joerg

> -Original Message-
> From: juniper-nsp  On Behalf Of
> Roger Wiklund
> Sent: Wednesday, August 19, 2020 12:30 PM
> To: Arzhel Younsi 
> Cc: juniper-nsp 
> Subject: Re: [j-nsp] SNMP OIDs for Yellow/Red Alarm on MX204
> 
> Maybe you can use an SNMP script as a workaround?
> https://www.juniper.net/documentation/en_US/junos/topics/example/jun
> os-script-automation-snmp-script-example.html
> 
> /Roger
> 
> On Fri, Aug 7, 2020 at 3:32 PM Arzhel Younsi  wrote:
> 
> > Hi,
> >
> > Our rep opened ER-080949 last month.
> >
> > Cheers.
> >
> > --
> > Arzhel
> >
> > On Thu, Feb 28, 2019, at 23:59, John Kristoff wrote:
> > > On Thu, 28 Feb 2019 22:06:27 +
> > > Theo Voss  wrote:
> > >
> > > > do you have an ER (Enhancement Request) ID for us to beg our SE/sales
> > > > rep for in order to support this?
> > >
> > > I just requested from a local rep.  When and if I get one I'll respond
> > > to this thread.
> > >
> > > John
> > > ___
> > > 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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SNMP OIDs for Yellow/Red Alarm on MX204

[Roger Wiklund]

Maybe you can use an SNMP script as a workaround?
https://www.juniper.net/documentation/en_US/junos/topics/example/junos-script-automation-snmp-script-example.html

/Roger

On Fri, Aug 7, 2020 at 3:32 PM Arzhel Younsi  wrote:

> Hi,
>
> Our rep opened ER-080949 last month.
>
> Cheers.
>
> --
> Arzhel
>
> On Thu, Feb 28, 2019, at 23:59, John Kristoff wrote:
> > On Thu, 28 Feb 2019 22:06:27 +
> > Theo Voss  wrote:
> >
> > > do you have an ER (Enhancement Request) ID for us to beg our SE/sales
> > > rep for in order to support this?
> >
> > I just requested from a local rep.  When and if I get one I'll respond
> > to this thread.
> >
> > John
> > ___
> > 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] IPv4 BFD flaps on MX204

[Antti Ristimäki]

Hi,

In fact inline IPv6 BFD is supported for other than link-local addresses 
starting from 18.1 IIRC. This doesn't help for IS-IS or OSPFv3, though, as 
those use link-local addresses for adjacencies.

We do have IPv6 BFD enabled for IS-IS but with very relaxed timers compared to 
IPv4. Haven't seen any issues for a couple of years.

Antti

- On 18 Aug, 2020, at 15:11, Mark Tinka mark.ti...@seacom.com wrote:

> I'd recommend disabling IPv6 BFD for now as well. It's not handled in
> hardware, and so if it drops, you would lose your IGP. Worse if you run
> multiple address families in your IGP, e.g., IS-IS, or IPv4 over OSPFv3 .
> 
> Hardware support for BFDv6 is coming in 1H'21.
> 
> Mark.
> 
> On 18/Aug/20 13:01, Mihai wrote:
>> Hi Ivan,
>>
>> Indeed, that was the issue, thanks!
>>
>> Regards
>>
>> On 18/08/2020 09:54, Ivan Malyarchuk wrote:
>>> If you have many uncontrolled directly connected L2 domains like
>>> IX-es or customers, check policer __default_arp_policer__.
>>> If there are drops, you need to apply interface-specific arp policers
>>> to interfaces with protocols and/or to source of arp bursts.
>>>
>>>
>>>
>>> 18.08.2020 02:35, Mihai пишет:
 Hi,

 I have a MX204 with a couple of OSPF/OSPFv3 adj to other MXs over
 two et- interfaces, BFD enabled for both protocols.
 At random intervals the IPv4 BFD sessions are flapping with or
 without the 'no-delegate-processing' option, however the IPv6
 sessions are stable (they are using the same timers).

 Did anyone experienced something like this? The router is running
 18.2R3-S3.


 Thanks!
 ___
 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
> 
> 
> --
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp