Re: [j-nsp] Experience with Junos 15.1 on MX960?

[Olivier Benghozi]

We've been running 16.1R4-S3 or S4 for 4/5 months (we had to choose between 
15.1F and 16.1R for our MPC7s), without MC-LAG.
We've been hit by about 8 PR, including 4 non-cosmetic ones (with 3 also 
present in 15.1F anyway).
Most of them are allegedly fixed in 16.1R6.
17 might be the next step in 6 months.

> On 12 dec. 2017 at 22:01, Nikolas Geyer  wrote :
> 
> We’re running 16.1R4 and it’s been stable for the most part, aside from a few 
> annoying cosmetic problems.
> 
> Running it on MX480’s and 960’s, a variety of RE’s, a variety of 
> MPC2/MPC3/MPC4/MPC7, usual protocols such as BGP, OSPF, MPLS, RSVP and a few 
> Tbps of traffic. No MC-LAG unfortunately though.
> 
> Will probably schedule moving up to 17 some time early 2018.

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

Re: [j-nsp] What is your experience with the EX2200

[Christian Scholz]

Unfortunately no pattern yet - all areas have problems - but if I have to
name one that has very "hard" Problems it will be dot1x...
Thing is, that we installed a lot of them in production, they were just fine
but after a while we noticed, that whenever we changed the config (even
changing a single VLAN) the Device crashes - no pattern - no Clue. 
Core-Dump does not tell anything good.
JTAC is on this but didn't come up with a Solution yet - we replaced all of
them with the good old EX2200 and now the Production Network runs fine again
(Version 12.3R12-S6 I think).
We will test 17.4 or maybe even better 18.1 or 18.2 - the EX2300 needs to
become more mature before we trust it again.

By the way:
My earlier Mail was not meant to "bully" anyone - it was just my Opinion. I
love Juniper but the Software 15.1 is only a Joke - but enough said ;)



-Ursprüngliche Nachricht-
Von: Dan White [mailto:dwh...@olp.net] 
Gesendet: Montag, 11. Dezember 2017 16:53
An: Christian Scholz 
Cc: juniper-nsp@puck.nether.net
Betreff: Re: What is your experience with the EX2200

Thank you all for your feedback. This is invaluable advice as we don't have
much operational experience with Juniper switches to work with.

Christian,

Is there a common theme among the issues you've encountered? Are they
aligned with a particularly feature set?

On 12/09/17 20:29 +0100, Christian Scholz wrote:
>I would only buy the EX2300 if somebody points a Gun in my Face -
seriously!
>Anyone recommending a Device that purely relies on 15.1 Software does 
>not even closely know what he is talking about...
>
>The 2300 is a Joke so far - We have 7 PR's open and weekly Core-Dumps...
>Stick with the EX2200 since the EX2200 is not EOL and the EX2300 is 
>unusable until a fine Release (17.3 onwards) is available, fixing all 
>the critical things.
>15.1 is the new Windows Vista - unstable, unreliable and just a big 
>joke - never ever ever ever use a 15.X in Production until you want to 
>watch the World burn...
>
>Just my 2 cents...

--
Dan White
BTC Broadband
Network Admin Lead
Ph  918.366.0248 (direct)   main: (918)366-8000
Fax 918.366.6610email: dwh...@olp.net
http://www.btcbroadband.com


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

Re: [j-nsp] Experience with Junos 15.1 on MX960?

[Nikolas Geyer]

We’re running 16.1R4 and it’s been stable for the most part, aside from a few 
annoying cosmetic problems.

Running it on MX480’s and 960’s, a variety of RE’s, a variety of 
MPC2/MPC3/MPC4/MPC7, usual protocols such as BGP, OSPF, MPLS, RSVP and a few 
Tbps of traffic. No MC-LAG unfortunately though.

Will probably schedule moving up to 17 some time early 2018.

Sent from my iPhone

On 12 Dec 2017, at 2:20 pm, Niall Donaghy 
> wrote:

Hello,

We are running 15.1F6-S6.4 on MX480 and MX960. No MC-LAG.
We rolled this out after Juniper PIIR and SURR, and our own internal 
type-certification process.
We needed F6 for EVPN and streaming telemetry features.
Several scary service-affecting bugs came out in the PBN notices, so we 
upgraded twice from the initial version and, hence, now on S6.4.

