Re: [j-nsp] EX4550 and MX104
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-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and MX104
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 wrote: > Hi, > > On Wed, Jul 18, 2018 at 02:50:13AM +, 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 > g...@greenie.muc.de > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and MX104
> Richard McGovern : > > 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. -- Pavel ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and MX104
Hi, On Wed, Jul 18, 2018 at 02:50:13AM +, 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 g...@greenie.muc.de signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and MX104
From: Pavel Lunin Date: Tuesday, July 17, 2018 at 6:17 PM To: Richard McGovern Cc: juniper-nsp 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 mailto:rmcgov...@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. 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. > 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-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and MX104
Richard McGovern : > 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. 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. > 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-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and MX104
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. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and MX104
Hi, On Tue, Jul 17, 2018 at 04:46:37PM +, 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 g...@greenie.muc.de signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and MX104
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" 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-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and MX104
Agree. Can’t please everyone all the time. Sent from my iPhone > On Jul 17, 2018, at 10:34 AM, Mark Tinka 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-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and MX104
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-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and MX104
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-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and MX104
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-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and MX104
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 g...@greenie.muc.de signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and MX104
On Tue, Jul 17, 2018 at 10:52 AM, Mark Tinka 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-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and MX104
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-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and MX104
Mark Tinka : > > > 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-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and MX104
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-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and MX104
On Thu, Jul 12, 2018 at 7:19 PM, Aaron Gould 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-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
