Discussion:
[j-nsp] EX4550 and MX104
Aaron Gould
2018-07-12 17:19:13 UTC
Permalink
I hear some chatter about systems getting old and incapable and allegedly being end of life or end of serviced... I just saw these links, dated July 10, 2018 so very recent, they mentioned how this company is using these two platforms for financial and government critical sectors.

https://investor.juniper.net/investor-relations/press-releases/press-release-details/2018/ESDS-Selects-Juniper-Networks-to-Power-Future-Ready-Cloud-in-India/default.aspx

https://www.google.com/amp/s/www.zacks.com/amp/stock/news/310933/juniper-provides-improved-cloud-application-delivery-to-esds

Aaron
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Pavel Lunin
2018-07-12 21:07:49 UTC
Permalink
On Thu, Jul 12, 2018 at 7:19 PM, Aaron Gould <***@gvtc.com> wrote:

> I hear some chatter about systems getting old and incapable and allegedly
> being end of life or end of serviced... I just saw these links, dated July
> 10, 2018 so very recent, they mentioned how this company is using these two
> platforms for financial and government critical sectors.
>

That's normal. Government and financial sectors always use the most
outdated solutions because of bureaucracy, compliance, certifications and
all those WTF reasons :)
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Mark Tinka
2018-07-16 13:25:38 UTC
Permalink
On 12/Jul/18 23:07, Pavel Lunin wrote:

> That's normal. Government and financial sectors always use the most
> outdated solutions because of bureaucracy, compliance, certifications and
> all those WTF reasons :)

Probably with a big fat vendor (or vendor-partner) 10-year management &
support contract to boot :-)...

Mark.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Pavel Lunin
2018-07-17 08:30:39 UTC
Permalink
Mark Tinka <***@seacom.mu>:

>
>
> On 12/Jul/18 23:07, Pavel Lunin wrote:
>
> That's normal. Government and financial sectors always use the most
> outdated solutions because of bureaucracy, compliance, certifications and
> all those WTF reasons :)
>
>
> Probably with a big fat vendor (or vendor-partner) 10-year management &
> support contract to boot :-)...
>


Or because they just don't want to bother with the new Junos switching CLI
for Broadcom-based models ;)
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Mark Tinka
2018-07-17 08:52:24 UTC
Permalink
On 17/Jul/18 10:30, Pavel Lunin wrote:

>
>
> Or because they just don't want to bother with the new Junos switching
> CLI for Broadcom-based models ;)

Well, looks like Juniper are horny for that moving forward, so the only
solution there is to move to another vendor :-).

Mark.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Pavel Lunin
2018-07-17 09:24:18 UTC
Permalink
On Tue, Jul 17, 2018 at 10:52 AM, Mark Tinka <***@seacom.mu> wrote:

>
> Or because they just don't want to bother with the new Junos switching CLI
> for Broadcom-based models ;)
>
>
> Well, looks like Juniper are horny for that moving forward, so the only
> solution there is to move to another vendor :-).
>


Honestly, I don't feel like the new CLI model is broken. For me it rather
looks like change everything just to change everything.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Gert Doering
2018-07-17 09:47:56 UTC
Permalink
Hi,

On Tue, Jul 17, 2018 at 11:24:18AM +0200, Pavel Lunin wrote:
> Honestly, I don't feel like the new CLI model is broken. For me it rather
> looks like change everything just to change everything.

And that makes it "non-broken", why?

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany ***@greenie.muc.de
Mark Tinka
2018-07-17 11:06:24 UTC
Permalink
On 17/Jul/18 11:24, Pavel Lunin wrote:

>
>
> Honestly, I don't feel like the new CLI model is broken. For me it
> rather looks like change everything just to change everything.

The new CLI, in itself, isn't broken. What it does is break the old CLI.

IOS to IOS XR is one thing. But even they didn't break IOS to IOS XE.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Richard McGovern
2018-07-17 14:24:59 UTC
Permalink
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.

From there the industry started to use VLANs for L2, and VLANs with associated Routing for L3 Switching. When Juniper developed their original EX Access switch product line they choose to use the now common term VLAN in their CLI, as these devices are primarily used for L2. This time frame was around 2008/9. This now made the original EX CLI different than the M/MX Junos CLI.

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. You cannot change from one CLI to the other via Junos SW code release changes. This CLI change only happens when one switches to a different newer hardware platform.