There are a number of threatening bugs in S6.4 still, but so far the experience 
has been good.

We are running RE-S-1800x4 so are immune to PR1312308.
Your REs are affected, therefore you should check the PR and TSB, which 
recommends 15.1F6-S10 or 15.1F7-S3.

TSB17205 
http://kb.juniper.net/InfoCenter/index?page=content=TSB17205=SUBSCRIPTION
 - PR1312308 - All protocols time out and FPCs are restarting after transient 
SSD freeze
PR1312308 
https://prsearch.juniper.net/InfoCenter/index?page=prcontent=PR1312308 - All 
protocols time out and FPCs are restarting after transient SSD freeze

I strongly recommend you do your due diligence in researching bugs affecting 
your proposed hardware and software versions; there be dragons.

I can tell you for 15.1F6-S6.4 we got 10 PBNs in October this year, thankfully 
none in November, and for December, let's see what we get for Xmas..
Br,
Niall

Niall Donaghy
Senior Network Engineer
GÉANT
T: +44 (0)1223 371393
M: +44 (0) 7557770303
Skype: niall.donaghy-dante
PGP Key ID: 0x77680027
nic-hdl: NGD-RIPE

Networks • Services • People
Learn more at www.geant.org​
​GÉANT is the collective trading name of the GÉANT Association and GEANT 
Limited.

GÉANT Vereniging (Association) is registered in the Netherlands with the 
Chamber of Commerce in Amsterdam. Registration number: 40535155. Registered 
office: Hoekenrode 3, 1102BR Amsterdam, The Netherlands.
GEANT Limited  is registered in England & Wales. Registration number: 2806796. 
Registered office: City House, 126-130 Hills Road, Cambridge CB2 1PQ, UK.



-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Karl Gerhard
Sent: 12 December 2017 09:53
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Experience with Junos 15.1 on MX960?

Hello

we've had very bad experience with Junos 15.1 on our switches (EX4550, EX4300, 
EX4200).
Now we're getting new MX960s with 2xRE-S-X6-64G and unfortunately the minimum 
required Junos version for this RE is 15.1. Can anyone share their experience 
with Junos 15.1 on MX960? Is it as bad as it is on the switches? Would it be 
wiser to jump directly to 16.1/16.2/17.1/17.2/17.3?

We're especially interested in bugs/problems related to MC-LAG.

Regards
Karl
___
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] Experience with Junos 15.1 on MX960?

[Niall Donaghy]

Hello,

We are running 15.1F6-S6.4 on MX480 and MX960. No MC-LAG.
We rolled this out after Juniper PIIR and SURR, and our own internal 
type-certification process.
We needed F6 for EVPN and streaming telemetry features.
Several scary service-affecting bugs came out in the PBN notices, so we 
upgraded twice from the initial version and, hence, now on S6.4.

There are a number of threatening bugs in S6.4 still, but so far the experience 
has been good.

We are running RE-S-1800x4 so are immune to PR1312308.
Your REs are affected, therefore you should check the PR and TSB, which 
recommends 15.1F6-S10 or 15.1F7-S3.

TSB17205 
http://kb.juniper.net/InfoCenter/index?page=content=TSB17205=SUBSCRIPTION
 - PR1312308 - All protocols time out and FPCs are restarting after transient 
SSD freeze
PR1312308 
https://prsearch.juniper.net/InfoCenter/index?page=prcontent=PR1312308 - All 
protocols time out and FPCs are restarting after transient SSD freeze

I strongly recommend you do your due diligence in researching bugs affecting 
your proposed hardware and software versions; there be dragons.

I can tell you for 15.1F6-S6.4 we got 10 PBNs in October this year, thankfully 
none in November, and for December, let's see what we get for Xmas..
Br,
Niall

Niall Donaghy
Senior Network Engineer
GÉANT
T: +44 (0)1223 371393
M: +44 (0) 7557770303
Skype: niall.donaghy-dante
PGP Key ID: 0x77680027
nic-hdl: NGD-RIPE

Networks • Services • People 
Learn more at www.geant.org​
​GÉANT is the collective trading name of the GÉANT Association and GEANT 
Limited.

