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
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] Netscreen-to-Junos Translation Tool
On Tue, Jul 17, 2018 at 07:48:52AM +, M Abdeljawad via juniper-nsp wrote: > Was checking portal for the Netscreen-Junos translation tool but was not > there, is it obsoleted? If I remember right, that tool was really Netscreen->JunOSe So, an obsolete target that was nothing like what an SRX is. At best these sorts of tools were an approximation. ___ 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] Netscreen-to-Junos Translation Tool
There is a tool available via the Juniper Partner site that helps with migrations from Netscreen to SRX. /Per > 17 juli 2018 kl. 15:54 skrev Doug McIntyre : > >> On Tue, Jul 17, 2018 at 07:48:52AM +, M Abdeljawad via juniper-nsp wrote: >> Was checking portal for the Netscreen-Junos translation tool but was not >> there, is it obsoleted? > > If I remember right, that tool was really Netscreen->JunOSe > > So, an obsolete target that was nothing like what an SRX is. > > At best these sorts of tools were an approximation. > > > > ___ > 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] QFX5100 vs ACX5048
Yes... Exactly. I upgraded to 17.3R2 and was a total mess. And had to downgrade to 15.1X train. On Wed, Jul 4, 2018 at 11:31 AM Colton Conor wrote: > Gustavo, > > We you say " Another problem was upgrading to the lastest Junos JTAC > recommended that made the ACX5048 unusable... ( Junos was unable to find > the physical ports..) We had to downgrade to get it back working again.." > what version was this as JTAC recently changed their recommended version? > It seem everyone on this thread is talking about software train 15.1X54. > > However, the current JTAC recommended version is Junos 17.3R2 as of 14 May > 2018. Why is everyone running 15.1X54 code? > > Has anyone upgraded to Junos 17.3R2 on the ACX's? No matter the model, > all ACX's current recommended is now Junos 17.3R2 > > > On Mon, Jul 2, 2018 at 8:11 AM, Gustavo Santos > wrote: > >> I had some issues with ACX5048 , the most noticable was arp packets from >> pure L2 vlans and VPLS punting to CPU and flooding the default arp policer >> police.. >> JTAC was able to reproduce the issue and gave us an option to disable >> default arp policer until they release a service release to fix this issue >> that was solved indeed. >> >> Another problem was upgrading to the lastest Junos JTAC recommended that >> made the ACX5048 unusable... ( Junos was unable to find the physical >> ports..) We had to downgrade to get it back working again.. >> >> On Sun, Jul 1, 2018 at 8:05 PM Alexandre Guimaraes < >> alexandre.guimar...@ascenty.com> wrote: >> >>> Better in terms of concept. In term of usage, i still investing in >>> qfx5100 >>> >>> Acx5058 Suppose to be a promise of a new future, unfortunately, with all >>> problematic of the qfx5100 hardware, the acx5048 leak vlan till the last >>> breath of cpu after that, all deamons and services going down up >>> and down, up and down. >>> >>> I never more brought one peace ACX5048 after jtac didnt responds why and >>> solution for the leaking...( I have only two acx5048 and hundreds on >>> QFX...). >>> >>> The new promise is the new acx5448. No vlan leaking, a good load >>> balance(ae) algorithm, full of this full of that a lot of promise. >>> >>> Let’s see... >>> >>> att >>> Alexandre >>> >>> Em 1 de jul de 2018, à(s) 19:31, Colton Conor >>> escreveu: >>> >>> > What is the main difference between these two boxes? Hardware wise they >>> > look identical. Is there anything on the hardware side that makes the >>> > ACX5048 better than a QFX5100, or is it only software related? >>> > ___ >>> > 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 >>> >> > ___ 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
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
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
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 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
[j-nsp] Netscreen-to-Junos Translation Tool
Hi Was checking portal for the Netscreen-Junos translation tool but was not there, is it obsoleted? Thanks RegardsMahmoud ___ 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] Is it possible to pass apostrophe character(ASCII dec code 39) as an argument value to SLAX script?
On Fri, Jul 13, 2018 at 12:35 AM Phil Shafer wrote:
>
> Martin T writes:
> >aren't you using grave accent("echo -e "\x60"") character? I was using
> >"echo -e "\x27"" character.
>
> Doh! I read apostrophe (even named the script apos.slax) but my
> brain turned into backtick.
>
> Yes, this looks like a JUNOS bug:
>
> root@box> op apos char "'"
> ''':(null):(2) Invalid expression
> error: runtime error
> error: Evaluating user parameter char failed
>
> The underlaying slax library handles it correctly:
>
> % slaxproc -E -n cs-examples/apos.slax -g -a char "'"
>
>
> got: '
>
>
> But it looks like this is explicitly handled in slaxproc.c:
>
> quote = strrchr(pvalue, '\"') ? '\'' : '\"';
> tvalue[0] = quote;
> memcpy(tvalue + 1, pvalue, plen);
> tvalue[plen + 1] = quote;
> tvalue[plen + 2] = '\0';
>
> This logic doesn't appear in the JUNOS driver (/usr/libexec/ui/cscript).
> I'll open a PR for this.
>
> There is a limitation in XSLT that one can't mix strings with both
> single and double quotes. Strange but true.
>
> Thanks,
> Phil
Thanks for confirming this! Just for information, another interesting
quirk I found is that in the case of non-interactive SSH mode, the ";"
character breaks the command on cli if it is preceded by escaped
double-quote character. I tested this with Net::OpenSSH, Net::SSH2 and
Net::SSH::Expect Perl modules, but one can demonstrate this easily
with OpenSSH client as well. For example:
$ ssh vmx1 'set cli directory "f\"oo;bar"'
error: Cannot set directory to 'f"oo'
error: unknown command: bar
$
In interactive mode, there is no such limitation:
martin@vmx1> set cli directory "f\"oo;bar"
error: Cannot set directory to 'f"oo;bar'
martin@vmx1>
Last problematic printable(dec 32 to dec 126) ASCII character, which I
found, was "\". It seems to work in a way that it escapes the
double-quote character('\"' becomes '"') and reports a syntax error if
"\" isn't followed by any other character.
The reason I found those Junos cli quirks is that I wrote a test
script(https://perldoc.perl.org/Test/More.html), which among other
things, generates a random string of characters from " "(dec 32) to
"~"(dec 126) which becomes an argument value for op script. So in
order to avoid any Junos cli errors, I'm doing following substitutions
to this randomly generated string before returning it to Perl
Net::SSH::Expect module:
# Replace one or more \ character(s) with single _ if the \
character(s) is at the end of the string.
$str =~ s/\\+$/_/;
# Delete all the \ character(s) if they are preceeding a " character.
$str =~ s/\\+"/"/g;
# Delete all ' characters.
$str =~ s/'/_/g;
# Escape the " character.
$str =~ s/"/\\"/g;
return $str;
I'm not saying, that this is perfect, but it is best I have managed to
come up with. I try to preserve the rendomly generated string as much
as possible. As much as I have tested, it seems to work.
regards,
Martin
___
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 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] eve-ng - lab environment
Another cool thing with EVE-NG, it has got REST APIs which can be used in CI/CD automated builds for things like testing and validation. Might be a useful tool for NetDevOps :) Ashvin On Mon, Jul 16, 2018 at 7:06 PM Aaron Gould wrote: > Cool, yeah, my gosh I like eve more than lsys at this point > > > > -Aaron > > > > ___ > 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
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