Does this make the transition a little more difficult, yes. This is really no different, IMHO, then CISCO CAT CLI, vs IOS CI, etc. One difference is Juniper now has one solid CLI moving forward. I am not sure CISCO could make the same claim.

FACT – all Juniper Broadcom based devices, outside of original QFX3500/3600 (not even 100% sure if Broadcom based) use only the newer ELS based CLI. Same as true for all newer and future Junos based devices.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.ne
Mark Tinka
2018-07-17 14:34:31 UTC
Permalink
On 17/Jul/18 16:24, Richard McGovern wrote:

> 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.
>
> From there the industry started to use VLANs for L2, and VLANs with associated Routing for L3 Switching. When Juniper developed their original EX Access switch product line they choose to use the now common term VLAN in their CLI, as these devices are primarily used for L2. This time frame was around 2008/9. This now made the original EX CLI different than the M/MX Junos CLI.
>
> 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. You cannot change from one CLI to the other via Junos SW code release changes. This CLI change only happens when one switches to a different newer hardware platform.
>
> Does this make the transition a little more difficult, yes. This is really no different, IMHO, then CISCO CAT CLI, vs IOS CI, etc. One difference is Juniper now has one solid CLI moving forward. I am not sure CISCO could make the same claim.
>
> FACT – all Juniper Broadcom based devices, outside of original QFX3500/3600 (not even 100% sure if Broadcom based) use only the newer ELS based CLI. Same as true for all newer and future Junos based devices.

Thanks, Richard, for stepping in/up and contributing to this discussion.
Nothing beats the horses' mouth!

I'm sure Juniper's decision process was very clear in their mind, and no
one can fault them for that. You're a business, and you have the make
the best call you possibly can for the future of your concern.

The bottom line is that for some of us that found the previous CLI
simpler, and don't see the actual benefit in overly complicating it with
ELS for some (not all) of the functionality we employed, our decision
process was just as clear.

I have no doubt that the new-generation Broadcom-based platforms will do
as well as the outgoing Marvell units. It's just a pity that we won't be
on that train; but sometimes, that's just how it goes.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https:/
Richard McGovern
2018-07-17 15:10:28 UTC
Permalink
Agree. Can’t please everyone all the time.

Sent from my iPhone

> On Jul 17, 2018, at 10:34 AM, Mark Tinka <***@seacom.mu> wrote:
>
>
>
> On 17/Jul/18 16:24, Richard McGovern wrote:
>
>> 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.
>>
>> From there the industry started to use VLANs for L2, and VLANs with associated Routing for L3 Switching. When Juniper developed their original EX Access switch product line they choose to use the now common term VLAN in their CLI, as these devices are primarily used for L2. This time frame was around 2008/9. This now made the original EX CLI different than the M/MX Junos CLI.
>>
>> 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. You cannot change from one CLI to the other via Junos SW code release changes. This CLI change only happens when one switches to a different newer hardware platform.
>>
>> Does this make the transition a little more difficult, yes. This is really no different, IMHO, then CISCO CAT CLI, vs IOS CI, etc. One difference is Juniper now has one solid CLI moving forward. I am not sure CISCO could make the same claim.
>>
>> FACT – all Juniper Broadcom based devices, outside of original QFX3500/3600 (not even 100% sure if Broadcom based) use only the newer ELS based CLI. Same as true for all newer and future Junos based devices.
>
> Thanks, Richard, for stepping in/up and contributing to this discussion. Nothing beats the horses' mouth!
>
> I'm sure Juniper's decision process was very clear in their mind, and no one can fault them for that. You're a business, and you have the make the best call you possibly can for the future of your concern.
>
> The bottom line is that for some of us that found the previous CLI simpler, and don't see the actual benefit in overly complicating it with ELS for some (not all) of the functionality we employed, our decision process was just as clear.
>
> I have no doubt that the new-generation Broadcom-based platforms will do as well as the outgoing Marvell units. It's just a pity that we won't be on that train; but sometimes, that's just how it goes.
>
> Mark.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.n
Tobias Heister
2018-07-17 16:43:21 UTC
Permalink
Hi,