GÉANT Vereniging (Association) is registered in the Netherlands with the 
Chamber of Commerce in Amsterdam. Registration number: 40535155. Registered 
office: Hoekenrode 3, 1102BR Amsterdam, The Netherlands.
GEANT Limited  is registered in England & Wales. Registration number: 2806796. 
Registered office: City House, 126-130 Hills Road, Cambridge CB2 1PQ, UK.



-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Karl Gerhard
Sent: 12 December 2017 09:53
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Experience with Junos 15.1 on MX960?

Hello

we've had very bad experience with Junos 15.1 on our switches (EX4550, EX4300, 
EX4200).
Now we're getting new MX960s with 2xRE-S-X6-64G and unfortunately the minimum 
required Junos version for this RE is 15.1. Can anyone share their experience 
with Junos 15.1 on MX960? Is it as bad as it is on the switches? Would it be 
wiser to jump directly to 16.1/16.2/17.1/17.2/17.3?

We're especially interested in bugs/problems related to MC-LAG.

Regards
Karl
___
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] Experience with Junos 15.1 on MX960?

[Chris Wopat]

On Tue, Dec 12, 2017 at 3:52 AM, Karl Gerhard  wrote:

> Hello
>
> we've had very bad experience with Junos 15.1 on our switches (EX4550,
> EX4300, EX4200).
> Now we're getting new MX960s with 2xRE-S-X6-64G and unfortunately the
> minimum required Junos version for this RE is 15.1. Can anyone share their
> experience with Junos 15.1 on MX960? Is it as bad as it is on the switches?
> Would it be wiser to jump directly to 16.1/16.2/17.1/17.2/17.3?
>

We've been running 15.1F7 where required (RE-S-X6 + MC7E) and 15.1R6 on
other MX's since last summer. no MC-LAG.

Minor issues which are mostly cosmetic such as PR1243071 (SNMP incorrectly
reporting discards as errors).

Junos 15.x is the first release running FreeBSD 10 + adds in virtualization
(at least on that RE) so we honestly expected many more issues than we
actually had.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Experience with Junos 15.1 on MX960?

[Rolf Hanßen]

Hello,

we run a pair of MX960/RE-S-X6-64G (without MC-LAG) since a year now with
16.1.
In first release we hit 2 bugs, 16.1R4-S2.2 works fine since 6 months.
Here also everybody was weeping about the evil new software, in the last
year we had several situations we wanted to use working code from that new
box on amcient boxes that failed because of missing sw features (and MPC
cards).

kind regards
Rolf

> Hello
>
> we've had very bad experience with Junos 15.1 on our switches (EX4550,
> EX4300, EX4200).
> Now we're getting new MX960s with 2xRE-S-X6-64G and unfortunately the
> minimum required Junos version for this RE is 15.1. Can anyone share their
> experience with Junos 15.1 on MX960? Is it as bad as it is on the
> switches? Would it be wiser to jump directly to 16.1/16.2/17.1/17.2/17.3?
>
> We're especially interested in bugs/problems related to MC-LAG.
>
> Regards
> Karl


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

Re: [j-nsp] SRX and http/https proxy

[Roger Wiklund]

Two options on the top of my head:

1. Use Security Director, that will download the signature to the server
and then push it to the device. (SD will also give you lots of other
benefits/visibility)
2. Download the update to a web server the SRX can reach, then use
offline-download "request security idp security-package offline-download
package-path http://x/y;

You can easily configure an event-option to run the update every night.

set event-options generate-event daily time-of-day 01:00:00
set event-options policy update_idp_package events daily
set event-options policy update_idp_package then execute-commands command
"request security idp security-package offline-download package-path
http://x/y;

BTW stick with Junos 15.1X49-D120 for now. 17.4 or 18.1 will get full
15.1X49 feature parity.

Regards
Roger






On Tue, Dec 12, 2017 at 11:38 AM, Benoit Plessis 
wrote:

