[j-nsp] About Secure Transport for RPKI on JUNOS

2018-12-21 Thread Pyxis LX 
Hi, All,

Does JUNOS support any secure transports mentioned in RFC6810 for rpki-rtr
protocol? (SSHv2/IPsec or TLS for rpki-rtr-tls?)
I am unable to find any documents related on the JUNOS website or CLI.
Given that IOS-XR supports SSHv2 tunnel, I would suspect JUNOS has same
level of support?

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

Re: [j-nsp] qfx5120-48y-8c - jtac recommeded junos version

2018-12-21 Thread Eric Krichbaum 
You'll have to let us know how well they work. I heard no vc stacking until
v19 code or so. Also wondering about 18 level code.  Just took a set of
5100s to 17.3 with good results.

-Original Message-
From: juniper-nsp  On Behalf Of Aaron
Gould
Sent: Friday, December 21, 2018 10:34 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] qfx5120-48y-8c - jtac recommeded junos version

I got my QFX-5120's in a couple days ago. running 18.3R1.11

 

I don't see a JTAC Recommendation for 5120

 

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

=KB21476

 

{master:0}

root> show system information

Model: qfx5120-48y-8c

Family: junos-qfx

Junos: 18.3R1.11

 

 

- Aaron

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


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

[j-nsp] qfx5120-48y-8c - jtac recommeded junos version

2018-12-21 Thread Aaron Gould 
I got my QFX-5120's in a couple days ago. running 18.3R1.11

 

I don't see a JTAC Recommendation for 5120

 

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

=KB21476

 

{master:0}

root> show system information

Model: qfx5120-48y-8c

Family: junos-qfx

Junos: 18.3R1.11

 

 

- Aaron

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

Re: [j-nsp] SNMP_EVLIB_FAILURE - snmp not working anymore

2018-12-21 Thread Emille Blanc 
Juniper has always been accommodating in my occasional request to provide 
disambiguation to KB's or PR's, whenever I use the feedback widget.
Let them know your thoughts.

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Sebastian Wiesinger
Sent: Friday, December 21, 2018 4:48 AM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] SNMP_EVLIB_FAILURE - snmp not working anymore

* Olivier Benghozi  [2018-12-21 02:05]:
> PR1270686
> 
> restart statistics-service

This PR is one example of something I don't like in most Juniper PRs.
It states the command you quoted but then there is also this text:

Workaround:

Disable pfed's periodic refresh using config:
set accounting-options periodic-refresh disable

Nowhere in this PR is explained what that does and what possible
side-effects are. You only find this exact command in a post on the
Juniper forums:


> set accounting-options periodic-refresh disable
> -->Periodic-refresh is disabled to change the default behavior for
> stats collection. Pre-BBE, stats were constantly collected in JUNOS.
> This uses CPU cycles that are needed for call set up.
> -->With the introduction of BBE in JUNOS, we needed to change the
> behavior for stats to be on demand. That is what disabling
> periodic-refresh does. There is no negative impact to accurate stats
> or interim stats.
> -->Without this disabled, accounting will be very inefficient and not
> scale.

This might be the correct explanation or it might be just a text from
someone who wants to gain "kudos" so that he can get to the next level
in the Juniper Support pantheon aka "The Stack Exchange disease".

Either way it would be very nice if Juniper would post some more
information on *what* a workaround does and when it would not be wise
to use it. In this case you should probably not use the workaround if
you have a scaled BBE setup I would imagine.

Regards

Sebastian

-- 
GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
___
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] interface-range inheritance change in 14.1X53 and 15.1

2018-12-21 Thread Thomas Bellman 
On 2018-12-21 23:22 UTC, Anderson, Charles R wrote:

> Can anyone shed some light on WHY this change was made?  I much prefer
> the old behavior.
> 
> From PR1281947:
> 
> "The behavior of the "interface-range" configuration statement changed
> in 14.1X53 and 15.1. Prior to 14.1X53 and 15.1, more specific configuration
> on the interface would supersede what was configured in the interface-range.
> In 14.1X53 or 15.1, if there was specific interface configuration, the
> configuration in "interface-range" will append to it. For example, if there
> is a mismatch of VLAN assignment between the interface-range and the direct
> interface configuration, it will append the configured VLAN and cause an
> invalid configuration in 14.1X53 or 15.1."

I don't know Juniper's motivations, but the new behaviour *allows* you
to append, which could be useful for trunk mode interfaces.  The old
behaviour didn't.  (I don't use this myself for interface ranges, but I
do use it for groups/apply-groups; I don't know if groups also changed
chnaged their behaviour.)

To, kind of, emulate the old behaviour, you could use multiple ranges:

interface-range all-hosts {
member-range xe-0/0/4 to xe-0/0/23;
mtu 9216;
unit 0 {
family ethernet-switching {
interface-mode access;
}
}
}
interface-range most-hosts {
member-range xe-0/0/4 to xe-0/0/14;
member-range xe-0/0/16 to xe-0/0/23;
unit 0 {
family ethernet-switching {
vlan { members HostVLAN; }
}
}
}
xe-0/0/15 {
unit 0 {
family ethernet-switching {
vlan { members OtherVLAN; }
}
}
}

Admittedly, a fair bit more clumsy, but it *is* possible to express.

Maybe there should have been a 'except-interface-range '
statement, similar to 'apply-groups-except'?


(A nicer way of expressing VLAN assignments, would be to throw out
the 'interface-mode' statement, and replace 'vlan members' with two
statements: 'untagged-vlan ' and 'tagged-vlans '.  I
suppose that would also have solved your practical problems, since
singletons are still overridden by more specific declarations, and I
guess you want this for access-mode interfaces.)


/Bellman



signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] interface-range inheritance change in 14.1X53 and 15.1

2018-12-21 Thread Timur Maryin via juniper-nsp 

My bet is that is an example of poorly written external description.
Besides "Resolved-In" has only one version.


On 21-Dec-18 00:22, Anderson, Charles R wrote:

Can anyone shed some light on WHY this change was made?  I much prefer the old 
behavior.


From PR1281947:


"The behavior of the "interface-range" configuration statement changed in 14.1X53 and 15.1. 
Prior to 14.1X53 and 15.1, more specific configuration on the interface would supersede what was configured 
in the interface-range. In 14.1X53 or 15.1, if there was specific interface configuration, the configuration 
in "interface-range" will append to it. For example, if there is a mismatch of VLAN assignment 
between the interface-range and the direct interface configuration, it will append the configured VLAN and 
cause an invalid configuration in 14.1X53 or 15.1."

https://prsearch.juniper.net/InfoCenter/index?page=prcontent=PR1281947

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

Re: [j-nsp] SNMP_EVLIB_FAILURE - snmp not working anymore

2018-12-21 Thread Jeff Meyers 

Thanks, worked!

Am 21.12.2018 um 02:05 schrieb Olivier Benghozi:

PR1270686

restart statistics-service


Le 21 déc. 2018 à 01:23, Jeff Meyers  a écrit :

Dec 21 01:20:40  fra4-cr2 mib2d[67435]: SNMP_EVLIB_FAILURE: PFED ran out of 
transfer credits with PFE.Failed to get stats. ifl index: 373

I already did a snmp process restart without any success. Google doesn't reveal 
anything helpful to me. Next thing I want to try is a manual RE failover but 
with maintenance notifications, I cannot do that instantly. Did anyone here see 
this before and does by any chance know a solution for this?


___
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