On 17.07.2018 16:24, Richard McGovern wrote:
> 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. You cannot change from one CLI to the other via Junos SW code release changes. This CLI change only happens when one switches to a different newer hardware platform.

Not 100% true. At least QFX3500/3600 had non ELS Junos version (with and without qfabric) and switched to ELS at one point via software upgrade. But they are EOL by now.
We had to convert configuration when switching from qfabric to VC when we reused our QFX3500/3600.

https://forums.juniper.net/jnet/attachments/jnet/switch/17322/1/Getting%20Started%20with%20Enhanced%20Layer%202%20Software%20-%20Technical%20Documentation%20-%20Support%20-%20Juniper%20Networks.pdf
> ELS is supported on the EX4300, EX4600, and EX9200 switches for all Junos OS releases, starting with the initial releases shown in Table 1.
> ELS support was introduced on QFX3500 and QFX3600 switches in Junos OS Release 13.2X50-D15. ELS is only supported on the software package that supports
> Virtual Chassis (the jinstall-qfx-3-* software package) for QFX3500 and QFX3600 switches.
> For QFX5100 switches, ELS support was introduced in Junos OS Release 13.2X51-D10 and is supported on the jinstall-qfx-5-* software package

This might indicate that for a short period even QFX5100 did have non ELS software, but i do not remember 100% anymore.

https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/getting-started-els.html#id-understanding-the-els-translator
has a chapter about translating as well:
> If you are upgrading from a version of Junos OS that does not support ELS to a version of Junos OS that supports ELS, we recommend that you update your configuration with the ELS Translator using the following procedure:


--
regards
Tobias
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Richard McGovern
2018-07-17 16:46:37 UTC
Permalink
QFX3500/3600 might have been the only platform where SW change introduced ELS CLI, but as you mentioned they are EOL now. QFX5100, and all other QFX platforms (outside of QFX3500/3600) supported ELS CLI only from day 1.

On 7/17/18, 12:43 PM, "Tobias Heister" <***@tobias-heister.de> wrote:

Hi,

On 17.07.2018 16:24, Richard McGovern wrote:
> 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. You cannot change from one CLI to the other via Junos SW code release changes. This CLI change only happens when one switches to a different newer hardware platform.

Not 100% true. At least QFX3500/3600 had non ELS Junos version (with and without qfabric) and switched to ELS at one point via software upgrade. But they are EOL by now.
We had to convert configuration when switching from qfabric to VC when we reused our QFX3500/3600.

https://forums.juniper.net/jnet/attachments/jnet/switch/17322/1/Getting%20Started%20with%20Enhanced%20Layer%202%20Software%20-%20Technical%20Documentation%20-%20Support%20-%20Juniper%20Networks.pdf
> ELS is supported on the EX4300, EX4600, and EX9200 switches for all Junos OS releases, starting with the initial releases shown in Table 1.
> ELS support was introduced on QFX3500 and QFX3600 switches in Junos OS Release 13.2X50-D15. ELS is only supported on the software package that supports
> Virtual Chassis (the jinstall-qfx-3-* software package) for QFX3500 and QFX3600 switches.
> For QFX5100 switches, ELS support was introduced in Junos OS Release 13.2X51-D10 and is supported on the jinstall-qfx-5-* software package

This might indicate that for a short period even QFX5100 did have non ELS software, but i do not remember 100% anymore.

https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/getting-started-els.html#id-understanding-the-els-translator
has a chapter about translating as well:
> If you are upgrading from a version of Junos OS that does not support ELS to a version of Junos OS that supports ELS, we recommend that you update your configuration with the ELS Translator using the following procedure:


--
regards
Tobias


_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Gert Doering
2018-07-17 19:41:30 UTC
Permalink
Hi,

On Tue, Jul 17, 2018 at 04:46:37PM +0000, Richard McGovern wrote:
> QFX3500/3600 might have been the only platform where SW change introduced ELS CLI, but as you mentioned they are EOL now. QFX5100, and all other QFX platforms (outside of QFX3500/3600) supported ELS CLI only from day 1.

Doesn't make some of the decisions in the ELS code any nicer.

Like, inability to configure "set protocols vstp vlan all" and be done
with "have I remembered to turn on vstp for this new VLAN?" - different
*syntax* for things is fine and dandy, but taking away functionality that
people use "just because different" is not how you make happy customers.