> Hi,
>
> We have recently bought an SRX345 cluster with IDP licensing and i'm a
> bit baffled by something a bit "stupid".
>
> The SRX will need regular download over the internet for the IDP
> database, however, by principle i setup the system so that the admin
> interface has a limited network connectivity (by use of a separate
> routing-instance for the main trafic).
>
> So i looked for a way for the SRX to use a web proxy (squid, ffproxy)
> for thoses operations.
>
> According to the documentation & configuration it is supported (system
> proxy server / system proxy port) however of the 4 download "use-case" i
> tested (request system licence update, request security idp
> security-package download, request system license add, file copy) only
> the first (request system licence update) does "try" to respect and use
> the system proxy, and even there it doesn't correctly communicate with
> the proxy for "https" requests.
>
> I tried with 17.3R1.10, 12.1X46-D15.3, 12.3X48-D40.5 with the same
> result each time.
>
>
> A case is pending openning over juniper support but the support contract
> of the SRX345 isn't openned yet, so i though of reaching over there,
> does anybody know anything on the subject ?
>
> Regards,
> Benoit Plessis
>
> ___
> 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] Experience with Junos 15.1 on MX960?

[Sebastian Becker]

I recommend Junos 16.1R4 as minimum. They have done some improvements to the 
software quality.
We are on 16.1R4-S6.3 and it looks good so far.

— 
Sebastian Becker

> Am 12.12.2017 um 10:52 schrieb Karl Gerhard :
> 
> 
> Hello
> 
> we've had very bad experience with Junos 15.1 on our switches (EX4550, 
> EX4300, EX4200).
> Now we're getting new MX960s with 2xRE-S-X6-64G and unfortunately the minimum 
> required Junos version for this RE is 15.1. Can anyone share their experience 
> with Junos 15.1 on MX960? Is it as bad as it is on the switches? Would it be 
> wiser to jump directly to 16.1/16.2/17.1/17.2/17.3?
> 
> We're especially interested in bugs/problems related to MC-LAG.
> 
> Regards
> Karl
> ___
> 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] Experience with Junos 15.1 on MX960?

[Raphael Maunier]

Same here.

15.1 seems to be … not a good choice ( EX3300 / EX2200 )
For QFX10k/5k, I’m not sure If we can start using 17.2R2 or just wait for 17.3R2

Raphael


On 12/12/2017 10:52, "juniper-nsp on behalf of Karl Gerhard" 
 wrote:

Hello

we've had very bad experience with Junos 15.1 on our switches (EX4550, 
EX4300, EX4200).
Now we're getting new MX960s with 2xRE-S-X6-64G and unfortunately the 
minimum required Junos version for this RE is 15.1. Can anyone share their 
experience with Junos 15.1 on MX960? Is it as bad as it is on the switches? 
Would it be wiser to jump directly to 16.1/16.2/17.1/17.2/17.3?

We're especially interested in bugs/problems related to MC-LAG.

Regards
Karl
___
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] Experience with Junos 15.1 on MX960?

[Pierre Emeriaud]

> we've had very bad experience with Junos 15.1 on our switches (EX4550, 
> EX4300, EX4200).
> Now we're getting new MX960s with 2xRE-S-X6-64G and unfortunately the minimum 
> required Junos version for this RE is 15.1. Can anyone share their experience 
> with Junos 15.1 on MX960? Is it as bad as it is on the switches? Would it be 
> wiser to jump directly to 16.1/16.2/17.1/17.2/17.3?
>
> We're especially interested in bugs/problems related to MC-LAG.

We've been hit with several bugs on 15.1F5, from S4.6 to S7. S8 seems
to work fine for our usecase, and sleep is finally possible.

But so far, no issues with MC-LAG, with either two 15.1 boxen or a mix
of 14.1 and 15.1.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Experience with Junos 15.1 on MX960?

[Aaron Gould]

Why wouldn't we all use the juniper.net jtac recommended software versions
web site to determine at least a starting point ?

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

I just bought (6) MX960's and I see them arriving with 15.1F7.3 on RE's
RE-S-2X00x6 with Enhanced MX SCB 2

I'm new with the MX960 platform, so I will be learning as I go.

- Aaron


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

Re: [j-nsp] Experience with Junos 15.1 on MX960?

[adamv0025]

Interesting choices one has with modern codes.
So how I see it we now have the old fashioned approach of waiting till the
code gets a critical mass resulting in most bugs to be fixed -then consider
for internal testing and deployment.
Or just go for the latest codes -that promises to catch like 90% of bugs via
new advanced internal testing strategies. 
That kind of shifts the paradigm right?
>From do you want to be the first adopter of a new code, to do you want to be
the first adopter of the vendor's new code testing strategy -and rely on it
to be as good as advertised.

But I agree one can select any code and if you do your rigorous in house
testing to make sure the code works with your hw and features who are we to
say otherwise right?

