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
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
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
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
upgrad
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
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 t
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 securit
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 (EX4
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
> 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
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&id=KB21476&actp=METADAT
A
I just bought (6) MX960's and I see them arriving with 15.1F7.3 on RE's
RE-S-2X00x6 with Enha
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%
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
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
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 (b
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.48M
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 swit
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 anyo
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
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 Ytt
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.n
> Of Saku Ytti
> Sent: Monday, December 11, 2017 2:46 PM
>
> Someone pointed this to me -
> https://kb.juniper.net/InfoCenter/index?page=content&id=KB24145
>
Are there any "sensible" policers defined for these "70 such hardware
filters, which target different protocols"?
adam
netconsultings.com
22 matches
Mail list logo