Or having XML output change - this is about the second most annoying
part. Everybody tells me how great netconf and XML is and that I should
use that to query stuff, and then basic XML tags change their name
depending on whether I query a EX3300 or EX4600 switch.

(And no, you can't compare this to "this is like Cisco CatOS vs. Cisco IOS",
because "that was a different operating system, where everything was totally
different" - inside IOS for switches, such a silly and needless change has
*never* happened)

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany ***@greenie.muc.de
Mark Tinka
2018-07-17 21:59:57 UTC
Permalink
On 17/Jul/18 21:41, Gert Doering wrote:

> (And no, you can't compare this to "this is like Cisco CatOS vs. Cisco IOS",
> because "that was a different operating system, where everything was totally
> different" - inside IOS for switches, such a silly and needless change has
> *never* happened)

It's very unlikely that Juniper arrived at this decision on the basis
that "CatOS was ditched for IOS". This is why I didn't even bother
raising the point in my response to Richard.

As my Swedish friend would say, "It is what it is". Just move on and
vote with your feet...

Mark.
Pavel Lunin
2018-07-17 22:17:21 UTC
Permalink
Richard McGovern <***@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
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
h
Richard McGovern
2018-07-18 02:50:13 UTC
Permalink
From: Pavel Lunin <***@gmail.com>
Date: Tuesday, July 17, 2018 at 6:17 PM
To: Richard McGovern <***@juniper.net>
Cc: juniper-nsp <juniper-***@puck.nether.net>
Subject: Re: [j-nsp] EX4550 and MX104

#1 – I do not make the news, I only report it. #2, it is impossible to keep everyone happy all of the time. I have learned that over almost 40 years in networking, . . . As well the really important stuff comes after the sale, not before.

Richard McGovern <***@juniper.net<mailto:***@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.


ð First came M before MX in mid-90s, I believe.

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.

=>Agreed, and fortunately all those people are now gone within Juniper.

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.


ð I repeat. Agreed, and fortunately all those people are now gone within Juniper.

ð

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



_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/ma
Gert Doering
2018-07-18 06:36:34 UTC
Permalink
Hi,

On Wed, Jul 18, 2018 at 02:50:13AM +0000, Richard McGovern wrote:
> As well the really important stuff comes after the sale, not before.

Yeah. JTAC really excels on this.

(We have an open case where SNMP on *some* EX4600 is abysmally slow while
the same queries on other EX4600 with the same software / SNMP config
behave quite normally. Not proceeding in meaningful ways since half
a year...)

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany ***@greenie.muc.de
Jimmy
2018-07-18 23:47:43 UTC
Permalink
We encountered this on T1600 chassis.
After months troubleshooting, i discovered myself it is due to some
monitoring system were still polling using snmp v1. After all changed to
v2c. Problem resolved.
As usual JTAC would suspect here and there, and luckyly i have another
chassis with identical software / config but not affected as comparison.

On Wed, 18 Jul 2018 at 14:37, Gert Doering <***@greenie.muc.de> wrote:

> Hi,
>
> On Wed, Jul 18, 2018 at 02:50:13AM +0000, Richard McGovern wrote:
> > As well the really important stuff comes after the sale, not before.
>
> Yeah. JTAC really excels on this.
>
> (We have an open case where SNMP on *some* EX4600 is abysmally slow while
> the same queries on other EX4600 with the same software / SNMP config
> behave quite normally. Not proceeding in meaningful ways since half
> a year...)
>
> gert
> --
> "If was one thing all people took for granted, was conviction that if you
> feed honest figures into a computer, honest figures come out. Never
> doubted
> it myself till I met a computer with a sense of humor."
> Robert A. Heinlein, The Moon is a Harsh
> Mistress
>
> Gert Doering - Munich, Germany
> ***@greenie.muc.de
> _______________________________________________
> juniper-nsp mailing list juniper-***@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Pavel Lunin
2018-07-18 16:03:19 UTC
Permalink
> Richard McGovern <***@juniper.net>:
>
> 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.
>>
>
>
> ð First came M before MX in mid-90s, I believe.
>

I might be wrong but if memory serves, M/T had no ethernet switching. So
all this bridge-domain machinery should have come around with the MX
series. It's not legacy but intentionally designed to be like this, as it's
SP-oriented.