To your point b) -there's also an option for JSUs -but this platform seem
much less common than SMUs in XR so you might get bugs in JSU framework.

Also latest XR promises to customize the installation so you can cherry pick
only protocols you need hopefully resulting in less regression bugs. 

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::

> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of Saku Ytti
> Sent: Tuesday, December 12, 2017 10:47 AM
> To: Karl Gerhard
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Experience with Junos 15.1 on MX960?
> 
> Hey,
> 
> Personally my strategy with software has always been:
> 
> a) start with latest long term release
> b) if you need bug fixes, update to rebuilds
> c) if you need new features, update to latest long term release
> 
> I don't think software is like wine, I don't think it gets better as it
ages. And
> Juniper has done lot of good work on quality which only applies to late
> releases.
> 
> 15.1 will be EOL in under half a year. Just for support you want at least
16.1,
> but then why not jump straight to 17.3?
> 
> What ultimately makes you experience positive or negative can be behind
> complex set of variables which poorly translates to other networks. Rarely
> there is some vintage release number which is universally good or
universally
> bad.
> 
> I'd start testing 17.3 and go from there.
> 
> 
> On 12 December 2017 at 11:52, Karl Gerhard  wrote:
> > Hello
> >
> > we've had very bad experience with Junos 15.1 on our switches (EX4550,
> EX4300, EX4200).
> > Now we're getting new MX960s with 2xRE-S-X6-64G and unfortunately the
> minimum required Junos version for this RE is 15.1. Can anyone share their
> experience with Junos 15.1 on MX960? Is it as bad as it is on the
switches?
> Would it be wiser to jump directly to 16.1/16.2/17.1/17.2/17.3?
> >
> > We're especially interested in bugs/problems related to MC-LAG.
> >
> > Regards
> > Karl
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 
> 
> --
>   ++ytti
> ___
> 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] Experience with Junos 15.1 on MX960?

[Javier Valero]

Hi,

We had a bad experience with MX960 and 16.1R3. We were affected by multiple 
PRs. Some of them silent and "malicious" .

However, we have a good experience with 15.1 on 4550 and 4200.
Which problems did you found on it?

Regards.
Javier Valero | IslaLink / OranLink


-Mensaje original-
De: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] En nombre de Karl 
Gerhard
Enviado el: martes, 12 de diciembre de 2017 10:53
Para: juniper-nsp@puck.nether.net
Asunto: [j-nsp] Experience with Junos 15.1 on MX960?

Hello

we've had very bad experience with Junos 15.1 on our switches (EX4550, EX4300, 
EX4200).
Now we're getting new MX960s with 2xRE-S-X6-64G and unfortunately the minimum 
required Junos version for this RE is 15.1. Can anyone share their experience 
with Junos 15.1 on MX960? Is it as bad as it is on the switches? Would it be 
wiser to jump directly to 16.1/16.2/17.1/17.2/17.3?

We're especially interested in bugs/problems related to MC-LAG.

Regards
Karl
___
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] Experience with Junos 15.1 on MX960?

[Saku Ytti]

Hey,

Personally my strategy with software has always been:

a) start with latest long term release
b) if you need bug fixes, update to rebuilds
c) if you need new features, update to latest long term release

I don't think software is like wine, I don't think it gets better as
it ages. And Juniper has done lot of good work on quality which only
applies to late releases.

15.1 will be EOL in under half a year. Just for support you want at
least 16.1, but then why not jump straight to 17.3?

What ultimately makes you experience positive or negative can be
behind complex set of variables which poorly translates to other
networks. Rarely there is some vintage release number which is
universally good or universally bad.

I'd start testing 17.3 and go from there.


On 12 December 2017 at 11:52, Karl Gerhard  wrote:
> Hello
>
> we've had very bad experience with Junos 15.1 on our switches (EX4550, 
> EX4300, EX4200).
> Now we're getting new MX960s with 2xRE-S-X6-64G and unfortunately the minimum 
> required Junos version for this RE is 15.1. Can anyone share their experience 
> with Junos 15.1 on MX960? Is it as bad as it is on the switches? Would it be 
> wiser to jump directly to 16.1/16.2/17.1/17.2/17.3?
>
> We're especially interested in bugs/problems related to MC-LAG.
>
> Regards
> Karl
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



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

[j-nsp] SRX and http/https proxy

