[j-nsp] Juniper vs Arista

[Colton Conor]

We have used Juniper for a long time across various lines. What I have
noticed is on the JTAC recommend version website piratically all of their
product lines are running on different code trains. They all run Junos yes,
but they all have different features. It seems like Juniper has a different
software development team for every product.

Arista's sales engineering are claiming that their entire product line runs
EOS, and there is a single firmware file for all products. Does anyone know
if that is true, and how that compares to the way Juniper does things?
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Jared Mauch]

Post by Colton Conor
We have used Juniper for a long time across various lines. What I have
noticed is on the JTAC recommend version website piratically all of their
product lines are running on different code trains. They all run Junos yes,
but they all have different features. It seems like Juniper has a different
software development team for every product.

There tends to be common code (vendors call it their platform independent or similar)
For features like BGP, etc..

Where it goes into the hardware, you have platform dependent code that deals with the specific hardware.

Post by Colton Conor
Arista's sales engineering are claiming that their entire product line runs
EOS, and there is a single firmware file for all products. Does anyone know
if that is true, and how that compares to the way Juniper does things?

You tend to see different software types based on the hardware involved (eg: x86 vs non-x86) as this is necessary. Juniper has shipped more than one CPU type, so there’s different images. Much of this is semantics, but a lot can be said about having a strong central engineering team at companies that keep things from going too far off the rails. Cisco has it far worse than Juniper, but Juniper also has way more product lines than it did in the 90s.

Personally I really like Arista but also like JunOS based on my use case.

What are your goals? This may help answer this question better.

I believe there’s also arista-nsp on here..

- Jared
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puc

[Mark Tinka]

Post by Jared Mauch
Personally I really like Arista but also like JunOS based on my use case.

What we can be certain of is that the small companies become big
successful ones, grow, and then have to sacrifice a bit of their earlier
principles to maintain the new lifestyle. So it would not surprise me if
Arista decide to fork the code depending on what happens with their
product lines in the future. To be honest, I've learned that it's not
worth trying to tie them down to this; they are running a business after
all.

Your best defence is to understand the platform, and understand the
vendor's behaviours.

Post by Jared Mauch
I believe there’s also arista-nsp on here..

Is there?

I checked last year and couldn't find anything. Do you have a link?

Mark.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinf

[Gert Doering]

Hi,

Post by Mark Tinka

I believe there???s also arista-nsp on here..

I checked last year and couldn't find anything. Do you have a link?

Mailman claims "there isn't yet", but if Jared would add one, I'd
subscribe :-)

https://puck.nether.net/mailman/listinfo/

gert

[Mark Tinka]

Post by Gert Doering
Mailman claims "there isn't yet", but if Jared would add one, I'd
subscribe :-)
https://puck.nether.net/mailman/listinfo/

As would I...

The Arista code is so Cisco-like, and in our use-case, has done
everything as advertised in the manuals and in the "Arista Warrior"
O'Reilly publication. So we haven't had to struggle... but then again,
our deployment is very simple - Layer 2 core switching.

But I'd certainly like yet-another-place to b**ch and moan about my new
vendor, Arista :-)...

Mark.

[Saku Ytti]

Post by Mark Tinka
The Arista code is so Cisco-like, and in our use-case, has done
everything as advertised in the manuals and in the "Arista Warrior"
O'Reilly publication. So we haven't had to struggle... but then again,
our deployment is very simple - Layer 2 core switching.

I know what you mean, but 'code is Cisco-like' may not be read as
positive by every recipient. I think you more accurately mean 'CLI is
like classic IOS'.

ANET does not have much run way until they are forced to two image
future, due to 64b control-planes. Not that I care about at all how
many images vendors ship. Lot of it is just smoke and mirrors, like
inflating single package with mostly useless content to make it seem
like single image fits all.
Perhaps in future it's all very small (<5 0M) net install image, then
DEB/RPM all packages via local proxy to have functioning install for
specific target, with specific forwarding engines.

[Sebastian Wiesinger]

Post by Saku Ytti

Post by Mark Tinka
The Arista code is so Cisco-like, and in our use-case, has done
everything as advertised in the manuals and in the "Arista Warrior"
O'Reilly publication. So we haven't had to struggle... but then again,
our deployment is very simple - Layer 2 core switching.

I know what you mean, but 'code is Cisco-like' may not be read as
positive by every recipient. I think you more accurately mean 'CLI is
like classic IOS'.

Do they have commit capability?

Regards

Sebastian

[Mark Tinka]

Post by Sebastian Wiesinger
Do they have commit capability?

https://eos.arista.com/config-sessions-tips/

Mark.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Saku Ytti]

Post by Sebastian Wiesinger
Do they have commit capability?

Yes, and it works.

In IOS-XR commit doesn't inherently work, because of how it's
designed. In JunOS commit inherently works. In IOS-XR BGP team owns
commit for BGP config, tunnel team owns commit for GRE, it's not
generic infrastructure issue if A=>B doesn't work, that's problem for
specific component team. So you can find these impossible configs in
IOS-XR quite often, where you cannot move from arbitrary A to
arbitrary B.