And yeah, I forgot that MX also has two Ethernet switching config styles.
So... I am out of fingers to count the ether-switching config styles in
JUNOS. And it's OK, in fact. The point of this discussion is that adding
more instances is not the right way to reduce the number of them. And it's
arguable if it really needs to be reduced. JUNOS has always been known to
have multiple ways to do the same thing. And it's OK.



> 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.
>>
>
>
> ð I repeat. Agreed, and fortunately all those people are now gone
> within Juniper.
>

I am not sure that it's about people. I'd say it's more general story of
trying to repeat the M/T/MX/JUNOS success with other products.

Back in the early 2000s Juniper managed to revolutionize software design
for Service Provider routers. This is where the company feels safe and
knows what it does.

Look how much attention Juniper pays to user behavior consistency of the SP
products. I am too lazy to check but I am sure that there are still spare
parts for M/T available for purchase. This "per-packet" which is not really
per-packet but per-flow ECMP thing is pure legacy and could be changed
easily, but behavior consistency is the king. 64 bit RE for M7i when
everyone seemed to forget what M7i was. Lots of such examples in the M/T/MX
world. And it's good, it works.

However when it comes to the non-SP/DC world, it's just the opposite.
ScreenOS to SRX migration. WiFi. SSL VPN. Traffic Optimization. Space. J
Series. CDN caching. SRX media gateway. I am sure, I forgot something. I
doubt that it was the same people who killed those products.

It's not comparable with the MX as a business. So let's mess everything up
twice a year, because "JUNOS was a success at the beginning, we want a
single JUNOS for everything, it must be a success again". Or just because
"it doesn't sale". But yes, if you change the product behavior twice a
year, it won't sale. ScreenOS had a kind of 30% of the market and SRX...
you know... Not because it's a bad firewall but because it was a lot of
pain at the time of that ScreenOS->JUNOS migration.

BTW, a few months ago I've promenaded around in one of the major European
telco sites just to have a look at what people had in their racks. Oh Dear,
I've seen A LOT of Netscreen/SSG/ISG and even a couple of J-series. Racked,
powered, blinking LEDs. This should be some OOB in most cases, I think, but
anyway, they are still here! I was impressed.
Mark Tinka
2018-07-19 04:58:25 UTC
Permalink
On 18/Jul/18 18:03, Pavel Lunin wrote:

> I might be wrong but if memory serves, M/T had no ethernet switching. So
> all this bridge-domain machinery should have come around with the MX
> series. It's not legacy but intentionally designed to be like this, as it's
> SP-oriented.

That's exactly the way I remembered it.

I mean, M/T had basic 802.1Q VLAN trunking support, but that was about it.

STP and them first appeared on the MX.

> And yeah, I forgot that MX also has two Ethernet switching config styles.
> So... I am out of fingers to count the ether-switching config styles in
> JUNOS. And it's OK, in fact. The point of this discussion is that adding
> more instances is not the right way to reduce the number of them. And it's
> arguable if it really needs to be reduced. JUNOS has always been known to
> have multiple ways to do the same thing. And it's OK.

+1.


> It's not comparable with the MX as a business. So let's mess everything up
> twice a year, because "JUNOS was a success at the beginning, we want a
> single JUNOS for everything, it must be a success again". Or just because
> "it doesn't sale". But yes, if you change the product behavior twice a
> year, it won't sale. ScreenOS had a kind of 30% of the market and SRX...
> you know... Not because it's a bad firewall but because it was a lot of
> pain at the time of that ScreenOS->JUNOS migration.

Don't remind me - just when we were about to settle on the J-series as a
route reflector, it went and became the SRX with firewall or packet mode.


> BTW, a few months ago I've promenaded around in one of the major European
> telco sites just to have a look at what people had in their racks. Oh Dear,
> I've seen A LOT of Netscreen/SSG/ISG and even a couple of J-series. Racked,
> powered, blinking LEDs. This should be some OOB in most cases, I think, but
> anyway, they are still here! I was impressed.

Doesn't surprise me, if I'm honest.

We still use the Cisco 7201 as looking glass routers, because they were
well built for purpose and were supported for a very long time. And even
when Cisco decided to stop forgetting about them, it was because you
knew they had squeezed them for all they were worth, and it was now time
for something else. Not these haphazard changes that you aptly describe
in this post.

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