[Benoit Plessis]

Hi,

We have recently bought an SRX345 cluster with IDP licensing and i'm a
bit baffled by something a bit "stupid".

The SRX will need regular download over the internet for the IDP
database, however, by principle i setup the system so that the admin
interface has a limited network connectivity (by use of a separate
routing-instance for the main trafic).

So i looked for a way for the SRX to use a web proxy (squid, ffproxy)
for thoses operations.

According to the documentation & configuration it is supported (system
proxy server / system proxy port) however of the 4 download "use-case" i
tested (request system licence update, request security idp
security-package download, request system license add, file copy) only
the first (request system licence update) does "try" to respect and use
the system proxy, and even there it doesn't correctly communicate with
the proxy for "https" requests.

I tried with 17.3R1.10, 12.1X46-D15.3, 12.3X48-D40.5 with the same
result each time.


A case is pending openning over juniper support but the support contract
of the SRX345 isn't openned yet, so i though of reaching over there,
does anybody know anything on the subject ?

Regards,
Benoit Plessis

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

Re: [j-nsp] QFX5100 ACLs

[Saku Ytti]

ACK. Which is common in the industry, lot, probably most boxes are not
edge L3 compatible. Inclusive all the BRCM super cost-effective
10/100GE boxes.

We don't even have to think about malicious users, what happens when
my BGP customer has L2 loop? Entirely reasonable to think they'll
inject 1.48Mpps of BGP to me. Heck, I've created L2 loop or two
accidentally.


On 12 December 2017 at 11:12,   wrote:
> Good point actually, and there's the fact that one can't block the protocol 
> if not used.
> So I guess one has to burry these in the core and rely on flawless iACLs
>
> adam
>
> netconsultings.com
> ::carrier-class solutions for the telecommunications industry::
>
>> -Original Message-
>> From: Saku Ytti [mailto:s...@ytti.fi]
>> Sent: Tuesday, December 12, 2017 9:08 AM
>> To: adamv0...@netconsultings.com
>> Cc: Brendan Mannella; juniper-nsp@puck.nether.net
>> Subject: Re: [j-nsp] QFX5100 ACLs
>>
>> Policer on term which does not discriminate good and bad only gives attacker
>> an leverage by reducing the pps/bps demand to congest the good?
>>
>>
>> On 12 December 2017 at 10:21,   wrote:
>> >> Of Saku Ytti
>> >> Sent: Monday, December 11, 2017 2:46 PM
>> >>
>> >> Someone pointed this to me -
>> >> https://kb.juniper.net/InfoCenter/index?page=content=KB24145
>> >>
>> > Are there any "sensible" policers defined for these "70 such hardware
>> > filters, which target different protocols"?
>> >
>> > adam
>> >
>> > netconsultings.com
>> > ::carrier-class solutions for the telecommunications industry::
>> >
>>
>>
>>
>> --
>>   ++ytti
>



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

Re: [j-nsp] What is your experience with the EX2200

[Chris Lee via juniper-nsp]

On Tue, Dec 12, 2017 at 2:29 AM, Kevin Day  wrote:

> The problems with the EX2300 I've seen:
>
> * The out-of-the-box version of Junos on them has a clock bug where it
> says its NTP synced, but the system clock gets advanced to 2038 and things
> go crazy. It's sometimes difficult to keep the switch running long enough
> to upgrade it.
>

Yep hit this bug several times but was hard to pinpoint an exact cause,
sometimes it seemed to be worse if I'd powered the switch up and left it
for a while before loading the initial config. After a while I found that
manually setting the time to within a few minutes of correct local time and
rebooting the switch that it would be enough to get the new image deployed.


> * It's also painfully slow to reboot, but not quite as bad as the EX2200.
>

Yeah was equally disappointed to see that boot times hadn't improved any
over the EX2200, in my experience both platforms take a full 5 minutes to
boot and start forwarding traffic.


> * Some old half-duplex devices don't negotiate with the EX2300, but work
> with the EX2200. It's improved with later builds, but not perfect.
>

We similarly had issues with old model Gallagher cardax controllers not
properly negotiating on the EX2300, they used to negotiate themselves to
10Mbps Half-Duplex on the old Cisco 3750 switches just fine, took a bit of
trial and error on the EX2300 configs to work out to just set the port to
10Mbps Full-Duplex with no auto-negotiate and no flow-control and they show
up as working at 10Mbps Full Duplex now.