Good acid test for sanity of design 'can I get output of _every_
command in serialised format', <100% coverage means poor and expensive
to maintain design.

Note, this is not trash on IOS-XR, you can find another argument where
JunOS and EOS look poor and IOS-XR looks great, it's merely topical
and important-to-me feature to get right. If you're CLI jockey
network, like most networks are, then it's not very important thing to
get right.

[Gert Doering]

Hi,

Post by Sebastian Wiesinger
Do they have commit capability?

Yes, optional. You either do "conf term" just like on IOS, or you do
"conf session" which needs commit.

Which is really really nice - if I do troubleshooting, I want a
"interface foo / shut / no shut" to have effect right away without
minute-long commit waits - and for larger change blocks ("bgp neighbor"
comes to mind), commit is good :-)

Which is sort of what stuck after our Arista POC: it's like IOS with
lots of useful enhancements, and without the annoying "I refuse to
do things, because I am right and you are wrong" attitude of JunOS.

gert

[Mark Tinka]

Post by Gert Doering
Which is sort of what stuck after our Arista POC: it's like IOS with
lots of useful enhancements, and without the annoying "I refuse to
do things, because I am right and you are wrong" attitude of JunOS.

The t-shirt is going to print :-)...

Mark.

[Mark Tinka]

Post by Saku Ytti
I know what you mean, but 'code is Cisco-like' may not be read as
positive by every recipient. I think you more accurately mean 'CLI is
like classic IOS'.

This... as in, "it's not much to learn". Very different under the hood,
obviously, but on top, it's not as foreign as coming from a Cisco world
into a Juniper one.

Post by Saku Ytti
ANET does not have much run way until they are forced to two image
future, due to 64b control-planes. Not that I care about at all how
many images vendors ship. Lot of it is just smoke and mirrors, like
inflating single package with mostly useless content to make it seem
like single image fits all.

Agreed.

Post by Saku Ytti
Perhaps in future it's all very small (<5 0M) net install image, then
DEB/RPM all packages via local proxy to have functioning install for
specific target, with specific forwarding engines.

Probably.

Mark.

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

[a***@netconsultings.com]

Of Saku Ytti
Sent: Tuesday, August 14, 2018 9:31 AM
Perhaps in future it's all very small (<5 0M) net install image, then

DEB/RPM

all packages via local proxy to have functioning install for specific

target, with

specific forwarding engines.

Cisco is certainly on the right track with the flexible packaging in 64 bit
XR (though the mini ISO is nowhere near 5Meg ).

adam

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


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

[Tobias Heister]

Post by Mark Tinka

Post by Gert Doering
Mailman claims "there isn't yet", but if Jared would add one, I'd
subscribe :-)
https://puck.nether.net/mailman/listinfo/

As would I...

+1

[Jared Mauch]

Fixed.

https://puck.nether.net/mailman/listinfo/arista-nsp

Post by Mark Tinka

Post by Gert Doering
Mailman claims "there isn't yet", but if Jared would add one, I'd
subscribe :-)
https://puck.nether.net/mailman/listinfo/

As would I...
The Arista code is so Cisco-like, and in our use-case, has done everything as advertised in the manuals and in the "Arista Warrior" O'Reilly publication. So we haven't had to struggle... but then again, our deployment is very simple - Layer 2 core switching.

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

[Mark Tinka]

Good man :-)!

Mark.

Post by Jared Mauch
Fixed.
https://puck.nether.net/mailman/listinfo/arista-nsp

Post by Mark Tinka

Post by Gert Doering
Mailman claims "there isn't yet", but if Jared would add one, I'd
subscribe :-)
https://puck.nether.net/mailman/listinfo/

As would I...
The Arista code is so Cisco-like, and in our use-case, has done everything as advertised in the manuals and in the "Arista Warrior" O'Reilly publication. So we haven't had to struggle... but then again, our deployment is very simple - Layer 2 core switching.

.

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

[Mark Tinka]

Let me make some noise about this in my region...

Mark.

Post by Mark Tinka
Good man :-)!
Mark.

Post by Jared Mauch
Fixed.
https://puck.nether.net/mailman/listinfo/arista-nsp

Post by Mark Tinka

Post by Gert Doering
Mailman claims "there isn't yet", but if Jared would add one, I'd
subscribe :-)
https://puck.nether.net/mailman/listinfo/

As would I...
The Arista code is so Cisco-like, and in our use-case, has done everything as advertised in the manuals and in the "Arista Warrior" O'Reilly publication. So we haven't had to struggle... but then again, our deployment is very simple - Layer 2 core switching.

.

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

[Gert Doering]

Hi,

Post by Colton Conor
Arista's sales engineering are claiming that their entire product line runs
EOS, and there is a single firmware file for all products. Does anyone know
if that is true, and how that compares to the way Juniper does things?

This is true, so for "control plane" features, you can basically rely
on the same things being available everywhere.

Now, "data plane" - like, "can this box do MPLS? can it do SVI counters?" -
depends a lot on the unterlying hardware. So even if you have the same
EOS on top, one box will do MPLS, and another box will not. (And part
of that is "product management", that is, the Trident II+ boxes will
not do MPLS because "buy a bigger one if you want that", even if the
hardware could support some basic set of MPLS features)

