Hello Kamal
thanks for sharing your valuable insight. Very interesting to see what happens
when one tries to upgrade hundreds of Juniper devices.
Upon reading your mail one could get the impression that the upgrade woes and
all the bugs+regressions are a structural problem related to how Junos
Hi,
Up grade issues !
This is very valid point, we are totally fed up with,
Upgrade is a horrible
We got round 2 and half years to upgrade around 200 Ex4200 devices.
Initially every one in three devices failed to boot after the upgrade.
Juniper keep on preaching us go to the site and format
On 23/Sep/19 20:39, Gert Doering wrote:
> Among routers (full flexibility, large tables, buffers, ...) it's a
> fairly good bargain - compare this to ASR9001 or ASR9901 from the Cisco
> camp.
This.
Mark.
signature.asc
Description: OpenPGP digital signature
On 23/Sep/19 20:37, Jason Lixfeld wrote:
> Is the MX204 not a prohibitively expensive 10G port?
When you consider that you can:
- Drive a Metro-E ring at 100Gbps with no special Transport gear.
- Hang an ASR920 or two off of those 10Gbps ports to manage
low-speed customers.
-
Hi,
On Mon, Sep 23, 2019 at 02:37:08PM -0400, Jason Lixfeld wrote:
> > Juniper have dropped the ball here for years. Until the MX204. However,
> > the MX204 is good if you run 10Gbps customers in the Metro. Otherwise,
> > for now, nothing beats the ASR920, IMHO.
>
> Is the MX204 not a
> On Sep 23, 2019, at 2:17 PM, Mark Tinka wrote:
>
> On 23/Sep/19 14:07, Jason Lixfeld wrote:
>> What are your other requirements? Who/what else are you looking at?
>
> We were the first ISP in the world to run IP/MPLS all the way into the
> Access back in 2009 - TIME dotCom, Malaysia - on
On 23/Sep/19 14:07, Jason Lixfeld wrote:
> What are your other requirements? Who/what else are you looking at?
We were the first ISP in the world to run IP/MPLS all the way into the
Access back in 2009 - TIME dotCom, Malaysia - on the Cisco ME3600X.
I haven't operated that network since
(16.x or 18.x) but at the same time I haven't had it recur in our 18.x lab so...
-Michael
> -Original Message-
> From: juniper-nsp On Behalf Of
> Nikolas Geyer
> Sent: Sunday, September 22, 2019 6:27 PM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Suggestio
> On Sep 23, 2019, at 5:11 AM, Mark Tinka wrote:
>
> This is the major driving reason behind us avoiding the NCS540
> for the Metro.
What are your other requirements? Who/what else are you looking at?
___
juniper-nsp mailing list
On 23/Sep/19 13:14, Tarko Tikan wrote:
>
>
> What is the motivation to run jericho in your L2-only setup (instead
> trident)? Only buffer space?
We were chasing the actual switch, as it met all of what we needed,
including the larger buffer space.
Mark.
hey,
7280R, Jericho.
What is the motivation to run jericho in your L2-only setup (instead
trident)? Only buffer space?
--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
On 23/Sep/19 10:58, Karl Gerhard wrote:
>
> The big companies have fancy and expensive labs and employees that spend
> weeks testing new releases. However, we're a small hosting provider running a
> bunch of MX480ies and other Juniper stuff. I need routers that I can upgrade
> without
Hi,
I'd like to point out one more thing because I feel that this point hasn't been
stressed enough:
Upgrading Junos might be more time consuming than many people expect it to be.
The reason for this is that quite often, things that previously worked in Junos
will break in a new release. This
On 23/Sep/19 09:44, Gert Doering wrote:
> Ewww... thanks for the heads up. I have one of those "incoming" as
> new "full table, many features, external links" L3 device, and that
> one will definitely need QoS + netflow/ipfix + L3...
>
> Will test very thoroughly :-)
I'll also let you know
Hi,
On Mon, Sep 23, 2019 at 09:28:38AM +0200, Mark Tinka wrote:
> > Which box was this? Trident or Jericho?
> 7280R, Jericho.
Ewww... thanks for the heads up. I have one of those "incoming" as
new "full table, many features, external links" L3 device, and that
one will definitely need QoS +
On 23/Sep/19 09:23, Gert Doering wrote:
>
> Which box was this? Trident or Jericho?
7280R, Jericho.
Mark.
signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
Hi,
On Mon, Sep 23, 2019 at 09:15:48AM +0200, Mark Tinka wrote:
> We hit an issue where policing did not work, despite being activated. We
> then realized we had to explicitly enable "l2 qos" for our TCAM profile.
> This is traffic-affecting. You then verify by bumping the hardware ACL
>
On 19/Sep/19 00:52, Jason Lixfeld wrote:
> FWIW, you may want to check out Arista’s 7280R. We’ve just deployed a pair
> of these for EVPN-MPLS and they’re slick, and from what I understand, they
> have the FIB scale to be able to act as a border router. It’s a very
> IOS-like CLI (but so
I have to play devils advocate around “Right this inconsistency between
configured and operational state in my opinion is THE biggest problem of XR”
Have had this problem occur multiple times in Junos, as recently as Junos 17,
where what was being advertised did not reflect configured policy.
On 9/19/19, 1:05 AM, "juniper-nsp on behalf of Phil Reilly"
wrote:
MX104's are the dual brain unit of the 204. Though a 204 has 40/100G
capabilities. If I read your original request correctly about ip
routing. Not sure the 104/204 is grunty enough to deal with multiple
Thu, Sep 19, 2019 at 06:42:58PM +0300, Saku Ytti:
> Quite, so I guess to be eligible for update group junos has two
> constraints and ios has one, junos constraints are same egress-policy
> and same peer-group, ios constraints same egress-policy. I can
> understand thne rationale to both, junos
On Thu, 19 Sep 2019 at 18:36, wrote:
> In cisco these should be under common update group
This is a fair point. I've not tried to create unique peer-groups with
non-unique policies so this has escaped me.
> What is dynamic is that the peer 192.0.2.41 will be kicked out of group 11 if
>
> From: Saku Ytti
> Sent: Thursday, September 19, 2019 2:42 PM
>
> On Thu, 19 Sep 2019 at 16:29, wrote:
>
> > The dynamic in Cisco implementation means that peers are automatically
> placed to update groups based on commonalities in export policies,
> regardless of the configuration.
> > In
>
> > Ideally I'd like to see equivalent of Cisco's dynamic update peer-groups
> in Junos.
>
> They are dynamic, but once you make export change which affects subset
> of members in peer-group, that member gets reset while placed to new
> update-group.
And that is how dynamic update groups works
On Thu, 19 Sep 2019 at 16:29, wrote:
> The dynamic in Cisco implementation means that peers are automatically placed
> to update groups based on commonalities in export policies, regardless of the
> configuration.
> In juniper case you can actually have two peers with exact same export
>
> From: Saku Ytti
> Sent: Thursday, September 19, 2019 1:32 PM
>
> On Thu, 19 Sep 2019 at 15:11, wrote:
>
> > Ideally I'd like to see equivalent of Cisco's dynamic update peer-groups in
> Junos.
>
> They are dynamic, but once you make export change which affects subset of
> members in
On Thu, 19 Sep 2019 at 15:11, wrote:
> Ideally I'd like to see equivalent of Cisco's dynamic update peer-groups in
> Junos.
They are dynamic, but once you make export change which affects subset
of members in peer-group, that member gets reset while placed to new
update-group.
> Right this
> From: Saku Ytti
> Sent: Thursday, September 19, 2019 12:33 PM
>
> On Thu, 19 Sep 2019 at 14:22, wrote:
>
> > Just a few examples when you change export policy it resets the peer
> > or the cockup with RR clearing all sessions or the fact BGP is part of
> > very complex RDP monolith -to me
On Thu, 19 Sep 2019 at 14:22, wrote:
> Just a few examples when you change export policy it resets the peer or the
> cockup with RR clearing all sessions or the fact BGP is part of very complex
> RDP monolith -to me that's not really "carrier grade" implementation
This happens when export
> Phil Reilly
> Sent: Thursday, September 19, 2019 6:05 AM
>
> the BGP functionality and extensions are well
> developed in JUNOS.
Ha... :)
Just a few examples when you change export policy it resets the peer or the
cockup with RR clearing all sessions or the fact BGP is part of very complex
g...@greenie.muc.de (Gert Doering) wrote:
> And given the price point of the MX204, if the amount of interfaces is
> sufficient, just get two of them :-)
Alternatively, just add QFXn as satellites.
El El
___
juniper-nsp mailing list
On Thu, 19 Sep 2019 at 01:52, Jason Lixfeld wrote:
> Don’t get me wrong, Cisco definitely owns their share of BS, but they seem to
> be predictable in how they are going to screw you. Juniper will screw you,
> but how they are going to screw you seems to be predictably unpredictable.
I have
Hi,
On Thu, Sep 19, 2019 at 05:04:54PM +1200, Phil Reilly wrote:
> MX104's are the dual brain unit of the 204. Though a 204 has 40/100G
> capabilities. If I read your original request correctly about ip
> routing. Not sure the 104/204 is grunty enough to deal with multiple
> internet tables.
However, based on feedback received from people who have been running Juniper
for a long time, and reading what folks have been saying here and elsewhere, we
feel that it’s just too risky to put this stuff anywhere else.
We have been using Juniper since 2003 and that is definitely _not_ my
Hi,
> On Sep 18, 2019, at 5:15 PM, Howard Leadmon wrote:
>
>
> I am looking to replace an older Cisco I have sitting down in Equinix, and
> have l have had a few tell me that I should look at the Juniper routers as
> well.
Diving into Juniper/JunOS isn’t for the faint of heart. It’s a
I am looking to replace an older Cisco I have sitting down in
Equinix, and have l have had a few tell me that I should look at the
Juniper routers as well. I need a router with at least eight 10GE
ports (12 to 16 is desirable), so the option for more would be nice,
plus I also need dozen
36 matches
Mail list logo