>
> Overall neither switch has had bad enough issues that I'd shy away from
> them. The 2300 is definitely an upgrade that I'm happy with.
>

Agreed, although the need to purchase a "paper" licence for the 2300 just
to enable virtual-chassis when it was otherwise standard on the EX2200
seems to be a step backwards as well, I'm having to store a whole heap of
envelopes with the paper licence to apparently prove the right to use that
feature.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Experience with Junos 15.1 on MX960?

[Nathan Ward]

Hi,

> On 12/12/2017, at 10:52 PM, Karl Gerhard  wrote:
> 
> Hello
> 
> we've had very bad experience with Junos 15.1 on our switches (EX4550, 
> EX4300, EX4200).
> Now we're getting new MX960s with 2xRE-S-X6-64G and unfortunately the minimum 
> required Junos version for this RE is 15.1. Can anyone share their experience 
> with Junos 15.1 on MX960? Is it as bad as it is on the switches? Would it be 
> wiser to jump directly to 16.1/16.2/17.1/17.2/17.3?
> 
> We're especially interested in bugs/problems related to MC-LAG.


15.1R6 works great for me on MX480, which is more or less the same box. l3vpn, 
l2circuit, pwhe, BNG all seem to work well. No MC-LAG sorry.
What sort of trouble have you had on the switches? Are they control plane 
problems which would translate to the MX, or, are they forwarding?


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

[j-nsp] Experience with Junos 15.1 on MX960?

[Karl Gerhard]

Hello

we've had very bad experience with Junos 15.1 on our switches (EX4550, EX4300, 
EX4200).
Now we're getting new MX960s with 2xRE-S-X6-64G and unfortunately the minimum 
required Junos version for this RE is 15.1. Can anyone share their experience 
with Junos 15.1 on MX960? Is it as bad as it is on the switches? Would it be 
wiser to jump directly to 16.1/16.2/17.1/17.2/17.3?

We're especially interested in bugs/problems related to MC-LAG.

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

Re: [j-nsp] QFX5100 ACLs

[adamv0025]

Good point actually, and there's the fact that one can't block the protocol if 
not used.
So I guess one has to burry these in the core and rely on flawless iACLs

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::

> -Original Message-
> From: Saku Ytti [mailto:s...@ytti.fi]
> Sent: Tuesday, December 12, 2017 9:08 AM
> To: adamv0...@netconsultings.com
> Cc: Brendan Mannella; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] QFX5100 ACLs
> 
> Policer on term which does not discriminate good and bad only gives attacker
> an leverage by reducing the pps/bps demand to congest the good?
> 
> 
> On 12 December 2017 at 10:21,   wrote:
> >> Of Saku Ytti
> >> Sent: Monday, December 11, 2017 2:46 PM
> >>
> >> Someone pointed this to me -
> >> https://kb.juniper.net/InfoCenter/index?page=content=KB24145
> >>
> > Are there any "sensible" policers defined for these "70 such hardware
> > filters, which target different protocols"?
> >
> > adam
> >
> > netconsultings.com
> > ::carrier-class solutions for the telecommunications industry::
> >
> 
> 
> 
> --
>   ++ytti

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

Re: [j-nsp] QFX5100 ACLs

[Saku Ytti]

Policer on term which does not discriminate good and bad only gives
attacker an leverage by reducing the pps/bps demand to congest the
good?


On 12 December 2017 at 10:21,   wrote:
>> Of Saku Ytti
>> Sent: Monday, December 11, 2017 2:46 PM
>>
>> Someone pointed this to me -
>> https://kb.juniper.net/InfoCenter/index?page=content=KB24145
>>
> Are there any "sensible" policers defined for these "70 such hardware
> filters, which target different protocols"?
>
> adam
>
> netconsultings.com
> ::carrier-class solutions for the telecommunications industry::
>



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

Re: [j-nsp] QFX5100 ACLs

[adamv0025]

> Of Saku Ytti
> Sent: Monday, December 11, 2017 2:46 PM
> 
> Someone pointed this to me -
> https://kb.juniper.net/InfoCenter/index?page=content=KB24145
> 
Are there any "sensible" policers defined for these "70 such hardware
filters, which target different protocols"?

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::

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