So: you still need to test box vs. features you need.

gert

[Mark Tinka]

Post by Colton Conor
We have used Juniper for a long time across various lines. What I have
noticed is on the JTAC recommend version website piratically all of their
product lines are running on different code trains. They all run Junos yes,
but they all have different features. It seems like Juniper has a different
software development team for every product.
Arista's sales engineering are claiming that their entire product line runs
EOS, and there is a single firmware file for all products. Does anyone know
if that is true, and how that compares to the way Juniper does things?

It is true that Arista currently have a single image for EOS across
their platforms.

But if I'm honest, I don't put a lot of stock in this. If you remember,
this was Juniper's line back in the day, "One Junos to rule them all".
Well, things obviously took another turn when they introduced the MX and
EX platforms around 2007/2008.

Ultimately, know your platform, understand your vendor, and don't get
caught in the hype. We already have far less time in the day as it is.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Pavel Lunin]

Post by Mark Tinka
But if I'm honest, I don't put a lot of stock in this. If you remember,
this was Juniper's line back in the day, "One Junos to rule them all".
Well, things obviously took another turn when they introduced the MX and
EX platforms around 2007/2008.

Moreover, as we've discussed a few weeks ago, the "single software über
alles" strategy might be just a dumb idea.

ScreenOS to JUNOS migration is a good example. Juniper basically lost the
firewall as well as small software routers markets by trying to fit all
into a single package. And now, look, MX150 is the new J4300 :)

Not sure, but from the first glance it doesn't look like they've gained
more than they've lost with the JunosE to JUNOS BNG migration.

The whole Juniper's enterprise market failure is all about "single JUNOS
doesn't fit all": WX, SSL VPN, IPS, Wi-Fi, etc etc etc.

And yes, Arista will face the same challenge when they buy someone like
Fortinet to expand beyond the niche where they are by the moment.

--
Pavel
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/

[Andrey Kostin]

Post by Pavel Lunin
Not sure, but from the first glance it doesn't look like they've gained
more than they've lost with the JunosE to JUNOS BNG migration.

I didn't miss JunosE any single day after we finished migration to MX.
MX platform is not ideal and has it's own quirks but I doubt that ideal
BNG exists.

[Saku Ytti]

Post by Andrey Kostin

Post by Pavel Lunin
Not sure, but from the first glance it doesn't look like they've gained
more than they've lost with the JunosE to JUNOS BNG migration.

I didn't miss JunosE any single day after we finished migration to MX.
MX platform is not ideal and has it's own quirks but I doubt that ideal
BNG exists.

I think Pavel's comment was less about technical merits or any
objective product quality, and more about how people react to change.
If you are comfortable with ScreenOS, you keep recommending it to your
customers, if it disappears from market, you don't consider just SRX,
you consider whole market and then stick on that platform.

[Pavel Lunin]

Post by Andrey Kostin

Post by Pavel Lunin
Not sure, but from the first glance it doesn't look like they've gained
more than they've lost with the JunosE to JUNOS BNG migration.

I didn't miss JunosE any single day after we finished migration to MX.
MX platform is not ideal and has it's own quirks but I doubt that ideal
BNG exists.

The first version of my reply was "...JunosE (yes, it was crap) to JUNOS
BNG migration". I finally removed the note in parentheses for the sake of
politeness :)

Saku got it right. It's not about what I like more - of course JunosE CLI
was a nightmare - it's about getting from something which works for a lot
of people to something which looks perfect in the imperfect world.

Finally the goal of this migration was to have one product instead of two,
which is easier to maintain, simpler to use and, consequently, more
interesting for customers, thus its market share should be higher.

I am not saying that JunosE to JUNOS BNG transition was a fail but I
honestly doubt that they reached the initial goals. It's the same hardware
now, however the BNG feature set is in fact a standalone subsystem in
Junos. I would only say thank you to Juniper if we had a no-BNG version of
JUNOS for MX series. And I really wonder if they won or lost market share
with this migration.

However for ScreenOS to SRX I know for sure that it's a fail. Enterprise
security people need a simple webui, comprehensive IPS signature manager,
online log with filters, cool dashboard and other bullshit to impress
bosses. JUNOS with its commits, full featured routing protocols and all the
stuff we love is technically better from a networker's point of view (not
taking into account all the bugs and missing feathers on the way to the
current state) but it's just a different product, targeting different
customers. So sometimes two software packages are better than one.

--
Cheers,
Pavel
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Mark Tinka]

Post by Pavel Lunin
I am not saying that JunosE to JUNOS BNG transition was a fail but I
honestly doubt that they reached the initial goals. It's the same hardware
now, however the BNG feature set is in fact a standalone subsystem in
Junos. I would only say thank you to Juniper if we had a no-BNG version of
JUNOS for MX series. And I really wonder if they won or lost market share
with this migration.

I know a network in South East Asia that went from Redback + JunosE back
in 2012 to Junos BNG on the MX. They are now kicking that out and going
to Huawei.

It's been 6 years of hell, according to them.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp