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
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
> 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
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
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
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.
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)
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
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
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
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
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
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
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
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 :-).
>
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.
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
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
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
19 matches
Mail list logo
