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

2017-12-12 Thread 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

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

2017-12-12 Thread 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

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

2017-12-12 Thread 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

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

2017-12-12 Thread 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

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

2017-12-12 Thread 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

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

2017-12-12 Thread 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

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

2017-12-12 Thread 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

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

2017-12-12 Thread 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

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

2017-12-12 Thread 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:

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

2017-12-12 Thread 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

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

2017-12-12 Thread 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

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

2017-12-12 Thread 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

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

2017-12-12 Thread 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

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

2017-12-12 Thread 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

[j-nsp] SRX and http/https proxy

2017-12-12 Thread 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

Re: [j-nsp] QFX5100 ACLs

2017-12-12 Thread 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

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

2017-12-12 Thread 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

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

2017-12-12 Thread 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

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

2017-12-12 Thread 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

Re: [j-nsp] QFX5100 ACLs

2017-12-12 Thread 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

Re: [j-nsp] QFX5100 ACLs

2017-12-12 Thread 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

Re: [j-nsp] QFX5100 ACLs

2017-12-12 Thread 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