[j-nsp] EX4550 and MX104

Pavel Lunin plunin at gmail.com
Tue Jul 17 18:17:21 EDT 2018


Richard McGovern <rmcgovern at juniper.net>:

> Felt need to jump in here, and hopefully get some of the real facts
> straight.  Prior to ELS CLI Juniper had basically 2 different CLI’s – one
> for EX Products and branch SRX one for MX and a like.  M/MX CLI came first
> and used the terminology IRB and Bridge Domains.  These products were
> designed for primarily L3, and L2 was added later.  I think this started in
> like mid-1990s.
>

I am not sure that the MX logic is from the 1990s. It should be first
released with the MX in... was it 2006 or 2007? While the first EX came
around in 2008. Not that big gap between the two.

For both it was the era when the term "VLAN" was already widely used. And
in fact the MX model is good, despite it doesn't use this common term.

The word "VLAN" often leads to misunderstanding, as it might mean both, a
802.1Q interface tag and a broadcast domain, while there is absolutely no
reason to have the a common semantics for these two things. So the MX logic
seems to be intentionally designed as such. Much like SROS "VPLS" thing.
For the SP world it's just OK.

However, EX is an enterprise switch, at least it was originally targeting
the campus market, where folks want something simple and more or less
cisco-like.

So, I think (I know, in fact), the real reason behind the two cli models
was the strong internal SP/enterprise division inside Juniper. It was just
different people who designed MX and EX.

Now fast forward to 2013.  Juniper had some decisions to be made with
> regards to future platforms and strategic direction.  Be it good or bad,
> Juniper decided on 2 approaches.  1 a common CLI for all future products
> (and therefore some new ‘name’), and to move away from Marvell and onto
> Broadcom as a strategic 3rd party chip vendor.  This was especially for
> price competitive products, like L2 (and TOR) switches.  The new [ELS] CLI
> was/is based more on MX, than older original EX for a variety of reasons,
> be they now good or bad.  This is the reason that the new Broadcom based
> switches have a different [ELS based] CLI that the original EX switches.
> So, the original EX CLI and newer ELS based CLI are 100% based upon
> hardware platform in use, and not SW release, and do not BREAK anything
> from working.


So yes, Juniper still has two models: ELS is "based more on MX" but it's
not really MX-like. Three in fact, Marvel-based EX are not EoL.

While you are right about the fact that a given EX box supports either one
model or another and not both, this change has nothing to do with the
Marvel to Broadcom migration. It's purely software and, as you said, there
are some EoL boxes which have seen both. It rather looks like Juniper said
to themselves that they lost the enterprise market anyway, and for the DC
MX-like model should be a bit better.

However the problem is that the folks who design and sell boxes have no
idea what people use them for. <torvalds-mode polite="on"> When you have
200 or 2000 EX4550/EX4200 in production (together with a lot of other gear)
and at some point your Juniper SE tells you "Hey, buy rather EX4600/EX4300
instead, it's the never version, EX4550 will be EoL in some time", you
expect to have some level of consistency between the two. OK, it's
understandable that a FRS software can't support all the features of a
10-years old box but having to change vlan.X to irb.X just because MX uses
irb, is a bit too much. What is MX? Haven't I bought EX? Why do I need to
know the whole story of Juniper Networks to put a damn Ethernet switch in
production? And the on-call NOC guys at 2 am care even less about strategic
decisions, which Juniper has made.</torvalds-mode>

> One difference is Juniper now has one solid CLI moving forward.

Hey, it's not 2004 out there! EX9200 is like an MX but not quite when it
comes to the switching CLI. SRX5k is also like an MX but also not quite...
but in a different way. SRX branch? Old ones or new ones? One solid CLI?
Come on!

--
Pavel


More information about the juniper-nsp mailing list